The design priciple of the open-source drivers is that the kernel part acts as nothing more than a conduit to shove bits into the chip.
It's the first time I hear that.
It is a good design principle for hardware with complicated interface.
Because of that, the interface is pretty raw and varies from chip to chip. For DMA programmed chips, the user-mode driver works by filling buffers with "stuff" and asking the kernel to kick of a DMA operation with the buffer. That's why so much of the ioctl inferface is device-dependent. This doesn't make for "workarounds in the drivers", it just means that the user-mode is written to work with its own low-level kernel-mode interface.
This reminds me to XFree86. XFree86 requires root rights to run, because it accesses the hardware directly (using /dev/mem) and does other dangerous things.
I think that the device driver should avoid that and expose a nice and safe interface to the userspace.
DRM does. And it would be possible to expand the range of functions that are safe for unpriveleged access.
On advantage of this is that we don't have to modify the kernel drivers very often. Some of the drivers have had regular updates to the user-mode part, but thier kernel driver hasn't been modified in over a year. For us, that's a *big* advantage.
This is certainly a very unimportant thing (for me). Because all other parts of the kernel change regularly, why should the graphics drivers
not?
Well, would you like to be the one to maintain that ?
A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc).
Harddisk controller is a lot simpler to make use of than a 3d accelerator. Besides, there are only two standards: IDE and SCSI. Same goes for USB and firewire.
The device driver should expose an interface, which can be used by all
users[1] in a safe way. With the current design, you can't render into a
off-screen buffer easily. Either you use X or DirectFB. But it's not possible to use it in a easy and safe way[2].
Look, I would be the first to agree with you - make a good mathematical model for your hardware and then implement the interface in the device driver.
The problem is that graphics hardware is changing and just when you made your nice interface you'll get the docs to something new (like programmable pixel shaders) and you have to redesign it.
[1]: even /dev/hda or /dev/sda is readable by world (at least on my box).
On a personal box this is probably fine. On a public one.. do you want your /etc/shadow file readable ?
best
Vladimir Dergachev
[2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver.
-- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M ?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
