From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: usbd - revision (Was: [9fans] USB developments) Message-ID: <20040115144342.G25947@cackle.proxima.alt.za> References: <20040115134756.F25947@cackle.proxima.alt.za> <4cba074ff1f8f3d1e1270f4f67fbe065@terzarima.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4cba074ff1f8f3d1e1270f4f67fbe065@terzarima.net>; from Charles Forsyth on Thu, Jan 15, 2004 at 12:11:38PM +0000 Date: Thu, 15 Jan 2004 14:43:43 +0200 Topicbox-Message-UUID: b9cefb9c-eacc-11e9-9e20-41e7f4b1d025 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