Live data from Hacker News

LibOS – A library operating system for Linux

lwn.net

21–30 of 59 posts

Re: LibOS – A library operating system for Linux

#21

This is excellent. Anyone who's ever faced the daunting task of bolting TCP on top of custom datagram protocol can certainly confirm how useful a library like this is.

Why isn't that "just" either using lwIP, or using your host's TCP running against a TUN/TAP device and then encapsulating the data you read from /dev/net/tun into your custom datagram protocol?

(This is not meant to be dismissive, just inquisitive. I'm sure it can't be anywhere near as easy as what I said, I'd just like to learn why.)

Re: LibOS – A library operating system for Linux

#25
Now this is userspace networking I can get behind!

Rather than re-implement a new network stack and solve all the same problems again, this builds on the years of good work already done and leverages the existing time investment within the existing stack.

"Librarising" existing stacks to userspace, great idea, this is the way of the future.

Re: LibOS – A library operating system for Linux

#26
post #24

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

For a number of reasons:

- It used to be impossible to implement securely. Until very recently, there was no hardware support for virtualizing the network buffers, which would mean emulating the network hardware in userspace. This would be very slow.

- Because even today, many devices don't have the required hardware virtualization support. For example, many (most?) ARM devices. If you give direct DMA access, you might be allowing anyone to splatter whatever code they want across whatever memory they want.

- Without kernel arbitration of some sort, there's no way to do load balancing across services, throttle, or firewall effectively.

- The kernel is designed to provide a uniform interface for all programs to the hardware. Putting networking in userspace gets rid of this abstraction, and means that every program has to be aware of the network hardware; software that works with file descriptors directly can't use the same abstraction for files and network.

- Because there are no hardware limitations on the amount of multiplexing. I don't remember how much muxing various hardware supports, but hardware has limits for this sort of thing. If you want more than N processes using the virtual network, you might be SOL with a virtualized userspace network stack.

Re: LibOS – A library operating system for Linux

#27
post #24

Stupid question: why does the Linux Kernel handle the networking in the first place? Why not implement everything in userspace from the start?

To multiplex multiple users and applications. Which is less necessary in these days of virtual network devices etc, eg SR-IOV can make a PCI device appear as say 64 network devices so every application can have its own.

Re: LibOS – A library operating system for Linux

#28

Now this is userspace networking I can get behind! Rather than re-implement a new network stack and solve all the same problems again, this builds on the years of good work already done and leverages the existing time investment within the existing stack. "Librarising" existing stacks to userspace, great idea, this is the way of the future.

The NetBSD rump kernel (rumpkernel.org) does this for every driver in the kernel, and is part of the OS, so they are maintained (there are lots of stacks pulled out but not maintained).

Thats why it is important that this project becomes part of upstream so it can be maintained as the stack changes.

Re: LibOS – A library operating system for Linux

#29

Reminded me of that quote: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." --DanIngalls

There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language only. You can't easily bolt them into whatever OS you already use. None of your familiar tools run on them either. Adoption rates are poor with no way to dip your toe into the environment.

What would a "no OS" system that equally supports multiple languages look like?

edit: Multiple languages that have nothing in common. Think about the insane variety of languages you have available on *nix.

Re: LibOS – A library operating system for Linux

#30
post #29

Reminded me of that quote: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." --DanIngalls

There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language on…

What would a "no OS" system that equally supports multiple languages look like?

Racket?

Post reply on HN