Hi,
I believe that I owe Johannes a reply to a patch that he
posted on 2000-may-04, so here's my reply.
<reminder>
It is the policy of the linux-usb mailing list (and its maintainer)
as defined and decided last Dec. 1999 to accept patches or reject
them with reason.
</reminder>
Johannes's devfs patches for USB have been especially difficult
for me to decide and no doubt I have taken a long time on it.
I really couldn't decide.
Johannes and David Brownell had some good discussion and some good
progress with JE's patch, and my thanks to David Brownell for
experimenting with this patch.
In the end I asked Linus about it, and he said that we can't _require_
devfs for USB operation [his reply is below], so this patch as
submitted isn't acceptable [my words]. I hope that this patch
decision hasn't delayed other USB implementation or patches.
So we are still in need of a patch with this kind of functionality
that doesn't rely on devfs. (Using usbdevfs is fine.)
It seems to me that module autoloading via usbdevfs should
be a high priority for us right away.
We don't know whether devfs will be used for lots of PnP support
in 2.5 or not, but we can't depend on it now (2.4).
There are also parts of Johannes's two patch files that aren't
about devfs that should be added to the kernel.
Johannes, will you give me separate patches for these (preferably)
or should I extract them?
Linus: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Basically, we cann't require devfs for operation, it's too
experimental as is.
If the thing still works without devfs, it would be quite acceptable.
For example, if the behaviour were to be that with regular devices you
can only see _one_ mouse device (the mixed up one) etc, and in order
to see multiple ones you'd have to use devfs, that would be ok, I think.
But if it becomes an issue of not seeing USB devices at all unless devfs
is on, that would be bad..
~~~~~~~~~~~~~~~ some comments about JE's patches ~~~~~~~~~~~~~~~~~
_______________ [basically what I sent to Linus] _________________
Johannes has proposed a USB patch for device/driver
PnP support that is based on devfs & devfsd.
IMO Johannes is pushing the leading (or bleeding) edge
of USB and PnP.
OTOH Alan says that most initial 2.4 distributions won't
have DEVFS support turned on, so Johannes' patch won't
do most people any good unless they enable DEVFS support.
Alan also doesn't want to base USB PnP on devfs because
he wants the USB backport patch to continue to work on
2.2 and having a devfs dependency makes that messy.
If we were starting from {zero, scratch}, Johannes' patch
wouldn't be difficult to accept & apply. There would be no
2.2 to consider, nothing about distros moving to devfs to
consider, etc.
I would go with Johannes' devfs patch and have what
appears to be a nice USB PnP solution, although it's
unknown as to how this would fit with Linux 2.5 PnP
(for USB, PCMCIA, hot-plug PCI, SCSI, 1394, etc.).
It has never been my primary goal to support Linux 2.2
with USB. Having a backport patch is nice. Maybe even
more than that for the distributors -- maybe Required.
Maybe we need to decide how important 2.2 support is
before going any further with this.
Sometimes reality sets in and we have to consider things
other than the ideal.
I really don't want to lose any developers over this issue.
We all benefit from having Johannes helping on Linux-USB.
I've seen a few emails suggesting that Linux 2.5 is where
full Linux PnP support will be developed. Is there reason
to believe that this will be based on DEVFS or on
something-yet-to-be-developed?
If based on DEVFS, I guess USB can be a guinea pig for it
to see how well it works, what changes it needs, etc.
~~~~~~~~~~~~~~~~~~~~~~ end ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
JE, 4/4/2000: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is an implementation of the proposed changes I sent an email about
last week.
See
http://www.electricrain.com/lists/archive/linux-usb/2000/03/msg00860.html
for the original email and explanation.
There are 2 patches. The first one is for the kernel and it is against
2.3.99-pre4-3. The second patch is for devfsd and is against the 3-FEB-2000
release.
[snip]
JE, 5/4/2000: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[snip]
First off, I've attached a patch to completely nuke usbdevfs's VFS layer in
favor of using devfs for all of that stuff. Nodes are still created, and you
use the same ioctl()'s, you just use a different name and you don't have
to worry about mounting an extra filesystem to get it.
The patch also does a couple of other things:
- Adds a new GET_DRIVER ioctl()
- Set's the address for the device before grabbing the descriptors
This is safe since we need to do the short descriptor read to get the
maximum packet size of the control pipe, however SET_ADDRESS doesn't
have a data transfer stage, so the maximum packet size is never used
Also, I'd like to get my user space driver binding patch included to
appropriately load and bind drivers for devices to minimize problems that
the
current scheme has.
[snip]
I'm working on another workaround which moves it from the HCD to the core
so it'll work with all devices, but I've been mainly working on other
issues that more important for USB as a whole than a specific device.
[snip]
______________________________________
~Randy
___________________________________________________
|Randy Dunlap Intel Corp., DAL Sr. SW Engr.|
|randy.dunlap.at.intel.com 503-696-2055|
|NOTE: Any views presented here are mine alone |
|and may not represent the views of my employer. |
|_________________________________________________|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
