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/