Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re <lucio@proxima.alt.za>]

On Thu, Jan 15, 2004 at 12:11:38PM +0000, Charles Forsyth wrote:
>
> certainly before writing the original devusb.c,

Probably no one better qualified than you for that purpose :-)

> my impression on inspecting the mess that was USB
> implementation in other systems is that one ended up with
> a fair number of little drivers in the kernel to handle the
> peculiar dances required for each new (or broken) device.

Which is why my first thoughts were that we ought to take a peek
at brucee's work in connection with LKMs.  But we don't have to,
we can certainly interchange kernel and userland top-halfs, in my
opinion.  I gave my reasons elsewhere, but to recap, the kernel
doesn't have much greater authority than eve, so as long as eve
owns the drivers, they'll work fine except for some context switching
costs.

Still, brucee, any reason why your work is still languishing unused?

> for instance, i fail to see why talking to a Palm on USB
> should need anything in the kernel, but there it is in other systems.

Well, let's not put it in there, we get a choice, don't we?  And
we can use others' bad experiences to save ourselves blood, ssweat
and tears.

> i therefore deliberately put enumeration outside the kernel because it is (potentially)
> non-trivial and recursive (so is PCI enumeration but it has
> rather less to do, placing less of a strain on KSTACK).
>
But no more than seven deep, or is that five?  Surely we can cope?
Much more importantly, how complex is enumeration as such?  In my
extremely limited understanding, it merely needs to return (assign,
in fact) the ID of the device, its type and whether it connected
or disconnected.  And, no, I'm not sure :-)  I'm asking.  Worse,
I'm hoping.  But of course I can "just try it".

> i still think a kernel would need to interact
> with a configurable user-level process (or processes) to do
> enumeration properly in general.  the state required to do that

Well, not what you have in mind, but if usbd reads the ctl or stat
or enum file (whatever you need to call it) and configures and
initialises each device in turn (and may or may not do something
with those that have disappeared, I'm not sure whether they need
reporting by #U or can just be detected by their absence, something
probably needs to be done about them at usbd/user level), then #U
needs to do only what it knows about, which is hopefully very
little, let's call it identification and someone (me?) can document
what it should consist of.

> seemed to be split between kernel and process, which seemed
> clumsy, compared to putting it all in user-mode.
>
I ought to take your word for it, but I won't: you don't sound
convinced enough.  Now if rob or jmk were saying the same in their
somewhat very final style, I would just go hide in my corner :-)

> that code still seems to me to belong beyond the `much-needed gap'.

Flesh this out a a bit for fools like me (if there are any), please!

++L