From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: Re: usbd - revision (Was: [9fans] USB developments) From: Charles Forsyth In-Reply-To: <20040115211012.K25947@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 15 Jan 2004 20:24:12 +0000 Topicbox-Message-UUID: ba2fac26-eacc-11e9-9e20-41e7f4b1d025 >>Let's see if our paths will cross. Kernel enumerates based on >>notification (an interrupt, perhaps?) that the structure has changed. >>Am I reading the spec right that enumeration is the only way to >>determine the structure and that it should occur frequently? That's >>certainly what it sounds like, I'm assuming that instead of polling >>one can wait for interrupts, but whichever applies, the code is no >>doubt in the existing driver code already as there is nothing optional >>about it. no. in UHCI you can get interrupts for the notional `root hub' but that's because it's notional. it's not a USB hub. you can't talk to it as though it's a USB hub. there are some strange registers. otherwise, for a real hub, you must periodically use a USB transaction on the hub's control endpoint to poll for changes to the status of its ports. there is no code in the existing driver to poll, but that's precisely because it leaves that to usbd, which anyway needs to poll for other changes in configuration. you need the tree structure because that reflects the physical connection structure. when a hub goes, it takes all the connections through it, including directly-connected devices, other hubs, their devices, and so on. i just don't see why it's so important to you that the kernel enumerate (if it doesn't configure, and if it does configure, it needs to know much more about the class, and since classes are often 0, the device). >>or serial numbers etc. becomes too painful. Keep in mind that XP >>deals with it, why shouldn't Plan 9? because many manufacturers write special USB drivers that deal with the peculiar/proprietary protocol used by their device! it's no different in that regard from VGA (or VESA) >>believe that brocee's work should be reconsidered. Specially if it has been, but that's not really a key to this discussion. it might indeed be useful to load USB-device-specific modules into the kernel, in the same way that Etherif components might be loaded, but that doesn't seem to me to be the determining aspect. the naming problem isn't that usb1/2/ep3data (say) is a funny name: at that level it's as good as any other existing one (eg, eia0, sdD0). the trouble is that for hardwired devices, it's not too bad to name them by physical connection (and that's to some extent unambiguous), since it's long-lived enough to associate with some higher-level notion (eg, my printer is on lpt0), but for dynamically-connected devices, the physical connection name is still unambiguous, but much less useful, since the printer now is usb0/3/ep2data but in a little while it's usb1/2/ep2data, depending on which USB slot on my thinkpad i chose. (in fact, for USB it's worse because the /2/ and /3/ there are dynamically assigned and unpredictable.) that's possibly where a link to (something like) plumbing might be relevant because it might be adequate to be able to say `if there's a printer on the USB bus, that's the one' or even `if there's an HP printer, that's the laser printer, but if there's an Epson that's the photo printer'.