On Thu, May 25, 2000, Dunlap, Randy <[EMAIL PROTECTED]> wrote:
> 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>
Gotcha. Point completely taken.
I can definately see your and Linus' reasoning behind this.
> 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.
David was the only person to give me feedback. Thanks David. I appreciate
it.
I have also talked to numerous people about this internally at VA as well.
Thanks to them as well.
> 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?
I've split out a couple of them already (from the first version). I'll
make a patch for the other unrelated features. I have a couple of more
that I've added since then as well I'd like to propose as well (look for
a separate email).
> 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..
This is misleading and many people have had this impression.
It's unfortunate you send me this email right now since I'm finishing up
support for the latest version which finally implements permissions and
ownership tracking among some other features.
Oh well. Since it's pretty mnuch done, I'm still going to post the patch
along with some comments about the topic.
> ~~~~~~~~~~~~~~~ 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.).
No one has touched on this much. I've talked to David Hinds (PCMCIA
developer) and my impression was that he has avoided the topic because
of other non technical reasons.
The PCMCIA guys do have a solution which works well for them, unfortunately
while some of the problems are shared among us, there are different
problems which their solution does not solve for us. Their solution
does not solve all problems either.
I have not talked to the Hot-Plug PCI people (Motorola?) but I suspect
that their problems are identical to that of the PCMCIA team since
they are so similar.
USB has much more in common with 1394 than any other hot swap interface
but they are not as far along as USB support is in Linux.
We do share many common problems that SCSI has with hot swap, but they
have not touched on the problems with hot swap at all.
> 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.
Just to clarify. Requiring devfs for this implementation (the word
implementation is important) does not rule out 2.2. Richard Gooch has
maintained a 2.2 version of devfs since before 2.3.
> 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.
I'll touch on this topic in another email.
[snip my emails]
> 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.
This was about the APC workaround and doesn't have much to do with devfs
and userspace driver binding. Just so no one gets confused why this was
in the email.
Just to recap:
I'll work on splitting out the unrelated features of my previous patches
and send them to Randy and the list ASAP. These are unrelated to anything
with devfs. I expect this will be sent today.
I'll also be sending an email with my devfs based USB device manager,
a quick white paper on the topic and my reasoning behind making the
decisions I have made.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
