Re: [9fans] USB developments

[Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>]

> 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.