Messages in this thread | | | Date | Thu, 30 Sep 1999 11:08:49 -0500 (CDT) | From | Jesse Pollard <> | Subject | Re: [Q]: Linux and real device drivers |
| |
From: Nathan Hand <nathanh@chirp.com.au> > - XFree86 (uses mmap and user space dma)
XFree86 will move to /dev/fb as soon as it is practical. This is to increase the security (and stability to the kernel) as well as greater portability. This is also one of the goals of the GGI project.
> - SANE (uses scsi generic, perhaps ide-scsi emulation)
I believe the application also recommends not putting anything else on the same SCSI but the scanner.
> - cdrecord (uses scsi generic, perhaps ide-scsi emulation)
The readme file for cdrecord states that this is only because of a lack of support at the SCSI level. The warning is that there is no security on any device on the controller that cdrecord has access to along with a recommendation to not put anything that needs security. The generic SCSI driver is not designed to enforce security.
> - ghostscript (de-facto printer drivers) > Not a good example: ghostscript doesn't do device drivers - it is a language interpreter. The output of the interpretation goes into a spool file where the data is passed through a user mode queue and copied a /dev/xxxx device. The device driver only handles the data transfer to/from user buffer to device. If the interpreter is used to directly write to the /dev/xxxx then it is transfering the data to the device using a kernel device driver.
What is really being called for (at least in these examples) is an expansion of the capabilities of the generic SCSI driver. The driver needs to be able to identify the target (and possibly the lun) that is allowed public access. This is a finer graned security capability than is currently supported - no defined way to allocate a device to a single user (other than serial devices).
The interface to graphics/video devices is being worked on - the frame buffer driver is one, GGI is another. These (appear?) to permit controlled access to memory buffers resident on the card (memory mapping), but not allow access to control registers except via the device driver.
I don't see a problem with getting device driver interfaces (kernel-driver) more stable. It is a problem changing the interface since not everyone becomes familiar with the change immediately, and until they do they can't port an older driver to newer "standards".
One of the advantages of a full microkernel design is that device drivers can operate in their own address space, thus protecting the microkernel from driver failures. Perhaps a related approach for kernel-driver interfaces could use two versions: A source level interface that allows for maximum integration (the current interfacing style), and a microkernel interface that puts the driver in its own address space. The microkernel interface could be the one directed for use by binary-only drivers.
How about something like that? ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |