Hacker News Reader

Comment by c00lio | Hacker News Reader

Why would (pseudocode, nonexisting but possible example) write(SIGKILL, "/proc/12345/signals") not be possible? For the other direction, there is signalfd in Linux. And of course you can get a peer address from /dev/tcp (https://andreafortuna.org/2021/03/06/some-useful-tips-about-... ). Yes, /dev/tcp is not an OS primitive but a bash builtin, but there isn't really a reason you cannot do this in the OS. Shared memory can be a file, you just have to mmap() it. mmap is always left out of the open/close/read/write-enumeration of the traditional file API, but I think it is actually extremely useful and should be the fifth alongside those.

Debugging is hard to imagine, yes. One could look at /proc/12345/mem, write breakpoints in there, but I'm not sure about how to do the more exotic things.

View on HN

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of `ioctl`, and it's doubtful whether the resulting interfaces will be any easier to use than the existing ones.

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

I can’t wait till we’re configuring our OS using CSS-in-JS and booting using webpack.

npm install -g styled-linux

As always, Fabrice Bellard is ahead of his time: https://bellard.org/jslinux/ :)

Plan 9 does this. The resulting interfaces are indeed easier to use, forward over the network, and redirect or emulate for testing.

Exactly? The alternative is ioctl whereas Plan 9 does everything over serialized streams to files.

The serialized streams make it easier to think of these ioctl-alikes as something you can easily access over a network (9p).

And that’s how resource sharing is done in plan 9.

Let me introduce you to the Linux Audio Stack. Laying protocols on top of each other, when everything is just files, is no different from layering protocols on top of each other when some things are files and some thing aren't.

The question isn't "will it be just as bad" but "would some things become easier, and if so, how many things would become easier?".

Because if the latter, then it's a worthwhile topic to think about even if we never use it in any commercial sense of of the word.

The main problem with Linux audio is the bloom of APIs that appeared over the years. While a file-based interface would be cool, it would be just yet another API that competes with all the others for its place in the ecosystem. Fortunately, ALSA and PulseAudio seem to dominate right now.

mmap() is very different in its semantics from read() and write(). The latters have a clear, precise definition, a byte stream received by your file driver. mmap() is a different beast, it can be a ring buffer, it can a spinlock, it can be anything. The moment you have mmap(), the "eveything is a file" model is already broken and the namespace API can longer work reliably over the network. How would you transport an mmap() over the network? if /dev/tcp in plan9 uses mmap to asynchronously write the packets, you can no longer rely on the 9p filesystem protocol to implement a proxy by mounting the remote computer's /dev/tcp, because there is no clear and reliable way to map remote memory. It's no more about transporting a random sequence of bytes to another computer. You need more than that to make it work. It's just one example where this "everything is a fike" model is overly simple for the harsh real world.

> 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 to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

> Coercing random access memory into a serial file just to go and emulate a random access over that file is... not a great way to deal with a high-performance primitive.

The file doesn't need to have an on-disk representation. I don't see why an mmap-ed file should behave any different from a SHM segment. They are basically the same thing, the SHM segment even has a file descriptor. It just doesn't have a name somewhere in the filesystem hierarchy. https://man7.org/linux/man-pages/man7/shm_overview.7.html

It can have a name in the file system: /dev/shm

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 actually all about random access" doesn't give you much abstraction.

As somebody already said on the comments, the nice (maybe IMO, I'm not sure) thing about Plan9 is that every resource is named somewhere in a tree. The fact that those things are "files" only detracts from the value and makes the system less fit for modern usage.

Yeah, "everything has a filename" and "everything is a file" are very similar concepts but they aren't quite the same, and it might be that most of the value comes from the former.

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.

> 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.

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.

/proc pseudofiles could have a mode (perhaps on open) that determines whether the protocol is ascii or packed/binary. there could even be a side-band interface that provides the packed schema (assuming not everything is exploded to atomic type-evident items).

How is that "simple and elegant" design going for you?

Passing data in registers is more efficient, that's what you lose with serialization. Serialization gets you generality at the cost of some performance.

Right, registers are even faster.

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.

Reply on news.ycombinator.com