From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] USB developments Message-ID: <20040115150224.H25947@cackle.proxima.alt.za> References: <20040115104258.A25947@cackle.proxima.alt.za> <1bc4a83f021e1f3542be7e8c1d0233e4@plan9.escet.urjc.es> <20040115120513.C25947@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20040115120513.C25947@cackle.proxima.alt.za>; from Lucio De Re on Thu, Jan 15, 2004 at 12:05:14PM +0200 Date: Thu, 15 Jan 2004 15:02:25 +0200 Topicbox-Message-UUID: b9d63754-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 15, 2004 at 12:05:14PM +0200, Lucio De Re wrote: > > Well, my thinking (muddled as it is) was that the ATA/ATAPI driver > must somehow submit commands via the USB interface, which means that > if the ATAPI driver is not already split along these lines, it ought > to be and the top portion would then be linked to its bottom portion > or the USB driver depending on how it is to be used. > As suggested by Richard Miller, I had a look at /dev/sdctl. There'are configure() and unconfigure() functions in there that certainly seem appropriate to our needs. If I read it right, they deal with the appearance and disappearance of ATA (and SCSI? doesn't look like it, at first glance) controllers in PCMCIA (PC-Card) format. The corresponding /dev/sdstat, queried on my workstation, yields: term% cat /dev/sdstat sdC ata port 1F0 ctl 3F4 irq 14 sdD ata port 170 ctl 374 irq 15 which is pretty useful, if not exactly in the format USB would require. Is there any documentation on this other than the source? The source is OK, I guess, but it seldom provides rationale, which would help me immensely. At a guess, for correction by those in the know, I'd wish for: ... sdU ata usb0/2 ... with all sorts of complications that cause my head to hurt. But it won't cause any damage to fix the little comment: /* Try to find the card on the ISA bus. This code really belongs in sdata and I'll move it later. Really! */ (this in /sys/src/9/port/devsd.c!). I should think that generalising the (un)configure() functions would require producing specialised stubs for each machine dependent or otherwise device, so the above would be fixed as a matter of course. ++L