Tilck – A Tiny Linux-Compatible Kernel | Hacker News Reader

Tilck – A Tiny Linux-Compatible Kernel

github.com

270 pointsgjvc74 comments

A Linux-compatible kernel under a BSD license is intriguing :)

Jokes aside, this looks great as an educational project, because you can run real Linux software on this kernel, from Vim to Doom.

Things will become really interesting once this gets ported to ARM. There is a serious amount of MCUs with 4 MB of RAM where Tilck should run fine, but even Yocto or OpenWRT won't fit.

> A Linux-compatible kernel under a BSD license

I mean, in all seriousness, NetBSD and FreeBSD both have binary compatibility layers to run Linux programs

I really was hoping that this Tilck is a microkernel, otherwise i don't see any point compared to Free or NetBSD.

But maybe it's just there because it's fun...and that's absolutely ok.

The comparison was due to the licence. Both Net and FreeBSD have monolithic kernels in the style of Linux. (Or more properly, Linux is in the style of the BSD kernel.)

>The comparison was due to the licence.

Thanks Sherlock.

> I really was hoping that this Tilck is a microkernel

It says right there on the homepage in the link:

« What is Tilck?

Tilck is an educational monolithic x86 kernel »

That answers both your points.

My third point was fun, so that makes your answer unnecessary ;)

No, not really. It specifically addresses a useful purpose -- education -- meaning that no, it's not just for fun.

>meaning that no, it's not just for fun.

As if you know what fun is ;)

Why do people always go ad-hom?

:-(

See, that's what i mean...

Be happy and have a great day.

Let's summarise here.

You:

[1] apparently didn't read the link and asked foolish questions about it.

[2] I answered your questions.

[3] You attacked me and questioned its usefulness.

[4] I answered that too.

[5] You attacked me again and mocked me.

[6] And now, it's not really clear to me, but you are blaming me for being unhappy that you attacked me?

I don't know if it is possible to block people on HN, but for you, I will try to find out, because you personally have both wasted my time and made my weekend noticeably less pleasant, and now you are mocking me.

Chill bro, no need to get argumentative in a environment where mostly answers arent even read properly

FWIW, someone downthread linked to one that is: https://news.ycombinator.com/item?id=34296258

If you’re learning, having a direct implementation vs multiple layers of abstraction is a huge benefit.

Without networking support (not even sockets), not being ported to ARM is the least of the tasks.

MCUs with just 4MB of RAM may not even have IP based networking.

Unless you want really high performance networking, you don't need tons of RAM to implement it. ESP32-based MCUs are known to implement Wifi + TCP/IP + TLS [1] on 1-2MB of RAM. This is, of course, without a Linux-compatible kernel.

Much RAM is not needed if most of your code resides on the flash and runs directly from there.

[1]: https://github.com/espressif/esp-idf/tree/master/examples/pr...

2KB SRAM. ~1-2ms TCP setup + HTTP round trip, ~500-1000 requests/sec. Guess the MCU.

Atmega328P?

Knew someone would get it in one :)

If the slowness wasn't hint enough, the 2KB SRAM was a dead giveaway.

When I was your age, I sent 24 people to the actual moon with my software in 4K of RAM and here I am clicking your button and it takes ten seconds to load a 50 megabyte video ad and then it crashes. - @natecull, on Margaret Hamilton perspective

I work with a 2MB MCU, and run IP networking on it (in Python, no less). IP doesn't need very much RAM.

Sure, it's tilck that doesn't implement it. :)

You can run IP based networking on machines with well under 1MB (smallest I've personally a basic graphical web browser on would have been a 512KB Amiga)

on NXP K60 with FreeRTOS and lwIP IP based networking runs without problems with 256k Flash and 64k RAM. Of course it depends on the application, because the throughput is not high, but that is not the point here

We are doing IPv6 networking on MCUs with just 32k RAM.

finally, a secure operating system

Just like MS-DOS!

Porting to RISC-V would make sense.

Porting to ARM is not a priority, and ARM could fund it if they cared.

> A Linux-compatible kernel under a BSD license is intriguing :)

> Jokes aside

If you just were. That project uses indeed a BSD license. Isn't that making it unnecessarily hard on oneself as one then cannot 'borrow' Linux kernel code, including drivers?

You can still borrow code for a private test suite to compare behaviors.

> [..] in kernel mode while retaining the ability to compare how the very same usermode bits run on the Linux kernel as well. That's a unique feature in the realm of educational kernels.

There's also Kerla: https://github.com/nuta/kerla

Somewhat related, Managarm[0] also attempts to be Linux compatible, but has a microkernel, multiserver design.

0. https://github.com/managarm/managarm

Nice to see managarm mentioned! managarm does have vastly different goals though, as in running Linux software unmodified (i.e. compiled from source, not necessarily binary compatible due to ABI differences) on a fully async microkernel, including desktop apps a user might find useful for general-purpose stuff. Currently, we run weston (the wayland reference compositor) and have support for Xwayland and some graphical applications (as both Qt and GTK are ported). However, there's still a large part of Linux' API surface to be covered, so support will only improve with time.

Does managarm run on raspberry pis?

We’re working on support for raspberry pi 4 at this moment, and on emulated AArch64 targets we can boot into Weston, but our primary platform is x86_64.

Has any work been done for RV64GC?

Tilck – Tiny Linux-Compatible Kernel - https://news.ycombinator.com/item?id=28040210 - Aug 2021 (7 comments)

It seems we are more and more at taking a shot at kernel dev, I mean a full kernel.

What is really annoying with linux (and *BSD), it is their dependence on gcc/clang. It is not C, it is a dialect of C using too many bazillions gcc extensions. It means in the long run, we are hit straight in the face with planned obsolescence from C syntax, as ISO tantrums(c11/c17/c7489374893749387) or some ultra-recent gcc extensions ("sorry, you need THIS extension only available in gcc from 2 weeks ago").

I have been coding assembly lately, and being independent of those compilers gives me an exhilarating feeling of freedom.

Who said 64Bits RISC-V assembly written (with a conservative usage of a preprocessor) linux compatible enough kernel which runs the steam client, dota2/csgo and those horrible "modern" javascripted web browsers (I personnaly use only noscript/basic (x)html browsers)? Would even be fine for a self-hosted mini server (email, personal web/git(mirrors) site, p2p, all ipv6 to avoid that disgusting ipv4 NAT, etc).

To stay real, I would go incrementaly: I would start slowly by moving back some linux code to real C (namely _NOT_ compiling only with gcc/clang, and this will be hard), port some code paths to assembly, probably x86_64 at first then 64bits RISC-V would follow (and why not ARM64).

I am more than fine with linux GPLv2, actually, I would provide the "new" code under affero GPLv3 with a similar linux "normal" program exception (but more accurately defined, to target drivers in userspace and stay explicitely ok with closed source userspace programs using those drivers) _and_ as linux GPLv2(and more based on their author wishes) to be legal with re-used linux code.

Doesn't Linux compile under clang/llvm now?

https://www.openmandriva.org/en/news/article/openmandriva-lx...

>>OpenMandriva Lx is a unique and independent linux distribution, a direct descendant of Mandriva Linux and the first Linux distribution utilise the LLVM compiler

In fact, it does. [1]

[1] https://clangbuiltlinux.github.io/

Google was shipping clang kernels on Chromebooks in 2018 https://www.phoronix.com/news/Google-2019-Clang-Kernel

I feel like I read a post saying all patches for clang have been merged but my Google-fu seems to be lacking.

Yes, after Google spent the resources to make it happen for Android/ChromeOS.

So it used to be possible to compile a (lightly patched?) Linux with tcc, which was part of the really cool "live disk that compiles linux and then boots it in a matter of seconds" demo[0]. I think the problem is that kernels (need to!) care about extremely precise implementation details that most programs don't need; things like "this data structure of exactly this many bytes must be placed at this exact memory address with this exact alignment, then we need to set the CPU registers to this exact list without touching the stack, then run this CPU instruction to make the hardware do the action we just staged", and they care about doing so with good performance, and AIUI, spec-based C either can't do all the things that modern OSs want, need you to jump through a lot of unergonomic hoops, or don't get the performance that people want. Hence, compiler extensions to do what the kernel wants to do while minimizing undefined behavior but keeping performance. Honestly, the fact that every major OS (I specifically know about Linux, every BSD, illumos nee Open/Solaris, but I'd be shocked if NT/Darwin were different) needs to extend the compiler is probably a glaring criticism of the C standard.

[0] https://github.com/seyko2/tccboot

It means that in the end, maintaining duplicated assembly code paths for different ISAs would have been cheaper and much easier than the absurdely complex linux+gcc(or clang) duo. And I could bet than some code paths could be kept in simple and plain C (compiling with _not_ only gcc/clang) without that much loss of performance.

All that is a very strong case for RISC-V.

Erm. So that's a language/compiler issue, nothing to do with the ISA? And I might be on board with embedding assembly, but AFAIK that also requires compiler extensions. And I'm not an expert on compilers or C, but I suspect that still doesn't cover all the uses of compiler extensions.

The issue is the compiler/language.

Since RISC-V should be an international standard for assembly level interoperability, that removes in a reasonable way this "compiler/language" issue ... until no technically very expensive code generators/code preprocessors are used since those would not be that less worse than an optimizing compiler.

Write RISC-V assembly once, run anywhere.

The cherry on top, RISC-V ISAs do not have toxic IP tied to them, like x86_64 or ARM, and that at a worldwide level.

I would be ready to pay the price of losing some speed on C code paths until I can compile them with "toy"/small/alternative compilers which are not gcc/clang, BUT I cannot even do that since linux code is hard dependent on gcc extensions.

No need of compiler extensions for external Assembly modules, just as it used to be quite common a couple of decades ago.

IMhO, experimental OSes greatly benefits from supporting _some_ way of running _some_ Linux binaries - it solves the bootstrap problem and makes it so much easier to explore the system.

OT: I always felt the synchronous system call model is very dated. All high performance systems I know of (say, GPUs, NVMe, NFSv4, etc) all use a similar async command list model. Each exchange package up as much as possible and more work is done per context switch. Instead in Linux we just get an ever growing list of compound system calls (like pwritev, pwrite64, renameat). There's some hope with io_uring and ebpf, but it really should just be general mechanism. There's no need for a context switch outside of exceptions (like page fault) or blocking on completions for commands.

What do you mean by a 'compound' system call out of interest? Something that should by rights be split into multiple simpler calls?

Those system calls shown as examples pass a list of buffers to be read into / written from.

[1] https://man7.org/linux/man-pages/man2/readv.2.html

Isn't io_uring that general mechanism?

One could probably implement a Linux-compatible kernel that only implements io_uring (and only whatever sync calls are required to set it up). May not run many precompiled executables at the moment but maybe an interesting research direction.

For those that like this format, here is an interesting talk (and slides) presenting Tilck at Kernel Recipes:

https://kernel-recipes.org/en/2022/talks/developing-tilck-a-...

I wrote a few words live during this talk: https://kernel-recipes.org/en/2022/live-blog-day-2-morning/#...

Another interesting project to checkout is klange’s toaruos https://github.com/klange/toaruos

At first I read this as "tortuous", then "to aru" (toh ahru). So, despite not having watched the show, I'm now thinking of railguns.

It would be really interesting for me, to once see a kernel in a higher language than C. Would it be possible to write something like that in Rust, or am I missing something?

https://www.redox-os.org/

There are many many small hobby OSes in all kinds of languages: https://wiki.osdev.org/Projects

Rust is definitely NOT a higher language than C and there are dozens of OSs like TockOS, R3 and OS-like frameworks (like embassy-rs and RTEMS-inspired RTIC) written in it in the embedded world and quite a few in nonembedded world (i.e. world where you have MMU not just MPU or less).

There are many.

There is Oberon:

http://ignorethecode.net/blog/2009/04/22/oberon/

That's a whole family of OSes, from tiny text-mode up to SMP, TCP/IP-capable GUI OSes, in the language that followed Modula-2 (which in turn was the successor to Pascal.)

There was TUNIS, a UNIX implemented in a Pascal derivative:

https://en.wikipedia.org/wiki/TUNIS

Here's a whole article on them I wrote last year:

https://www.theregister.com/2022/03/29/non_c_operating_syste...

There are lot's of kernels written in higher level languages (including languages with a GC). Really, if you start searching for them then you will find several every day for weeks if not months.

Enjoy Mesa/Cedar,

https://www.youtube.com/watch?v=z_dt7NG38V4

I wonder what the total size is? I remember back in college a project to run Linux on a floppy disk (3.5) and I was using it as a NAT box

"Tilck is fundamentally different from Linux as it does not aim to target multi-user server nor desktop machines"

Linus Torvalds had said a similar thing about Linux: "just a hobby, won't be big and professional like gnu"

Yeah, but I get the impression that Torvalds was just being realistic; if given the ability to realize a full system I don't think he would have objected. Tilck, on the other hand, is deliberately an educational kernel that seems to reject fancier features because they would undermine its goal of staying small, simple, and understandable to students.

I wonder how python performance would be like on Tilck. It is pretty bad on freebsd compared to linux.

Can you provide a source for that? I have found the performance between FreeBSD and Linux to be comparable, even when using Python.

To replicate, create two qemu vms. One ubuntu 22.04, one fbsd13.1.

Install any python starting from 3.9

Write a function to sum the first 50_000_000 integers, run it on both.

Maybe, it is QEMU/FreeBSD problem, not FreeBSD/Python one?

I'm using FreeBSD for 20+ years on real hardware and never seen huge performance differences for all common software, which is not using CUDA or alike.

Thanks for that. I found some fbsd forum posts about this, but they also mentioned virtualization.

I also thought this was bollocks so have just been running pyperformance on a virtualised arm64. I have some figures from Linux running on the same platform. I've not been very scientific about it.

FreeBSD is consistently slower. Between 20-50% across the board. I must admit I'm amazed that Python spends enough time calling into the OS to make a difference this big. Perhaps it's a problem with libc? Maybe there's something going on with memory barriers? My "fist unix" was FreeBSD so I'm amazed and just a bit gutted.

Note the other replies @ parent. It seems to be a virtualization specific issue.

Reply on news.ycombinator.com