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/ 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 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> 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 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> > 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> >> 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> >>> 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/). >>>> >>>> >>>> >>>> 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 >>>> >>>> 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.) >>>> >>>> >>>> -- >>>> ???????????? >>>> >>>> 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.) >>>> >>>> _______________________________________________ >>>> Nut-upsdev mailing list >>>> Nut-upsdev at alioth-lists.debian.net >>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >>>> >>> >>> -- >>> ???????????? >>> >>> 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.) >>> >>> >> -- >> ???????????? >> >> 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.) >> >> > -- > ???????????? > > 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.) > > > -- > ???????????? > > 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.) > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210420/82a5b357/attachment-0001.htm>
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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210423/59b7b91f/attachment-0001.htm>
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.)-- ???????????? 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20210512/b3906e0d/attachment-0001.htm>