The Linux Kernel Has Been Forcing Different Behavior For Processes Starting With "X"

[skeevy420]

Xorg is fine they say. No need for Wayland they say...

How is the kernel having a bad workaround for supposedly depreciated software the fault of the depreciated software and not the fault of the kernel? How is this even Xorg vs Wayland?

Just look at proprietary systems that are so stupid that a certain company and its programmers, I'm not gonna name names, but we all know who I'm referring to, that had to skip version number 9 for their operating system because the kernel and tooling might assume it could be for the 95 or a 98 version and not the new 9 version because some of their stuff doesn't even check past the first digit in the version number.

I say yay for open source and multiple eyes being allowed to review and fix code. Yeah, sometimes quick, possibly bad, decisions are made, but at least it's all open for review, scrutiny, and fixes...unlike those other fine peoples' work.

[Ironmask]

Classic example of Linux-quality code.

I'd say the usual stuff about crap running in supervisor mode and microkernel multiserver systems being the way forward, but effort.

How is a workaround for a common graphics stack in drm/atomic in any way shape or form related to or fixed by a microkernel?
This isn't even an issue of stability or modularity, it was a goofy workaround for unmaintained but critical external code.
Your post is either a non-sequitur, or you don't actually know what a microkernel is.

[kpedersen]

How is the kernel having a bad workaround for supposedly depreciated software the fault of the depreciated software and not the fault of the kernel? How is this even Xorg vs Wayland?

Plus doing a check for 'X' is going to be much nicer than; 'm'utter, 'k'win, 's'way and all the individual compositors that will all individually have bugs in their deep underlying layers that they have had to reinvent the wheel with. Because presumably many of these will also need that modesetting hack.

[marios]

I hope that Linus accepts it.

Don't keep your hopes up. The more sane a patch is, the fewer the chances are that Linus accepts it.

[archkde]

Classic example of Xorg quality, but morons praising microkernel brain dead design have no clue as usual. Tell me why there's no single use case for your broken by design piece of shit microkernel? Just don't come with 'layers between OS and hardware' examples. I want examples of real world usage and performance of this broken by design POS. Oh, and why even OpenBSD doesn't give a shit about your crap?

Somehow, all of you whining about microkernels being "brain dead design" make me want to write my own microkernel-based OS even more. Monolithic kernels only won because the kernels that existed at the right point in time to be successful happened to be monolithic. Sadly, I don't have the extreme amount of skill required to write an OS to prove you wrong, but you probably wouldn't care either way.

[marios]

How is the kernel having a bad workaround for supposedly depreciated software the fault of the depreciated software and not the fault of the kernel? How is this even Xorg vs Wayland?

Just look at proprietary systems that are so stupid that a certain company and its programmers, I'm not gonna name names, but we all know who I'm referring to, that had to skip version number 9 for their operating system because the kernel and tooling might assume it could be for the 95 or a 98 version and not the new 9 version because some of their stuff doesn't even check past the first digit in the version number.

I say yay for open source and multiple eyes being allowed to review and fix code. Yeah, sometimes quick, possibly bad, decisions are made, but at least it's all open for review, scrutiny, and fixes...unlike those other fine peoples' work.

If this is true:
0. You learn something interesting every day.
1. A certain company will soon have to resort to non-printable ascii characters for versioning. They have already used '1', '2', '3', '7', '8', '9', 'M', 'N', 'V' and 'X'. Maybe I am still forgetting something. I would love to see them name a version "beep" (not the word, the sound)...

[Ironmask]

Somehow, all of you whining about microkernels being "brain dead design" make me want to write my own microkernel-based OS even more. Monolithic kernels only won because the kernels that existed at the right point in time to be successful happened to be monolithic. Sadly, I don't have the extreme amount of skill required to write an OS to prove you wrong, but you probably wouldn't care either way.

I don't think you realize the overwhelming amount of microkernels there are.
Redox is a microkernel. L4 is a microkernel. You don't have to make a microkernel at all, they exist in copious quantities. Did you write this post under some strange assumption that microkernels are entirely theoretical?
An OS is useless by itself, which is why nobody uses them. You need drivers, otherwise the OS is literally just a mundane abstraction with nothing to abstract. That's why nobody uses anything besides Linux and Windows, all the drivers are for those.
Your comment about why monolithic kernels are successful is also incredibly ignorant. Windows is a hybrid design based off a microkernel design but simplified for performance reasons. Linux just happened to be at the right place at the right time, it was actually inspired by Minix, a microkernel, but Linux was just more popular with hobbyists. Linux is also a hybrid design these days, so actually, there are no popular strictly monolithic OSes anymore.
The simple fact of the matter is, a microkernel is useless. It doesn't matter if critical OS drivers like the disk controller or USB stack crash. Either they hard crash the OS because they're in kernel mode, or they politely ask the OS to shut down because they're in usermode but still critical to the OS to actually do it's job (there are many usermode components in Windows that do this). The only thing that really needs to be in usermode is third party drivers, for stuff like graphics cards and printers, which both Windows and Linux do. That provides you all the stability you need, anything more than that is needlessly excessive and an unwarranted engineering effort.

[justinkb]

I'm not a C dev, but doesn't

 && req->value == 1

mean that only a process named "X" would enter in this condition?

I'm not saying it's not a questionable solution, but if it's true then maybe it didn't affect as many processes as they thought.

no, it does not mean anything of the sort, this isn't a check on the length of the process name or something? req->value is an unsigned 64-bit integer value that corresponds to the value to set for the capability, in this case the atomic cap. it can only be 0 (incapable) or 1 (capable). the "&& req->value == 1" simply makes it so the function errors out with -EOPNOTSUPP and a info message if atomic cap is trying to be enabled for these X* processes. there is no issue if the function is trying to set atomic cap off, so then it doesn't need to error out and print that message. only the first character of the process name is checked.

[r_a_trip]

Somehow, all of you whining about microkernels being "brain dead design" make me want to write my own microkernel-based OS even more. Monolithic kernels only won because the kernels that existed at the right point in time to be successful happened to be monolithic. Sadly, I don't have the extreme amount of skill required to write an OS to prove you wrong, but you probably wouldn't care either way.

The trouble with most microkernels is the IPC overhead. Pass a message, wait for the scheduler to switch cpu control to the other process, pass a message, wait for the scheduler, etc. Making most implementations significantly slower than a monolithic kernel.

AFAICT, the only succesfull microkernel OS that solved that particular problem is QNX, which tightly integrated message passing with cpu scheduling, thereby reducing unnecessary cpu cycles switching between processes. Pass a message, if the receiving process is waiting for it, give waiting process control over the cpu. Cuts out a lot of back and forth.

Have other microkernel OSes copied this behaviour? The patents should have expired by now, as QNX was initially released in 1982.

[Ermine]

Xorg is fine they say. No need for Wayland they say...

As if one cannot code broken atomic handling into Wayland compositor.