Hacker News Reader

Comment by Animats | Hacker News Reader

Back then, nobody realized how bloated the Linux kernel was going to become, with way too much in kernel space. The kernel is somewhere above 15 million lines of code now.

View on HN

It should be noted that in the nineties the Linux kernel was very far from being as modular as it is today. I don't know when dynamic module loading was introduced, but I recall in the very early 2K one had to recompile the kernel for nearly every new device added to the machine. Even when dynamic modules were available, not all devices could be managed as such and sometimes the driver code had to be statically linked to the kernel anyway. Today things have changed: pretty much every new device install/insertion will let the kernel automatically load the relevant device driver without any need to either insert a driver CD or go online to download it. Of all those millions lines of code, only a very small part is actually executed.

According to the LKM Howto, support was added around 1.2 (1995).

http://tldp.org/HOWTO/Module-HOWTO/x73.html#AEN90

Around 1.2.8 HJ Lu added the ELF kernel module support:

http://tech-insider.org/linux/research/1995/0526.html

I remember a lot of this and feel old now.

Me too, my first Linux distribution was Slackware 2.0 with the kernel 1.0.9, with initial support for IDE CD-ROM drives.

"Bloat" is a loaded term. It's meaningless to say "Look at all this code! It's bloated!" when you don't know the reason those lines are there, and comparing two "solutions" is meaningless when they don't solve all the same problems.

Mainly, I'm just getting tired of people trying to cut things out of the solution by cutting them out of the problem.

Saying that it's possible to solve a problem in a simpler fashion is fine. Saying a problem shouldn't be solved, that nobody should have that problem, so therefore we won't solve it, is not fine if you then turn around and compare your cut-down solution to the full solution.

I think AST did. IMHO, drivers belong in user space. There's an exponential number of devices out there, jamming them into the kernel has been a messy chore at best.

As someone completely alien to that side of computing except rudimentary stuff most people know, I never understood the reason why the drivers have to be maintained in the kernel tree. Maybe include the most common stuff, but why not have a second, distinct linux-drivers project that maintains those stuff in their own time?

Also, why we don't have a common interface to drivers at least between Linux and BSD by now? I don't like that there's animosity between the two ecosystems. That way we could have, if technicalities permit, a way for many diverse OS models to enter into the competition: if the drivers are written agains a certain standardised interface, one can code-up an OS to support that interface, and just like with POSIX, the OS would have a whole suite of drivers available from day one. Better for the driver authors too.

Linux kernel maintainers are actively hostile to the concept of a stable driver ABI. They believe that drivers are best maintained with the kernel so that they can be kept up and fixed.

Given that Linux has the broadest hardware support of any open source OS, and arguably any OS period, it's difficult to say they aren't right.

Which is exactly what Project Treble introduces, it converts Linux into a micro-kernel design, where each driver runs in its own process with a tiny kernel presence, communicating over Android RPC mechanisms.

https://source.android.com/devices/architecture/hidl/

Are Treble drivers compatible with Fuchsia? That'd be cool.

No idea, but I don't think so as they are completely different architectures.

Genode has an ABI for userspace (which includes OS components and drivers) that works across multiple kernels, which are mostly microkernels, but also Linux.

Considering Google designed both Treble and Fuchsia, it's not such a crazy idea.

Nit: AIUI, the kernel has no stable API. It has no ABI period.

There has to be an ABI in order for loadable kernel modules to exist. That's the part that's infamously unstable.

API stability is not guaranteed, though it's stable enough that the likes of Nvidia can write installers for their proprietary drivers that recompile a bit of interface glue between kernel and blob.

> There has to be an ABI in order for loadable kernel modules to exist

Given a particular install, yes, but it will change independent of kernel version based on e.g. build flags and even conceivably compiler chosen, etc.

> it's stable enough that the likes of Nvidia can write installers for their proprietary drivers that recompile a bit of interface glue between kernel and blob

Well...they certainly can. It also can infuriate me beyond all reason...

The way I've understood it is that proprietary kernel modules contain an opensource part that is included in the kernel which makes a small stable API available which is then used by the proprietary kernel modules.

Making a stable API that covers the entire kernel would be a monumental task on the other hand.

I'm not saying they are explicitly wrong, but I don't think that's a useful metric. Adoption drives the drivers, not design. That's close to saying Linus was right because Linux is more used than Minix. As a fellow HNer has pointed out, companies are figuring out that depending on hardware vendors to do the right thing is a bad idea, hence Project Treble. Then again, I have a feeling it won't be too long until they scrap linux altogether.

> That's close to saying Linus was right because Linux is more used than Minix.

Well, Linus chose usefulness as a higher priority than theoretically optimal, so by Linus's standards, yes, Linus was right.

> Then again, I have a feeling it won't be too long until they scrap linux altogether.

Um... don't hold your breath. I think you're going to be waiting a long time for that one.

Sorry if my last point wasn't clear, I was speaking strictly of Google/Treble. Fuschia seems to be coming right along, I can see them going live with it within a few years.

It sounds very interesting... I rarely go deeper that connected systems or application development myself. But would love to see some better underpinnings to a flexible UI/UX on top. I think there's lots of room for both.

They are maintained in the kernel because the kernel interfaces are not stable, by choice. Here is the explanation from the kernel docs:

https://github.com/torvalds/linux/blob/master/Documentation/...

That's exactly the kind of dismissive, arrogant nonsense that I won't bother reading, even if it is the formula to an infinite life:

> You think you want a stable kernel interface, but you really do not, and you don't even know it.

...

> It's only the odd person who wants to write a kernel driver that ...

And:

> stable-api-nonsense.rst

Yeah right, read the couple lines that are intented as one-line TLDR and dismiss it as arrogant nonsense; you probably won't be writing drivers anyway.

The document itself is a blunt dismissal it seems, anyways. And yes, I won't write any drivers if I can avoid it.

Keeping a common interface is hard.

Isn't it harder to keep rewriting stuff?

Apparently not ;)

Because a kernel is the interface between applications and hardware resources. Modern microkernels are ~50% architecture dependent code.

Creating a common interface would require all OS vendors to collaborate on some standard and maintain a leaky abstraction over their preferred abstraction. You can do that, but there are feature, performance, and maintenance compromises that must be made.

I didn't read the web, but is there a way to have a kernel running, listing what drivers it uses and afterwards, provide a configuration to recompile it with just those drivers (hence removing the bloat).. Or maybe that's not the way it goes, Linux just load the drivers it needs...

Yes it's called modprobed-db. But it only tracks what modules are loaded, not what's used in the kernel. Although maybe you could compile everything you can as modules first, then check what's loaded and then compile with all those modules build in.

It's 15 million of codes the full source, that includes supports for like 10 different hardware architectures, and device drivers for every hardware that was ever made!

When you compile the linux kernel you will compile only a small fraction of these lines of code, and distributions typically compile drivers and a lot of things as modules, so you load them only when you need them. You can compile the kernel to fit in as much as a couple of Mb of space, very useful for embedded systems (my openWRT router has a 8Mb of internal flash memory, and runs Linux 4.4!)

And if we compare Linux with for example Windows is pretty small, Windows kernel source is said to weight a couple of gigabytes, and this for a kernel that supports only one (ok, now two with Windows for ARM) computer architectures and doesn't include device drivers (besides the basic ones)

Over 20 million lines of code even. But you only run 1.5 to 3 million.

Reply on news.ycombinator.com