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 <johnson-shen at
ablerex.com.tw> 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
>>>> <johnson-shen at ablerex.com.tw <mailto:johnson-shen at
ablerex.com.tw>>
>> 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
>>>>>> <johnson-shen at ablerex.com.tw
>>>>>> <mailto:johnson-shen at ablerex.com.tw>>
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
>>>>>>> <johnson-shen at ablerex.com.tw
>>>>>>> <mailto:johnson-shen at
ablerex.com.tw>> 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
>>>>>>>> <johnson-shen at ablerex.com.tw
>>>>>>>> <mailto:johnson-shen at
ablerex.com.tw>> 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:Johnson-shen at
ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>>>>> 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:Johnson-shen at
ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>>>> 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:Johnson-shen at
ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>>> 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
>>>>>>>> Nut-upsdev at
alioth-lists.debian.net
>>>>>>>> <mailto:Nut-upsdev at
alioth-lists.debian.net>
>>>>>>>>
>> 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:Johnson-shen at ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>>>> 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:Johnson-shen at ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>>> 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:Johnson-shen at ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>>> 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:Johnson-shen at ablerex.com.tw
>> <mailto:Johnson-shen at ablerex.com.tw>
>>>> 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:Johnson-shen at ablerex.com.tw
>>>
>>> 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: Johnson-shen at ablerex.com.tw
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.)