←back to thread

John Carmack's arguments against building a custom XR OS at Meta

(twitter.com)
520 points OlympicMarmoto | 6 comments | 29 Aug 25 16:45 UTC | HN request time: 0.002s | source | bottom
Show context
jnwatson ◴[29 Aug 25 17:46 UTC] No.45067216[source]▶
I've written a lot of low level software, BSPs, and most of an OS, and the main reason to not write your own OS these days is silicon vendors. Back in the day, they would provide you a spec detailed enough that you could feasibly write your own drivers.

These days, you get a medium-level description and a Linux driver of questionable quality. Part of this is just laziness, but mostly this is a function of complexity. Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.

replies(13): >>45067491 #>>45069282 #>>45069287 #>>45069349 #>>45069690 #>>45070345 #>>45071036 #>>45071086 #>>45072259 #>>45072391 #>>45073789 #>>45075476 #>>45081942 #
andreww591 ◴[30 Aug 25 01:03 UTC] No.45071036[source]▶
At least for certain types of OSes, it should be relatively easy to get most of Linux's hardware support by porting LKL (https://github.com/lkl/linux) and adding appropriate hooks to access hardware.

Of course, your custom kernel will still have to have some of its own code to support core platform/chipset devices, but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers).

Also, it probably wouldn't work so well for typical monolithic kernels, but it should work decently on something that has user-mode driver support.

replies(1): >>45071106 #
1. snickerbockers ◴[30 Aug 25 01:18 UTC] No.45071106[source]▶
>but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers).

thus calling into question why you ever bothered writing a new kernel in the first place if you were just going to piggyback Linux's device drivers onto some userspace wrapper thingy.

Im not necessarily indoctrinated to the point where I can't conceive of Linux being suboptimal in a way which is so fundamental that it requires no less than a completely new OS from scratch but you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch.

replies(4): >>45071257 #>>45072209 #>>45072630 #>>45073243 #
2. andrekandre ◴[30 Aug 25 01:52 UTC] No.45071257[source]▶

  > you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch.
thats in interesting point, and makes me wonder if some kind of open interface for drivers to write to (and os's could implement) wouldn't be worthwhile?

probably it would have to be very general in design, but something along the lines of driverkit or iokit might work?

replies(1): >>45072167 #
3. pjmlp ◴[30 Aug 25 05:46 UTC] No.45072167[source]▶
That is how all OSes with binary drivers kind of work.

However it goes into the same direction of the previous commenter, device drivers are intertwined with the OS semantics, even on microkernels, so eventually it ends being just something like POSIX.

4. eru ◴[30 Aug 25 05:54 UTC] No.45072209[source]▶
You make a good argument, but let me take the other side:

What you describe is probably necessary for getting _fast_ Linux compatibility. However, if you are willing to take the overhead of a few layers of indirection, you can probably sandbox the Linux land somewhere, and not have it impact the rest of your design much.

Most hardware access doesn't have to be particularly efficient. And, yes, for the few pieces of hardware that you do want to support efficiently (eg your storage devices or networking, whatever you want to concentrate on in your design) these you can handle natively.

Btw, I would suggest that most people these days should write their toy operating systems to run as a VM on a hypervisor like Xen or similar. The surface to the outside world is smaller that way.

5. PeterStuer ◴[30 Aug 25 07:25 UTC] No.45072630[source]▶
Is this the old 'an OS is just a bag of buggy device drivers' argument?
6. lelanthran ◴[30 Aug 25 09:28 UTC] No.45073243[source]▶
If you're going this route, I have found netBSD a better option for this sort of thing.

It has a rump kernel architecture which makes reusing the drivers almost trivial compared to reusing linus drivers with a new kernel.