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: <20040115134756.F25947@cackle.proxima.alt.za> References: <20040115123004.D25947@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Fco.J.Ballesteros on Thu, Jan 15, 2004 at 11:46:53AM +0100 Date: Thu, 15 Jan 2004 13:47:56 +0200 Topicbox-Message-UUID: b94862e4-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 15, 2004 at 11:46:53AM +0100, Fco.J.Ballesteros wrote: > > I think the #U work is just to setup the bus and also to hardwire > the endpoints (i.e. to service real usb interrupts as it's doing now, > for performance). It should not depend on user programs, although > they can for sure setup the endpoints and the like. > We have the interesting Plan 9 feature that the kernel need not be used for separation of identity, everything the kernel can do, eve can also do, specially as regards peripherals. In Unix one moves operations into the kernel as soon as they need to have more rights than the average user. In Plan 9 the only really reason for kernel inclusion is efficiency: even interrupts could be handled by eve processes. What I'm trying to say is that we can put the bare essentials in #U and delegate an unreasonable amount to usb/usbd. But, to counter this, I think enumeration, to the extent that it can be treated as a generic operation, does belong in the kernel. I would repeat my suggestion that it be a #U operation triggered bu usbd, returning a list of devices and hubs that can be used as a starting point for further tasks. With usb_enumerate() as a #U function, it may be possible as well as necessary to include in the kernel code (is init(8) not a possibility?) keyboard, screen and mouse initialisation and configuration so as to be able to boot. Nemo, your experience is invaluable here, I must confess I didn't pay much attention at the time you posted your findings as USB was nowhere on my horizon at the time. > Usbd is probably where the enumeration belongs, but I'd say that > just that. The driver is the one who knows how to configure the device, > once it has been started by usbd (which only needs to look at usbdb). > I think the code itself should live in #U; usbd invokes it thereafter, the ideal time would be by blocking on a ctl read until #U detects a bus change (is this a correct understanding?). Usbd collects the fresh list of hubs/functions on completion. Mind you, #U may as well do the enumeration itself, unblock usbd by posting the list of devno -> (type, status) on the ctl usbd is blocked on. Too expensive, perhaps? I'm thinking of making the enumeration as simple as one can conceive, usbd can then be forgiven for repeating some of the functionality. If #U only holds a list of 0 to 127 possible devices and an accurate "condition", usbd can be expected to maintain the full bus description. We can stop multiple instances of usbd occurring (we may be doing this already?) by making sure that the #U/usbn files are single-open. (Maybe I can try my hand at a #U that does little more than this, right away? Comments?) > So, should we start perhaps by reworking the relationship between usbd > and the drivers? I don't really know. > Somebody with a lot of USB experience should be looking at the usbdb database, I think. This is a long-term function, so it would be nice to have a few volunteers, specially persons who already have some experience interacting with USB device manufacturers. I'd like to look at usbd in more detail, particularly trying to understand how to separate its functionality along standard lines. The device class bit is still very unclear to me, so I need to do some further reading of the USB specification. Those of us who have already looked at various devices may want to suggest where they see the separation between function-specific code and code that should be in usbd. I'd like to hear from them and tune usbd to suit. This with a view to making the device driver capable of being "mounted" on any USB stream, preferably with little or no knowledge of the actual shape of the stream itself. Even the choice of alternative (the standard annoyingly adopted the incorrect adjective "alternate" which I suppose I must force myself to use in future) configurations should be delegated to /lib/usbdb and usbd, in my premature opinion. I'll dig into Richard Miller's mass-storage code and try to understand where I'd hook into the ATAPI driver for my bit in the above. I now have two CBI devices, one ATA, the other flash memory card reader/writer, so it's worth my while to do some digging. Please keep the suggestions coming. Specially if you see me stray off the sensible path. And don't let me get away with waffle, please pick any nonsense I spout off here and correct me. ++L