On Sun, Aug 25, 2002 at 09:07:47AM -0700, James McMechan wrote:
> Currently the usb patch I been tinkering with for user mode linux is having
> trouble with the modifications to the build system and header files in
> linux-2.4.19, and linux-2.5.31 in addation appears to have a very large set
> of usb updates applied, I have just spent several evenings reading the code
> and working on compile problems with the updated versions.
> uml-2.4.19-1 compiles as built in but still not as a module.
> uml-2.5.31-1 in addation I am seeing many usb changes and some added
> complexity and am still working to make a reasonable patch set.
> Each of these run ~40K uncompressed and ~10K compressed, I don't think that
> I am up to a patch that works for both... Does anyone know: will the 2.5
> style header/directory layout changes make it into the 2.4 kernel or are the
> headers going to stay the same?
I'm thinking of leaving the file structure (i.e. no subdirectories) the
same in 2.4 for now, unless people _really_ want to see this change.
I am backporting lots of header file changes, and API changes from 2.5
to 2.4. See the 2.4.20-pre kernel for some of them (like the removal of
all typedefs, and some other changes.)
> It would be convient to just send the patches once and the let them sit in
> the trees, if desired I could make it so that they are not in the normal
> build scripts or something but sending 40K/10K diffs each time seems
> slightly silly
I'd be glad to accept the UML patch for 2.5, but not 2.4, as UML does
not look like it is going to go into the 2.4 tree.
> I may send the patches even without building as modules, but I really don't
> like to work without modules.
> What should I call the driver for 2.5 I was thinking based on the current
> usb/host examples that perhaps I should change to usb/host/uml_hcd? it would
> seem to make more sense assuming Jeff Dike's comment about putting it in the
> drivers/usb tree still seems reasonable?
It sounds like this is a USB host driver, so uml_hcd sounds fine. And
yes, putting it in the tree makes sense, as when people change the USB
api, they can fix your code too.
> I noticed that both the drivers/usb/Makefile and drivers/usb/host/Makefile
> files need configuration options for the hcd drivers would it make more
> sense to always include drivers/usb/host in drivers/usb/Makefile in both
> obj-y and obj-m cases?
The open needs to be in the drivers/usb/Makefile so the build process
knows to go into the drivers/usb/host/ directory if your driver is
selected to be built into the kernel directly (not as a module.) The
drivers/usb/host/Makefile will be used to figure out the rules to build
your code from.
> I have also noticed that ARM has a special case in the Config.in(s) to allow
> enables of USB. The approach I was thinking of for uml was to have the
> master CONFIG_USB external to that file and optionally source the
> drivers/usb/Config.in based on the setting this would allow the ARCH=um case
> to be handled easily in the ARCH Makefile and could also have the general
> case where USB depends on PCI handled one level up in the driver/Config.in.
> This would also allow the ARM case to be handled in a similar way without
> cluttering drivers/usb/Config.in with ARCH specific "$CONFIG_PCI" = "y" -o
> "$CONFIG_SA8110" = "y" -o "CONFIG_USERMODE" = "y" which I consider
I don't think it will be very cluttered. But send me a patch for
drivers/usb/host/Makefile to prove me wrong :)
> In the usb/XXX Config.in seems the place to handle arch specific hardware
> avaibility just like hardware that depends on v4l or the scsi midlayer the
> hostcontrollers already do this but the main Config.in has that nasty if
> PCI/SA8110+USERMODE in my case and I would like to simplify it if that seems
> a reasonable course. I would think that the CONFIG_PCI would make a nice
> addation to the dep_tristate list for the OHCI/UHCI cases since if I read it
> correctly the ARM/USERMODE stuff does not have the PCI but does have a
> specific controller.
> Also I noted that several of the include files have changed greatly in the
> 2.5 tree and the typedef struct usb usb_t for example has dissappeared.
> Several struct elements have changed name for example from ->index
> to ->wIndex in what Jeff Dike refers to as sTuDlYcApS and seems to dislike,
> are these Hungarian notation I think, from the spec or are they the
> linux-usb list perfered notetation?
As I said above, those typedefs are now gone, don't use them, they will
not show up again.
The change from ->index to ->wIndex was done as those fields directly
map to the USB spec fields, so we want to keep the names the same.
Trust me, I don't like StudlyCaps, and it is not the normal Linux style,
but in this case, it is needed.
> > Uncompressed is nicer, as then people can see them easier, and comment
> > on them directly in responses. If the patch is real big, let me know.
> Uncompressed ~40K compressed ~10K
It sounds ok to send to the list.
> > > Jeff had commented on the duplication of the RH_OTHER... defines from
> > > and when I checked I found that all three host controllers (ohci.h
> > > usb-uhci.h uhci.h) in 2.4.18 have all of the RH_XXXX we used defined the
> > > same, perhaps a common header file for (I assume) root hubs might be in
> > > order?
> > Yes, this work has been done in 2.5.
> Very good, I have been looking at the hc_simple.[ch] stuff and it appears to
> be very nice... I have not figured yet what parts I might be able to use but
> it appears much nicer than those three copies from before.
hc_simple.* is for an embedded controller, I don't know how well it
matches what you want to do. Take a look at the hcd interface, it
probably works better for you.
Hope this helps,