Comments on: Graphics into the kernel?

By: alcer123

alcer123 — Wed, 30 Nov -0001 00:00:00 +0000

I was thinking, is this the same thing MS did to its OS? Then. whenever the graphics break, th IS is tosted. i would think that making both the X server, and the kernel, work together better will be the route to go, but I am not an expert on this field.

By: yohance

yohance — Wed, 30 Nov -0001 00:00:00 +0000

i would have to agree witn alvaro on that…

By: sgopi

sgopi — Wed, 30 Nov -0001 00:00:00 +0000

I think there must be seperation of handling Graphics which is a complicated and its a seperate area.

Interface to access the hardware directly must be developed something like what Hypervisor does
for Virtual machines.

Thanks,
S.Gopinath

By: gussyman

gussyman — Wed, 30 Nov -0001 00:00:00 +0000

IMHO the graphics should stay out of the kernel, just to prevent situations when the system hangs because of that.

I’m not very familiar with what happens right now in the graphics system, but when my X hangs (very rarely although I have activated the composite manager) I just restart it with a simple Ctrl+Alt+Del and it just works again. Plain and simple.

By: pgoetz

pgoetz — Wed, 30 Nov -0001 00:00:00 +0000

“when my X hangs … I just restart it with a simple Ctrl+Alt+Del and it just works again.”

I think you mean Ctrl-Alt-Backspace? In any case,
I rarely encounter a situation any more where an X freeze can be fixed by simply restarting X from the keyboard. Usually the keyboard focus is gone and I end up having to log in to the machine remotely to kill X, which is a royal PITA. Despite a very generic install of Ubuntu 7.04, OpenOffice 2.x regularly freezes the X server on my machine, necessitating a remote restart. There is absolutely no circumstance in which a user application should be able to take down the server — period. There is no question in my mind that a lot of this insanity would simply go away if we “Render Onto Caesar What Is Caesar’s”, namely let the kernel manage the hardware like it is supposed to do given the barest minimum definition of what any kernel, even a microkernel, is supposed to do. To that end, I completely agree with the writer of this article that the X/linux situation is an unholy mess that needs to be straightened out. In my experience linux is an order of magnitude more stable than Windows; linux + X is an order of magnitude LESS stable — that is simply intolerable.

By: juangiordana

juangiordana — Wed, 30 Nov -0001 00:00:00 +0000

When X freezes most of the time I’m unable to kill the X server because the keyboard gets locked. I agree with the fact that having to log in remotely to kill X is a pain… and honestly … I prefer to hit the reset button like any normal user would do instead of playing the SSH guy. That’s kind of unacceptable.

By: jjourard

jjourard — Wed, 30 Nov -0001 00:00:00 +0000

Wanting to keep the kernel pure and clean is intellectually very appealing. If we had remained in a test-based world, I would be totally onboard with keeping any kind of graphics stuff out of the kernel. But outside of headless servers, you just have to deal with graphics issues every day, X is here to stay. Given that basic truth, I am very ready to accept into kernel space the limited and simpler slice of the graphics pie that Arajan describes. When X freezes, we truly are hosed, there’s no direct way to slap the system back to its senses. I accept this smaller intrusion into the kernel as the best way to deal with a constant headache.

By: jjourard

jjourard — Wed, 30 Nov -0001 00:00:00 +0000

…If this became standardized, maybe something trick from Intel would have a little corner of hardware either on the die (fat chance) or in the chipset to make the graphics-in-the-kernel method callable with even less resource allocation inside the kernel, maybe just a few flags? I am no hardware guy, as must be obvious to the chip guys right now, but the concept seems reasonable enough to me.

By: beerse

beerse — Wed, 30 Nov -0001 00:00:00 +0000

From my unix knowledge, I'd say that the kernel is the place for the drivers. So it should at least provide a general way to talk to devices. On unix level, there are character devices like tapes and the console (/dev/tty). I'd say a graphical display compares to a character display as a disk-device compares to a tape-device. Hence for the kernel, a graphics device should be a block-device. That makes the frame-buffer device a kernel device.

However, the way X11 is designed and the way it behaves, I can even say that X11 is a kernel on its own. X11 can use the framebuffer device, It can also use the device as it is provided by the kernel. However it does not need to: look at vnc on unix, the binary xvnc has nothing to do with the local hardware display.

On the other hand, what to use as the protocol to use between the device as the os-kernel is and the X11 server? What was wrong with the postscript as was used with SunOS? It might just be to much overhead (and/or to slow) Or should we use the X11 protocol itself?

Then the X11 server could/should be the device-driver in the kernel. Then the devices can be /dev/${DISPLAY}, similar to /dev/tty for character devices.

By: leelofgren

leelofgren — Wed, 30 Nov -0001 00:00:00 +0000

The graphics system must stay separate from the kernel to ensure that the kernel doesn’t crash. I disagree with jjourard in his statement that graphics is here to stay. Most of my Linux boxes are not running X Windows by default. I use startx when I want to use X Windows, then shut it down when I am done to save on resources and reduce attack exposure. I even shut it down on my desktop because it frees up resources that X Windows doesn’t always free up on it’s own. Can’t the graphics hardware/software interface be executed in a separate kernel process, isolated from the actual kernel? I think that the Graphics hardware/software interface should be virtualized in such a way that video hardware vendors can drop in OpenGL drivers with direct access to the underlying hardware without having to compile their drivers into the actual kernel. Maybe, this way, OpenGL won’t be left on the sidelines, and the graphics sub-system can become more stable as well, while the underlying kernel will stay stable.