Re: [9fans] port/devcons.c is not port-able

[Dan Cross <cross@math.psu.edu>]

Maybe this is relevant, maybe not.  My brain's been shot (uhh, not
literally for anyone who might wonder about that statement) over the
last few months so bear with me.

I have a digital camera that uses the mass storage protocol over USB.
I looked briefly at writing a driver for it, but realized at one point
that I would have to duplicate a lot of code to speak, e.g., the SCSI
protocol over USB to talk to it.  It occured to me that one way to deal
with it might be to write a SCSI loopback device that would speak the
SCSI protocol to/from a file descriptor that was passed into it somehow
(say by mounting it on one).  Then a user-level program could provide a
transport over say USB and let something above it talk SCSI so it would
still look like a disk as far as the rest of the system was concerned.

As for console input, we already have a console input file, right?  Or
at least a keyboard input file that effectively emulates a console
input file.  Can't we just cat whatever into that file to provide
console input from multiple sources?  E.g., cat /dev/eia0 > /dev/kbdin
(possibly parsing what comes out of /dev/eia0 to look for latin1()
style key sequences.  Perhaps it's time to look at pulling latin1() out
of the kernel and plonking it into libc again.  Everything that needs
to do alt sequences uses it, why is it still in the kernel?  But I
digress).  That is, just put the loopback in userland where it
belongs.  I think you're trying to get at something more subtle,
though, and I'm probably missing the point.

	- Dan C.