Re: Thread-private mappings and graphics (was Re: Per-Processor Data

James Simmons (jsimmons@edgeglobal.com)
Sun, 19 Dec 1999 10:53:46 -0500 (EST)


> Huh?
>
> (1) Feel free to write whatever hacks you want for the kernel. Anyone can do that.
>
> (1a) Convincing others that what you've done is worthwhile is more about
> their freedoms than yours, however.

I am :) Thanks to the power of OpenSource.

> What I meant was: have I missed some important technical concept?

I did post something. The three points I made where (some techincal and
princples)

1) Let me quote some passing out of "the Linux Kernel book" By Remy
Card, Eric Dumas, and Franck Mevel.

---------------------------------------------------------------------------
2.2.1 Virtual Machine

"The operating system gives the user, and the programs he uses, what
amount to a virtual machine within a real one."

"Operating systems are thus interfaces between applications and the
machine. This is why all physical processes (access to external or
internal peripherials, memory acess etc.) are delegated to the operating
system. This encapsulation of the physical layer, and its diversity, frees
developers from teh complexit of managing all the existing peripherals. The
operating systems take care of all this."

2.2.4 Resource management

"On general, the operating system is charged with managing the available
computer resources, of which the processor and the memory are particular
instances.
This function provides processes with an interface allowing resources
(such as disks, printers, etc) to be shared. It implements a protection
system which allows users and system administrators to protect access to
their data.
The system keeps a list of resources avalible and in use, which allows
it to attriubute them to processes which have a need for them. At any
given moment the system is aware of which processes are using machine
resources and can thus detect conflicts of access"
--------------------------------------------------------------------

The current graphics solution for linux doesn't embody these ideas. The
current solutions do not provide a layer of protection. Instead it relies
on setuid libraries to protect us. Their is nothing wrong in this
approach as long as you make sure everyone uses that library and
don't want to write their own thing. This means making sure no one but
the library can touch the driver. This prevents people who want to do
their own thing from not damaging the hardware. Make sure the library is
totally perfect and can't damage hardware. Make sure if someone does
their own thing it can get along with everyone else. Its just a different
way of doing things. I'm surprise no one has writing a setuid userland
library that handles access to the raw hard drive thus moving the VFS to
userland. I bet you would get huge performace gains this way. It could be
done. Why its not done is because its not the UNIX way. But it doesn't
stop anyone from doing this. The reality is their will always be people
that want to do their own thing. You can't stop them but you can protect
them from hurting themselves.

2. As I pointed out its not safe or secure. I know their is no such thing
as a perfect secure system except for a machine off line. That will always
be true. Its on thing if the cracker breaks in formats your hard driver,
shuts down your network connection, change your web page, or even reboots
the machine. Its another thing when a remote person could break in and
damage your physical hardware. This should never happen. I picture having
linux where the only way a user could damage the hardware is if they shot
it with a shotgun. Having the layer of protection of the kernel helps
out. No its not perfect. Thats why when I was a system admin I never
allowed modules. If someone gets root they could create their own module
and fry the system. Are modules bad? No, I use them to debug drivers all
the time. But for machines that are live I would never. So the point is
what is more important to you. A secure, stable system or having maximum
performace without out this.

Use DRI if you never will program the video card yourself and your
machine will never be on line so someone can break in and damage your
hardware.
Don't use DRI or be warned that using it can be dangerous if you are
online and someone can break in and damage your system or if you want to
write your own graphics software. The choice should be up to the public.

P.S
Their has been talk about porting a Direct X clone to linux. So as you
see their are other things besides OpenGL that will need to use the
graphics engine.

James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net

-
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/