Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

Post reply on HN
Print view View original

291–300 of 311 posts

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#291

Post by codedokode »

c00lio wrote: post #202
adql wrote: post #194

Earlier quoted context omitted.

For one, encoding and decoding text is slower than binary calls to a function with solid parameters that don't need to be converted. It's far too easy to pretend reality is not complex and that "elegant" solution somehow will fit everything

Netlink sockets in Linux input and output packed C structures. Doesn't get more efficient than that. Such an interface definitely doesn't have to be strings-only. But of course, you cannot use it with just 'echo' in that case.

Why not make real syscalls rather than emulate them using socket-like interface? Doesn't make much sense to me. For example, if you want to filter syscalls then it becomes more difficult (need to remember which type of socket it is, need to parse the structures and so on).

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#292

Post by codedokode »

3cats-in-a-coat wrote: post #175
winter_blue wrote: post #153

Earlier quoted context omitted.

An attempt is being made to reduce everything to: interface UniversalInterface { fun open(…) fun read(…) fun write(…) fun close(…) } If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. Ultimately, when someone does en…

> If you went to a software engineering design review meeting, proposing that several different kinds of objects representing everything from files, network sockets, to arbitrary devices should all use the interface above, you’d be laughed out of the room. You're describing a meeting in which people seem unaware of the purpose of uniform interfaces. Not sure we could call such a meeting "engineering design" meeting,…

> The goal is to do it once

There is an universal interface, it is called "system call". Rather than build unnecessary layer on top of it, improve the syscalls if you don't like them, and get rid of ioctls, /proc, /sys and other pseudo-syscall abstractions.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#293

Post by codedokode »

mike_hock wrote: post #260
arghwhat wrote: post #208

Earlier quoted context omitted.

To elaborate on those points a bit further, past what I already said about pidfd being introduced exactly to treat processes as files: 1. ioctls can make any "syscall" on a file. 2. a process does not have to be a singular file. All processes have most if not all their attributes exposed as files /proc/$PID/ as files, and can have this arbitrarily extended. In plan9, passing a signal (technically a note) is done by w…

This is an absurd interpretation of "everything is a file." The kind that makes you go "arghwhat?!" A file descriptor is exactly nothing like a file. You cannot write to a pidfd. You cannot waitid an eventfd. You cannot getsockopt on a regular file. The only operations that all file descriptors have in common is close, dup, poll and some other basic operations. So "file descriptor" basically just means "kernel interf…

Also, I remembered, there is /dev/pts, a weird file-based API that you need to use to create pseudo-terminals.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#294

Post by wbl »

salawat wrote: post #196
wbl wrote: post #7

Earlier quoted context omitted.

The problem with find is that it tries to put an entire programing language into its arguments.

I'd recommend you not look at awk/sed then.

Awk is a real programing language (hint: who are A, W, and K) where short scripts are strings passed in via single arg. That's not find.

Sed has a fairly well designed although limited interface you again pass in.

By contrast find tries to have separate pieces strung together each as an argument.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#295

Post by marcosdumay »

totony wrote: post #270
marcosdumay wrote: post #253

Earlier quoted context omitted.

To reverse that question, what do you gain by defining a `read` and `write` API over that memory segment? Because if you just add some high-level interface without any concern for performance, yeah, you get what Linux does today. But if you make them a core concern of your shared memory interface, you will certainly lose performance on the cases it's mapped as memory. And "everything is a file, but this one here is a…

Having a cursor to access files is mostly legacy no? The difference between memory and storage is getting very small, e.g. ssds and optane

Not exactly legacy, as SSDs are not completely random access, and disks still exist. But yes, the stream abstraction is losing relevance for files.

But well, if the proposal is to unify everything, you will have to unstream network connections too.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#296

Post by c00lio »

codedokode wrote: post #291
c00lio wrote: post #202

Earlier quoted context omitted.

Netlink sockets in Linux input and output packed C structures. Doesn't get more efficient than that. Such an interface definitely doesn't have to be strings-only. But of course, you cannot use it with just 'echo' in that case.

Why not make real syscalls rather than emulate them using socket-like interface? Doesn't make much sense to me. For example, if you want to filter syscalls then it becomes more difficult (need to remember which type of socket it is, need to parse the structures and so on).

The original idea for netlink sockets (where the name comes from) is to be able to do some network packet processing in userspace. E.g. to do stuff like virus-scanning on TCP connections.

The situation there is exactly the opposite of a syscall, it is rather that the kernel calls into userspace to perform a helper function.

Communication with the socket is still read()/write()/..., so there are still syscalls. The userspace program will do a read() to get the next struct+packet out of the socket.

The modern, syscall-less interface for stuff would be io_uring. There, you do not need to read(), you can just get your data written into a userspace buffer that you can mwait or poll on.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#297

Post by arghwhat »

mike_hock wrote: post #286
arghwhat wrote: post #266

Earlier quoted context omitted.

A file descriptor is a handle to a file, and anything you have an fd to is a file. This file carries a vfs implementation, such as that of pidfd, a device driver, or disk storage. The kernel does not distinguish between these. If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are not files - despite being at the heart of the whole "eve…

> A file descriptor is a handle to a file, and anything you have an fd to is a file. This file carries a vfs implementation, such as that of pidfd, a device driver, or disk storage. The kernel does not distinguish between these. Which is what I said. It's a "file" in name only. > If not being able to write makes it not a file, then files stop existing when a disk is full, and means that /dev/zero and /dev/null are no…

> Which is what I said. It's a "file" in name only.

No, it is the very definition of a file from the OS perspective. There is no other applicable definition to the OS. You seem to conflate files with disk storage, in which case not just plan9, not just Linux but the entirety of UNIX history seems to have flown past you.

That files are a nothing but abstract handles that implements the VFS interface to serve every conceivable function - where regular file is treated no differently than a device driver - is the entire point of modern UNIX. If this is the part you are stuck on it is not a surprise that both the existing Linux kernel APIs and trivial (and quite frankly, perfectly ergonomic and efficient) alternatives like the plan9 API seem so foreign to you.

"read and write structs" is the most normal thing for an application to do, whether you are reading JSON from disk, communicating over UNIX domain sockets with raw C structs, or sending protobuf over the network.

"But thank God it's not implemented in Linux" - Linux has many of these APIs already and it constantly grows, see for example all of /dev, /sys and /proc, not to mention FUSE and support for the 9P protocol to use all of plan9's services as-is.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#298

Post by miga »

3cats-in-a-coat wrote: post #117
giamma wrote: post #112

Earlier quoted context omitted.

I am probably looking at it from a too high-level perspective, but the RESTful paradigm was widely adopted in every domain and proved that you can model pretty much any concept as resources, with CRUD primitives and hyperlinks between them. Wouldn't the same be applicable to files, processes, devices and so on?

It is. I don't think people are well familiar with what Plan 9 calls "files". They're objects or resources, which also happen to be files. REST/OOP/Actors/Plan9 are very similar systems. And like it or not OOP shows that it's possible for one idiom to describe all the things when it's flexible enough.

These are called "special files" in Linux. "Device files" are just a special case.

Both "special" and "device" files are still "files".

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#299

Post by miga »

crabbone wrote: post #223
afr0ck wrote: post #47

The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interf…

Wait until you realize you need asynchronous I/O operations, and then you also need to manage caching on I/O operations, and you also need to distinguish appends from over-writes, and that you also need to care about who allocates memory for the buffer being written to / read from... And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow u…

It was not Unix that become platform for Internet, but Posix.

Linux is not derived from Unix, but supports Unix (Posix) APIs. As does modern MS Windows, and Mac OS X.

This also means that Google could experiment with OSes like Haiku or Fuchsia that support Posix, but are built in a different way.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#300

Post by miga »

codedokode wrote: post #290
marcosdumay wrote: post #203

Earlier quoted context omitted.

> write(SIGKILL, "/proc/12345/signals") Outside of lots of non-obvious problems with synchronization, this is your example that best fits the idea. This interface is probably a good one. > And of course you can get a peer address from /dev/tcp You will have lots and lots of problems with access controls if this is your only interface. > Shared memory can be a file Coercing random access memory into a serial file just…

> This interface is probably a good one. This interface is a bad one because if you want to filter syscalls then it will be difficult to distinguish write to a file from sending a signal.

You will filter syscalls by filename anyway.

Try `strace|grep open` on any program, and you will be spammed with a number of shared libraries. You need to filter them out anyway.

Post reply on HN