From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200407140431.i6E4VAP00788@augusta.math.psu.edu> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] port/devcons.c is not port-able In-Reply-To: Your message of "Tue, 13 Jul 2004 07:57:15 MDT." Date: Wed, 14 Jul 2004 00:31:10 -0400 From: Dan Cross Topicbox-Message-UUID: c019baea-eacd-11e9-9e20-41e7f4b1d025 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.