WebSite Information > Article Discussions
AN changing USB driver stack to 32-bit
Lars:
AN is currently working on XHCI. Along with that there is a decision to make the USB driver stack (mostly) 32-bit.
The stated reason for this was to increase data throughput.
Today, the USBxHCD.SYS and USBD.SYS drivers have been changed. Along with that change came a change in driver interface between these drivers that is no longer publicly documented (The driver interface of the old 16-bit drivers is documented in a HTML document as part of the DDK and therefore available to anyone with a DDK license).
Currently, the client drivers (USBPRT.SYS, USBMSD.ADD, USBAUDIO.SYS etc.) have not been changed and the driver interface of USBD.SYS still allows the use of 16-bit client drivers with the new 32-bit components.
However, there are ideas to also change the driver interface of all client drivers and make them 32-bit also.
What that means in practice is that you will no longer be able to combine say USBMSD.ADD and USBAUDIO.SYS from my driver set with the AN driver set.
Since AN has only little interest in offering audio and video support in OS/2 (it's not their business use case) that effectively would mean that development of USBAUDIO.SYS would be terminated and also that ArcaOS is become more and more proprietary, effectively a new OS next to OS/2.
Please speak up now if you don't want that to happen. I have always provided free USB drivers to the community and Wim and me we have invested considerable effort in making USBAUDIO.SYS what it is today. I see AN's need to make money from ArcaOS but I also see that with an ever diminishing user base, this step will be the last nail in the coffin of OS/2.
While there might be technical reasons I think that changing the driver interface will lock out anybody else in developing a USB driver (think about Wim's USBECD.SYS driver for example) and the OS/2 community is already short on driver developers.
Lars
Mike Kölling:
Hi Lars,
This is bad news for me, because I need both paths of development from you and AN. On my TP X200 I can only run the AN branch of USB drivers successful (or the latest IBM version) together with Wims drivers for the built in camera. On my newer TP X250 only your drivers are working. I really hope that both branches will not divert to much.
Greetings from Seoul,
Mike
Neil Waldhauer:
I'd rather see Arca Noae publish every interface that you guys need to continue their work. I can't imagine that they want the OS/2 community to shrink.
Going to a more modern 32-bit model for USB is not a bad thing in itself. Why make it bad by not disclosing necessary technical details?
Lars:
--- Quote from: Neil Waldhauer on January 26, 2018, 03:41:43 pm ---I'd rather see Arca Noae publish every interface that you guys need to continue their work. I can't imagine that they want the OS/2 community to shrink.
Going to a more modern 32-bit model for USB is not a bad thing in itself. Why make it bad by not disclosing necessary technical details?
--- End quote ---
It's not so much the bitsize that worries me as such but a change in interface.
For example, even in the existing USBEHCD.SYS I had changed part of the code to work with linear addresses (therefore 32-bit) because structures to manage became larger than 64 kBytes. That was necessary to get isochronous transfers to work with USB 2.0. There are other places in the drivers where I thunk to 32-bit and back to 16-bit. But all that was transparent to the inter-driver interface (no change).
My worry is that if data structures are passed between drivers that all pointers within these structures or the addresses of these structures will change to 32-bit flat or that the layout of these structures changes. When that happens, the existing client drivers will not work any more.
Also, it will then become impossible for me to run a USB driver with my stack in order to debug it (which I do quite frequently if there is a problem with driver interaction).
Martin Iturbide:
Hi
If Arca Noae's reason not to open source or distribute their documentation is because of the IBM DDK license excuse, I recommend for them to do what Lar's did. Offering USB drivers source code as a close source, but collaborative project under the umbrella of an organization like Netlabs.
That is the way they can legally continue USB development to be collaborative if they are worried about the IBM DDK license.
Regards
Navigation
[0] Message Index
[#] Next page
Go to full version