Dear Sir,
Long time no see.
I have a question to consult you about NUT drivers.
If the driver(e.g. Ablerex_nutdrv_qx) needs to be applied to different
PID/VID, how to deal with this situation?
Besides, user or NAS selects the appropriate driver by setting ups.conf.
Is there any other way?
Regards!~
Johnson
Jim Klimov 於 5/12/2021 8:12 PM 寫道:
On May 12, 2021 10:45:43 AM UTC, Johnson-shen <[email protected]>
wrote:
Dear sir,
I hope you have been well!
May I consult with you about nutdrv_qx’s driver?
If we upload the new driver to NUT. (ex. Ablerex_nutdrv_qx)
That means we have both(blazer_USB and Ablerex_nutdrv_qx) drivers for
our UPS and the same PID/VID.
Is it correct my understanding?
If it is correct, when NAS manufacturers use NUT package to import to
their kernel. They don't know which driver to use during UPS plug-in to
NAS. Because these two drivers have the same PID/VID (NAS vendor told
us
that they choose the driver by PID/VID).
Could you kindly provide more information or experience to us with
that?
Regards!
Johnson
Johnson-shen 於 4/23/2021 11:55 AM 寫道:
Dear Sirs.
I apologize for my phrase and appreciate your support and assistance
for this. We will research for drivers(nutdrv_qx).
Please Kindly support us again, if we have any questions about
(nutdrv_qx).
Regards!
Johnson
Jim Klimov 於 4/20/2021 6:02 PM 寫道:
Sorry for another delay,
I was looking at recent submissions for the new-architecture
nutdrv_qx family of drivers to provide examples, and some of those
submissions needed a bit of cleanup before posing as examples.
Unfortunately our QX expert did not respond yet, so it took a longer
while on my side.
So now I can suggest looking at two PRs:
* https://github.com/networkupstools/nut/pull/638/
<https://github.com/networkupstools/nut/pull/638/> adding support
for
"hunnox" - both a USB protocol subdriver (in nutdrv_qx.c) and
device/HID mapping "hunnox_subdriver" (with sources in
nutdrv_qx_hunnox.c/.h files), and
* https://github.com/networkupstools/nut/pull/1008
<https://github.com/networkupstools/nut/pull/1008> adding just an
"snr" protocol subdriver at this point.
They also add documentation updates for the changes they made, but
this aspect was slightly addressed in your PR already (mention of
the
new subdriver would need to move from docs/man/blazer-common.txt to
nutdrv_qx.txt though).
To remind, my primary concerns about your original submission and
from later discussion are:
* The changes in your PR #979 are targeted for blazer_usb driver
which would at some point be deprecated and obsoleted in favor of
nutdrv_qx, so this added support would be lost. While someone in the
community probably can pick up and port source code lines, it would
be hard to guarantee without access to hardware that the resulting
driver actually works. So in fact you are best positioned (and
incentivised) to initially provide the modern driver that will
survive in the NUT codebase for long.
* Another point is the bold statement that "PID=0000/VID=FFFF of
blazer_USB is Ablerex’s Identification code." It is not exactly a
random unique number, and I suppose if the USB-IF authority had a
*publicly* available registry of the ID numbers they give out - same
as DNS registry, or IANA TCP/UDP port registry, or MAC address
prefix
registry for networking, or many other such lists in IT - these
particular numbers would not be there, probably not for anyone.
Since
the USB-IF registry is not public, I can only assume that the other
mentioned Vendor ID "1cb0" is registered properly and no other
devices would conflict using it. I understand the technical point
that these "0000:FFFF" are the uncustomized IDs flashed into the USB
chips your devices use, but it also means that any other vendor
might
have those spectacularly not-unique ID numbers, with same or even
unrelated chips. We already do have a practical example of such mess
with "ATCL" chips that provide USB media connections for otherwise
unrelated UPSes that talk completely different protocols and have
different NUT drivers for same Vendor ID + Product ID + Device
String
tuple.
* Also, "the modification is only for the addition of Ablerex
product
features, so there is no need to consider the differences of other
customers" - the wording here may be unfortunate, English is not a
native language for either of us, but as written this phrase looks
very concerning :) You are changing an existing driver that supports
several device families already, and existing users of this driver
expect that the support is not broken when they upgrade NUT. So *OF
COURSE* there is a need to consider differences for other customers.
That said, your original (blazer_usb) submission was quite cleanly
separated and should not have impacted users... unless they have
some
"0000:FFFF" device that worked before with some subdriver and would
be detected as "ablerex_ext_command=1" and might stop working now;
you did not offer any failsafe (addvar() a flag, probably) to
override your detection and disable ablerex mode in the unlikely
case
it is misdiagnosed and breaks somebody in practice.
* Notably, the mapping macro in nutdrv_qx is more elaborate and
allows to map not just ID numbers but also a string the device
presents itself with, so detection of proper subdriver can probably
be made more reliable at that point, and not with a hack to check
particular IDs in `blazer_initinfo()` as you proposed in current PR.
Hope this helps,
Jim Klimov
On Mon, Apr 12, 2021 at 11:17 AM Johnson-shen
<[email protected] <mailto:[email protected]>>
wrote:
Dear Sir,
How’s today?
Could you kindly provide your comment about our opinions?
Please kindly provide more information, documents or example
code
about the driver that will separate Ablerex's, if you did not
agree with our opinions.
Regards!
Johnson
Johnson-shen 於 4/6/2021 6:22 PM 寫道:
Dear Sir,
Could you merge our driver for us?
Because PID=0000/VID=FFFF of blazer_USB is Ablerex’s
Identification code. And this time the modification is only for
the addition of Ablerex product features, so there is no need
to
consider the differences of other customers. Could you agree?
Regards!
Johnson
Jim Klimov 於 4/4/2021 7:43 PM 寫道:
Hello,
I am really sorry about the delay, I hoped our community
expert on the Qx drivers would recommend the best course of
action, but he did not reply yet.
To me it currently seems that this Pull request:
https://github.com/networkupstools/nut/pull/638/files
<https://github.com/networkupstools/nut/pull/638/files>
represents the modernly desirable addition of a USB protocol
subdriver (in nutdrv_qx.c/.h) and the vendor protocol nuances
subdriver (in separate files).
Sadly, according to comment trail, that particular Pull
request changed a bit of logic in existing functions (around
langid_fix and enabling a hunnox patch, most prominently) and
there were concerns if it is not breaking anything for other
devices that work currently. It would be beneficial if people
running nutdrv_qx today could build that branch and confirm
into PR comments that the updated driver does work well or
does
break something after all.
So I think the new ablerex subdriver should carefully take a
similar path. Nutdrv_qx modular code did grow as a refactoring
and merge of earlier drivers including blazer, so your
original
code contribution should be easily portable into the new
layout.
Thank you very much and really sorry it took longer that I'd
expect,
Jim Klimov
On Mon, Mar 29, 2021, 13:16 Johnson-shen
<[email protected]
<mailto:[email protected]>> wrote:
Dear Sir,
Thank you for your reply.
I can not sure what you mean.
May I confirm with you again about it?
You did not recommend that extend the new function from
blazer_usb.c for Ablerex UPS.
You suggest that separate the Ablerex function into a new
driver(.c or .h) independently to avoid vendor nuances.
Until we follow the above rule to modify, It will be
upload
and merge the driver.
Is it right?
Please kindly provide more information or explain to us,
if
I got you wrong.
Please kindly provide the example for a new structure to
us, I think will help to modify it for reference, if it is
right.
Regards!
Johnson
Jim Klimov 於 3/24/2021 6:26 PM 寫道:
Hello,
Yes, in fact there were two things.
One was that a week ago I posted some documentation
updates into your PR (e.g. for acknowledgements) and
asked
you to confirm they sit well with you, and hoped that's
it.
Unfortunately, I was now reminded that extending the
blazer_usb driver was not a good approach - it was
(poorly, fixing that) documented as heading to obsoletion
and eventual removal from codebase. Various drivers for
Qx
protocols were aggregated in drivers/nutdrv_qx*.{c,h} as
a
common core and clean separate sources for vendor
nuances.
In order for us to maintain support for your device in
the
long run, and not lose it when old redundant drivers do
get dropped, your code contribution should be relocated
to
this newer structure, and importantly - re-tested with
your hardware we do not have access to. I hope Daniele
(CC'ed) can clarify this better if you would need
assistance.
Sorry about not noticing this earlier,
Jim Klimov
On Wed, Mar 24, 2021, 03:58 Johnson-shen
<[email protected]
<mailto:[email protected]>> wrote:
Dear Sir,
The status of the project is waiting for the other
managers to verify and confirm?
Please advise me if you have any support for this
project.
Regards!
Johnson
Jim Klimov 於 3/18/2021 8:07 PM 寫道:
Hello, thanks for the driver update and sorry that I
had to be reminded of the PR by mailing list. I
reviewed it last week and added a few points on
documentation. Can you please check those, that I
did
not mistake something, and I think it is good to
merge. Thanks again!
Jim Klimov
On Thu, Mar 18, 2021, 11:33 Johnson-shen
<[email protected]
<mailto:[email protected]>> wrote:
Dear Wolfy,
Please advise me, if you need more information
about the new driver.
Also please kindly update the status of the new
driver for us.
Regards!
Johnson
Johnson-shen 於 3/10/2021 6:24 PM 寫道:
Dear Wolfy,
Please refer to the below table for the whole
support list of the UPS Model of the new
driver.
Please kindly advise me if you have any
questions.
Regards!
Johnson
Johnson-shen 於 3/10/2021 9:43 AM 寫道:
Dear Wolfy,
Thank you for the reply to emails quickly, the
DK+ is our customer model name for ODM.
We will provide the whole support list of UPS
Model of the driver to you tomorrow.
Regards!
Johnson
Manuel Wolfshant 於 3/9/2021 7:11 PM 寫道:
On 3/9/21 8:37 AM, John wrote:
Hi,
I'm engineer from Ablere Electronics Co.,
Ltd. (http://www.ablerex.com.tw/
<http://www.ablerex.com.tw/>).
I pull request to networkupstools/nut that
Add support for Ablerex Dk+ #979.
long time user of an MS3000RT here. where is
the DK+ described? I cannot find it on your
web site or via google.
wolfy
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District,
Kaohsiung City 807-66, Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District,
Kaohsiung City 807-66, Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung
City 807-66, Taiwan
(R.O.C.)
_______________________________________________
Nut-upsdev mailing list
[email protected]
<mailto:[email protected]>
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
<https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev>
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City
807-66, Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City
807-66, Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66,
Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
<mailto:[email protected]>
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66,
Taiwan
(R.O.C.)
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail:[email protected]
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
(R.O.C.)
Hello,
Ideally, there would be just nutdrv_qx_ablerex.c/.h source, using mostly the
same code and data you developed for blazer, and no separate support in blazer
at all (and so no confusion).
Users (and NAS's) would configure the common nutdrv_qx driver which supports
many devices related by use of Qx family of protocols and was architected to
make that coexistence and re-use of shared code easy (or easier than with
earlier driver codebases).
Based on PID and VID and possibly strings reported to a USB query, it can pick the proper
subdriver such as "ablerex" by itself, or explicitly follow the option from
ups.conf section for the device.
Hope this helps, and thanks,
Jim Klimov
--
Typos courtesy of K-9 Mail on my Android
--
盈正豫順電子股份有限公司
Ablerex Electronics Co., Ltd.
研發部 / 沈南村
E-mail: [email protected]
Tel: 886-7-397-8640 Ext: 894
Fax: 886-7-3978641
807-66高雄市三民區水源路157號
No.157, Shuiyuan Rd., Sanmin District, Kaohsiung City 807-66, Taiwan
(R.O.C.)
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
