From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <20856c5759b5882d951f9cee773e6c3c@plan9.escet.urjc.es> To: 9fans@cse.psu.edu Subject: Re: [9fans] USB developments From: Fco.J.Ballesteros In-Reply-To: <20040115120513.C25947@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 15 Jan 2004 11:23:57 +0100 Topicbox-Message-UUID: b9298342-eacc-11e9-9e20-41e7f4b1d025 > Probably, if Bell Labs are willing and can keep it going. Maybe > we ought to locate a mirror server for sources? Anyone can provide > such a luxury? Well, the mirror for sources is each one of our installations. :-) Again, I could open accounts here if any of you want to do a pull from here for whatever reasons, however, I think it's a better idea to do that from sources. > 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. I had the same point of view wrt to keyboard processing. In the beginning I kept the `top part' of the keyboard driver inside the kernel (kbdmap processing et al.), and the `bottom part' would be either the chipset part of the driver, or the user-level kbd driver. This was a nightmare, the usbhid had to supply scan codes to the kernel via an added /dev/kbdin, and there were races along the way. I just did what presotto suggested, and kept all in the user level program. What I did was to remove the `top part' from the kernel. I moved it to the user-level program, so that kbd processing could happen just in the user-level program (mostly). But you still have to keep some of the top-part in the kernel, because you want the kernet to be able to work if for whatever reason the user program is not started. Regarding ata, I'd say that it's best to put the top-part also within the usb driver, and leave the kernel driver alone. Don't know what you think about this.