Re: [ros-dev] Removing usbdriver.sys from build

[Aleksey Bragin]

This reminds me a funny argument, when I proposed arwinss saying it's  
better, easier to develop, and not so buggy. I was said: "hey, people  
put years of work into existing win32k, why did you come up with a  
new one?! And those people are going to feel offended".

Of course this driver is far from being good, however it works in  
some configurations (does it work for anyone besides me?), and I put  
a lot of hours into work on improving it and fixing these kind of  
bugs, adding new features, implementing keyboard and mouse support,  
and almost had the USB storage devices support.

I commented your list just for clarity sake, to respect those 92  
commits (not only mine) which made it into that driver. Feel free to  
remove this driver, either from boot or from build or even from the  
tree, because:
a) I don't have time for coding it
b) there is no point in coding it now because janderwald's one should  
be improved instead

WBR,
Aleksey.


On Jun 15, 2011, at 6:50 PM, Colin Finck wrote:

>   Hello all,
>
>  Edijus from #reactos has just tried ReactOS on his system, but the  
>  boot process got stuck at "usbdriver.sys". When reading his notice,  
>  I was wondering why we still include this ancient driver in every  
>  ReactOS build.
>  As far as I know ...
>
>  * it has never worked for us 
* for you
>   * it is incomplete and not well-tested 
*
complete enough to the point of supporting usb keyboards, mice  
(both tested), and potentially usb storage (had no time to finish).
>   * it has obvious code bugs (e.g. just look in
> ehci.c:3465 how it
>    enumerates more PCI devices and functions than possible,
>    consequently enumerating the first function twice due to bitshifts) 
* it had 1000
of these, many of them were fixed by me and other devs  
in the process.
>   * better USB work by Johannes and Michael is
> progressing well 
Absolutely, after his work is ready this one is unnecessary.

>   Although it might be useful as a testcase for the
> legacy HAL  
>  functions (like HalAssignSlotResources), it should still be removed  
>  from the build process for now.
>
>  If there are no objections, I'll do this change on the weekend.
>
>
>  - Colin