Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's monolithic but modular 11.5M LOC for every platform it runs on, not to mention drivers for the devices it supports, and all the modules for other functionality, pluggable file-systems and networking stacks. Now throw in code for backward compatibility going further back at least to 2.4 and you have 11.5M lines.

In reality, the core Linux kernel is just the stuff that compiles to vmlinux. You could read it all in a few weeks and understand it.



thats right, bloat

filesystems dont belong in the kernel.


Yeah, there is the FUSE project: filesystem in a userspace. There are lots of interesting filesystems using this e.g. NTFS-3G, sshfs or ferrisfuse. These projects are valuable and most of them doesn't belong to the kernel as they use userspace libraries for network protocols and xml parsing.

Unfortunately native disk file systems like NTFS-3G is lot more slower than their native counterparts.


&totse users ran tests of zfs-fuse back in the day and found that it was actually noticeably slower than native ext3. From that, I'm inclined to argue the opposite: filesystems should almost definitely be in-kernel. Granted, their tests were on Linux, not on a modern microkernel.


Linux, fuse

there's your problem. it's not designed for it


Well, with the last sentence I tried to write:

Unfortunately userspace file systems like NTFS-3G are lot slower than their native counterparts.

Which is understandable, regarding kernel calls are still quite expensive.


I wouldn't use Fuse as your benchmark. All of plan9's filesystems are userspace (except the one that uses a dedicated machine). They can saturate 10gbe so your objections really concern Fuse and it's hosts.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: