On Fri, Nov 23, 2001 at 07:00:09PM -0800, David Brownell wrote:
> You beat me to the question ... :)
>
> That looks like a good list. I'll just comment on a few specific
> items below, and hope that others chime in! I'm sure Greg and
> Johannes both have comments here.
>
> There may also need to be coordination with other folks. When
> does the new kernel build toolset kick in, for example? And I
> was rather intrigued by some of those notions of cleaning up the
> device tree for power management... some of that should fit into
> the hub work, and give us a physical device naming system that's
> "stable" unless the USB tree is recabled. (Unlike the device
> address scheme, which changes all the time.)
I've been watching Pat Mochel's power management patches and they will
fit into USB quite well (with some USB work :) They will probably land
early in the 2.5 cycle, and will cause the "generic device" change for
the USB core code (in which every device is based off of a "struct
device"). This will also cause some better device reference counting
and locking issues to be cleaned up (hopefully.)
The driverfs addition will also be a good thing for some of the USB
drivers to use (instead of abusing /proc)
> I'll prepare patches for this. I'm thinking of doing it in phases.
> The first one would be "add drivers/usb/hcd.[hc]", with one
> big file holding all the HCD glue and "hcd.o" linked to usbcore.
> Other patches would add the EHCI and OHCI hcd drivers.
Phases are good.
> But I'd like feedback on some questions: Should we move to
> having a "hcd" subdirectory with all the HCD stuff? And if so,
> should the current "multiple file driver" structure stick around?
>
> I tend to like the modularity there (and most places :) and some
> other "complex" drivers use multiple files too. But it's also
> known that the "humongous driver files" approach can also
> be made to work.
>
> For the record, I think of the current "hcd" as a good start,
> but do expect it'll need more work. Particularly as the 2.5
> device tree and power management work fires up, that'll
> be the natural place for some of that work to plug into USB
> (that, and the hub driver).
I think it's up to the specific driver author / maintainer on if they
want to have it in multiple files or not. It really doesn't matter to
me each way. I don't care about the subdirectory issues either (in the
current build system, it does make things a bit more difficult to get
everything working correctly. Hopefully the new kbuild system will help
this.)
> > General driver changes
> > * split out firmware loading to user space (affects some serial drivers,
> > kaweth driver and dabusb driver) [kaweth driver - Brad, serial driver - I
> > think Greg KH and Adam Richter both expressed intent]
>
> Mostly packaging changes, yes? Since "fxload" already exists in
> the hotplug package.
Yes, but it also involves some driver changes, and some further
development on the user space programs (to manipulate the firmware files,
and some new functions are needed to handle special devices.)
> > Specific driver changes
>
> As mentioned above: teach usb-storage to use bulk queuing.
> Necessary to get good throughput on highspeed USB. Lots
> of transfers of only one or two pages means lots of wasted
> bandwidth; say, 10 MByte/sec vs 20 MByte/sec for the same
> disk drive and request stream.
A few other drivers could use bulk queueing changes to improve
throughput speeds (printer and acm for instance.)
> In the 2.5 series some of the drivers are supposed to go away. Stuff
> like "dc2xx.c", "rio500c." and maybe a few others (that have usermode
> drivers). There's that "unbind from userspace" patch too.
I'd like to see both of those drivers removed, as they should be able to
be done in userspace.
I had a list somewhere that came out of the 2.5 developers meeting. As
I can't find it at this moment, here's a few other things that I would
like to be changed in 2.5
- all drivers have multiple debug levels that can be set with module
load options. This should allow for easier debugging in the field
from users, without requiring recompiling code. These levels and
options will be close to the same options that will be added to all
of the network drivers.
- Better reference counting and locking in the core USB code, to help
reduce driver locking issues. A lot of this will fall out of the
power management patches (hopefully.)
- Better URB handling (you should _always_ be able to determine if the
urb is really finished or not.)
- rename 'usbdevfs' to 'usbfs' to help reduce devfs confusion.
- usb-serial core changes (to help reduce duplicated code).
There's more, but I just got back from vacation, and can't remember them
at this time...
> Somewhat related, more of the usbcore functions should show up in
> the kernel programming guide -- not a separate doc.
Are there any public functions that aren't documented?
thanks,
greg k-h
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
