usb/umass, devfs: this sucks

[Henrik Gulbrandsen]

On Wed, 2007-12-26 at 00:35 -0700, M. Warner Losh wrote:
> In message: <200712260038.11546 at aldan>
>             Mikhail Teterin <mi+kde at aldan.algebra.com> writes:
> : If we want people to give FreeBSD a try in good faith, it is both profoundly 
> : stupid and dishonest on our part to claim, we have a working USB-system... It 
> : does not matter, how great our buffer-sharing VM is, if a home user can't 
> : process their photos with a FreeBSD-powered computer.
> 
> In an ideal world, it would be perfect.
> 
> However, all the USB hardware I've recently purchased actually does
> work without a hitch on my FreeBSD system.  Older card readers are
> more problematic.
> 
> Rather than complain about the system, how about merging RELENG_7's
> usb stack to RELENG_6?  Or fixing a few bugs from the PRs that are
> filed?  I did my time in a big push for 7.0, maybe some other people
> can help out a little too?

Fixing and merging are good, but it seems to me (as an occasional patch
contributor without commit privileges) that the bottleneck for USB is
still in the handling of incoming patches. At the moment, there are 162
USB PRs to close. Out of these, 103 are marked with "[patch]", but only
42 of those are actually in "patched" state. Almost all of the latter
were apparently handled as part of Warner's summer push.

The USB stack has to deal with many third-party devices, most of which
will not be immediately available for testing by FreeBSD developers.
This means that we are more or less forced to rely on external patch
contributors (such as myself) to provide workarounds for the problems
caused by various hardware peculiarities. Usually, it shouldn't take
more than a basic code review to accept these patches, so this would be
a good place to start if you want to improve USB handling in FreeBSD.

Look at it from my perspective: I would be happy to complete my fix for
the infamous five-year-old usb/46176, so people can finally detach umass
devices without having to manually unmount them first. However, it will
undoubtedly take a non-trivial amount of time to reproduce and eliminate
the remaining issues. I'm more likely to put in that effort if I believe
that my patches may actually end up in CURRENT, but if a one-line fix
such as that in usb/78984 has not been applied after more than a year,
how long will it take for patches that involve multiple subsystems?

/Henrik