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

[archkde]

If it only were this simple...

I know it's not at all simple to pull this off in practice. I also know that I lack the relevant skills, as I already wrote (in fact, I'm not a professional programmer at all). I can only daydream and write what I think would be possible. I do not demand anyone to implement any of these ideas either.

[karolherbst]

I know it's not at all simple to pull this off in practice. I also know that I lack the relevant skills, as I already wrote (in fact, I'm not a professional programmer at all). I can only daydream and write what I think would be possible. I do not demand anyone to implement any of these ideas either.

that's not the point. It just ignored actual real world problems, like what if the device can't be reset and all those details. Some issues can only be resolved by rebooting and no software as perfect as it may be will be able to solve this.

[sinepgib]

Long ago, you could make that distinction, yes. These days, X11 and X.org are used pretty much interchangeably.
The thing is, this unmaintained pile of poor quality code, not only works where Wayland implementations are still WiP, but it also does things Wayland doesn't because "it's not the compositor's job".

It doesn't change the fact X11 is the protocol and you could implement a different one. Whether we ended up in a monoculture of a single implementation is irrelevant. If you argue Wayland is just a protocol, X11 is too. The only valid comparison with regards to repetition is not in the server, but on WMs being a separate entity that should run on any server (which is not minor, and the open source landscape has a history of making a fragmented mess so there's a real need to be careful with Wayland).
Note I'm not saying Wayland is either better or worse than X11, each have their use cases (for mine, I think Wayland is better). But X.org maintainers tend to complain themselves about its code quality, so I'd rather take their word for it.

[rastersoft]

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.

I think that BeOS used the same idea. But don't take my word for sure...

[archkde]

[QUOTE=sinepgib;n1356177]

If you actually have those ideas you can probably program, it's a matter of time (not that it's easy to find the time really). You may use an existing microkernel as a base.
[/QUODE]

Well, I can program in the sense that given enough time, I can produce a userspace program that solves a(n easy enough) task. Not in the sense that it doesn't devolve into an unmaintainable spaghetti mess past 1000 lines of code. And forget about kernel space. Also I'm not really sure how much starting with an existing microkernel and then ripping out its IPC system would help, since there would not be much left.

This is a bad example IMO. You would need to make sure to reap references to the USB stack from other places. Think your VFS server that thinks there's still a pendrive connected. It's not really trivial to handle I think.

In this case, I think the kernel could post a "sender disconnected" reply to the VFS server, which it would then handle much like "pendrive was ripped out". That's one of the advantages a microkernel OS has over an actual distributed system.

These are much better examples as their functionality is much more self-contained (and there are actual user space implementations able to run on Linux IIRC, check out lwip).

Sounds interesting, I will check that out.

OK, but for this part it doesn't matter whether your design is monolithic or not.

Right, that was more of an aside. Although I guess there are some languages that are much better suited to userspace than to the kernel, I probably wouldn't want to write drivers in those either way.

[guiodic]

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

Yes, Xorg is fine. Modesetting DDX is a piece of Wayland imported in Xorg (like libinput and so on). Standard DDX drivers (pre-Wayland era) have not problems like this.

[MastaG]

This would've never happened if the whole kernel and Xorg stack were written in rust.

[Volta]

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.

Ironmask already explained. Your 'explanation' why monolithic kernels won is just out of scope of being silly. There are others who have skills, but they failed, because microkernels are brain dead design. Let's waste performance, code readability, energy just because.

[sinepgib]

Well, I can program in the sense that given enough time, I can produce a userspace program that solves a(n easy enough) task. Not in the sense that it doesn't devolve into an unmaintainable spaghetti mess past 1000 lines of code. And forget about kernel space. Also I'm not really sure how much starting with an existing microkernel and then ripping out its IPC system would help, since there would not be much left.

You don't need to out right strip the older one tho. You can add the new way so you have a mostly working system that you can gradually convert to test the ideas. Of course that won't lead to an actual production-ready kernel, but you get to try out the novelty so it might catch somebody's eye.

In this case, I think the kernel could post a "sender disconnected" reply to the VFS server, which it would then handle much like "pendrive was ripped out". That's one of the advantages a microkernel OS has over an actual distributed system.

But that would start inserting logic into the kernel that you should be careful about. Maybe the generic connection close could suffice tho. I think MINIX does track the IPC channels between processes.

Right, that was more of an aside. Although I guess there are some languages that are much better suited to userspace than to the kernel, I probably wouldn't want to write drivers in those either way.

Yeah, buuuuut some drivers may be implementable in higher level languages if those are efficient, such as Lua. I think that's the nice part of having userspace servers actually, you don't need to restrict yourself to the restrictions you have on a kernel.

[archkde]

that's not the point. It just ignored actual real world problems, like what if the device can't be reset and all those details. Some issues can only be resolved by rebooting and no software as perfect as it may be will be able to solve this.

That's actually a good point, I would need to think about how I would solve this problem (probably by keeping a minimal amount of state in a separate driver and making sure *that* really doesn't crash). Still, I guess it's better to at least gracefully shut down everything else instead of crashing the entire kernel and corrupting data outright.