I think every thing Tomas Carnecky has said here about device driver design is valid and dose apply to the DRM/dri. He may not know every thing about system security, but we also all have our strangths and his strangth is oviously device design. One way of interpeting what he is trying to say is that the DRM should be even lower-level and get back to the basics. There are going tobe alot of gripes and grones, but it's UNIX not windows.
ioctl ONLY for registers, even mmaped ones. read/write for DMA. seek for changing where your DMAing or writing to the GART and video mem. select sleeping and waiting. There is no versioning, invalid ioctls will be enuff to find out it's not supported by the card or driver. To identify the modual /proc/devices major number lookups. For security using diffrent minor numbers, 0 for mode setting, 1 for 2d, 2 for 3d, ext. Where 2 has the same modes as /dev/mem and games/users have to be setuid root they do directly access the hardware. The idea is to reduce the kernel mod to nothing more then device enumeration and detection. --- Tomas Carnecky <[EMAIL PROTECTED]> wrote: > Ian Romanick wrote: > > > Tomas Carnecky wrote: > > > >> The dri/drm interface seems to be quite low-level. I heard somewhere > >> that different devices have quite different registers and work in a > >> quite different way. If it is true that it would be better to make a > >> more high-level interface where every driver can do it's stuff as it > >> needs. How much low/high-level should the interface be so you get the > >> best performance out of these many different devices and don't have > >> to make workarounds in the drivers. > >> I have the impression that the newest cards have quite high-level > >> chips interfaces (supporting shaders etc.). > > > > > > 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. > > > 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. > > > 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? > > 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). > > 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]. > > > [1]: even /dev/hda or /dev/sda is readable by world (at least on my > box). > > [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-develel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ------------------------------------------------------- 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
