The Fight Over Merging Drivers Back Into X Server

[crazycheese]

With drivers integrated, you'll need to recompile xorg each time you want different driver support - same as linux kernel.
While it will remove the need to install drivers along, it will complex the Xorg code and make it harder to debug, which means slower cycles, which means they will eventually end up into stripping "unneeded stuff". Like aiptek tablets for example. I have one. Someone had vodoo and was proud to run it in linux. Sure, I will need to step in and pay for aiptek driver re-invention.

Developers are doing their thing anyway. Except up to the point they disagree on what is correct: is it a half filled glass, or is it a half full glass.

They start debate, which ends somewhere when Hitler is mentioned and everyone is angry and no code is written; or even funnier - project is forked or dismembered. Now you have two Xorgs.

It is glass of enough capacity to carry water. Move on.

[Sidicas]

Call me late to the party, but I was very surprised when the drivers moved from Xorg to the kernel to begin with...
I remember asking about the structure of XServer 5 years ago and the answer I kept getting back again and again was that it was a horrible idea to build things into the kernel because it just adds more opportunity for serious security exploits of the operating system and that if it could be built outside of the kernel then it should stay outside of the kernel..

With programmable GPUs and code executing on GPUs today, I can't imagine that it's any safer now than it was 5 years ago.. So I don't understand what has changed where everybody wants to shove all this code into the linux kernel instead of leaving it as part of Xorg. 5 years ago people were saying that Linux was so much better because XServer *WAS* so far detached from the kernel of the OS and it was more secure because of it....

So..uhhh.. What has changed to push all that code into the kernel to begin with?

I guess the people who were arguing that all code that *could* be outside of the kernel *should* be outside of the kernel (for security reasons) were wrong?

[bridgman]

AFAIK this discussion is about (previously) moving X driver source code into separate trees from the X server source code, and (proposal) moving all the X driver source back into the X server tree. Nothing to do with moving code from X driver to kernel driver and back. I think.

[elanthis]

Call me late to the party, but I was very surprised when the drivers moved from Xorg to the kernel to begin with...
I remember asking about the structure of XServer 5 years ago and the answer I kept getting back again and again was that it was a horrible idea to build things into the kernel because it just adds more opportunity for serious security exploits of the operating system and that if it could be built outside of the kernel then it should stay outside of the kernel..

The only drivers that are in the kernel are the parts that _must_ be in the kernel for things to work. The kernel needs to know how to set modes and do basic GPU management for its own purposes (power management, vt support, debugging, etc.) hence KMS/GEM/TTM are part of the kernel. The kernel needs to _add_ security by arbitrating what users can do what operations to what memory regions on the GPU (previously any user space app could **** your GPU in the face by submitting horrible, illegal, dangerous instructions), hence the command queues being in the kernel. Everything else still lives in user space, including all the millions of lines of state management and shader compilers and command stream building and instruction schedulers and so on. All of the core logic of the GPU drivers regarding actual rendering is all in a user-space library (or libraries) distributed as part of Mesa and Xorg.

With programmable GPUs and code executing on GPUs today, I can't imagine that it's any safer now than it was 5 years ago.. So I don't understand what has changed where everybody wants to shove all this code into the linux kernel instead of leaving it as part of Xorg.

The mode-setting cruft is the only thing that moved or will move from Xorg to the kernel. The memory management and command queue checkers are new pieces that never existed outside of the kernel in the first place (Xorg never had those features, ever). Everything else that the actual developers (not the doofuses on the forum here) are talking about is moving the remaining driver cruft from Xorg to Mesa/Gallium, keeping it all in user-space. That would make Xorg be just a protocol implementation of a display server with no hardware-dependent code and would centralize all of the hardware-specific userspace code into one project, usable by everyone. All of the meat of the super complex graphics drivers remains in user-space.

5 years ago people were saying that Linux was so much better because XServer *WAS* so far detached from the kernel of the OS and it was more secure because of it....

Which is still and always will be the case. Nobody (who actually matters) is suggesting otherwise.

[movieman]

The only thing X12 gives you is an opportunity to change the API - which is exactly what Wayland also gives you.

Wayland also costs you network transparency, which is a huge benefit for X. Computers are becoming more and more networked, yet Wayland wants to tie the display to a specific computer.

[smitty3268]

Call me late to the party, but I was very surprised when the drivers moved from Xorg to the kernel to begin with...
I remember asking about the structure of XServer 5 years ago and the answer I kept getting back again and again was that it was a horrible idea to build things into the kernel because it just adds more opportunity for serious security exploits of the operating system and that if it could be built outside of the kernel then it should stay outside of the kernel..

With programmable GPUs and code executing on GPUs today, I can't imagine that it's any safer now than it was 5 years ago.. So I don't understand what has changed where everybody wants to shove all this code into the linux kernel instead of leaving it as part of Xorg. 5 years ago people were saying that Linux was so much better because XServer *WAS* so far detached from the kernel of the OS and it was more secure because of it....

So..uhhh.. What has changed to push all that code into the kernel to begin with?

I guess the people who were arguing that all code that *could* be outside of the kernel *should* be outside of the kernel (for security reasons) were wrong?

Entire drivers were never moved into the kernel. Modesetting was. That's just the part of the driver that does the actual communication with the hardware, which is exactly what the kernel is designed to do. It really doesn't make any sense to have that code anywhere else, and that code is not being reintegrated into Xorg.

The entire GL API, 2D acceleration API, etc. is still completely userspace and that also makes sense. That kind of code is where you'll find tons of security issues with, and it takes a ton of code to implement.

So I suspect you are a little confused here. When you asked if drivers would be moved into the kernel, I suspect the answers you got were talking about the *entire* drivers, which definitely shouldn't be in there. And still aren't.

The drivers they are talking about moving into Xorg are just the OSS drivers which are seperately installed now. Instead of being seperate packages, you'd get them all at once with XOrg instead of individually.

[smitty3268]

Wayland also costs you network transparency, which is a huge benefit for X. Computers are becoming more and more networked, yet Wayland wants to tie the display to a specific computer.

This is wrong in so many ways, and its all been gone over 1000 times before on this very website.