Hacker News Reader

Comment by MarkusWandel | Hacker News Reader

Plan 9 is a fascinating time capsule of a period where text terminals were just being replaced with graphics ones. Which of course Plan 9 had a cleverly designed one for.

However if it had become mainstream, it would be just as cluttered up with inelegant stuff as Linux is now, in the endless pursuit of, say, graphics bandwidth performance, first for videos, then for 3D immersive games and now to merely draw your desktop. Mount an audio device remotely. Lovely. But try to get that working with Bluetooth, something mainstream desktop Linux has only just recently managed (i.e. use bluetooth headsets reliably and without fuss).

Ditto for 10GB ethernet or what have you. Elegance is quickly sacrificed at the altar of efficiency and expediency. At the risk of inciting disagreement, look at what happened to the originally relatively elegant and simple X protocol.

View on HN

I don't necessarily think so for 2 reasons:

The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device. This, coupled with the ability to map a file to memory, allows this paradigm to compete with the most efficient bare-metal implementations. One particular example is the /dev/draw interface mentioned in the article, where anyone could literally write graphics program just by fiddling with bits in memory, just like in DOS or the C64.

The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it? I don't see anything particularly inefficient here, particularly if the data transfer can be handle by a special network protocol that takes advantage of PCIExpress.

> For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it?

AIUI, you need something like CXL to implement a proper concurrency model that works seamlessly for both local and remote memory. So we're kinda close to what you're describing but not quite there yet.

HMM is on the way for a page migration-based impl that works on most hardware and allows seamlessly to use all CPU memory from GPU programs, including mmap’d files. CUDA 12 is going to be fun.

CXL 2.0 and earlier just aren’t it because of a coherency strategy that is absolutely dreadful. CXL 3.0 is better though, but that’s a long time away from hardware still.

> The fact that the lowest level of interaction you can have with a computer is writing memory.

While this is true as far as it goes, it's worth keeping in mind that not all memory controllers are equally low-level. Some of them expose cache architecture or the rectangular organization of DRAM in interesting ways.

> The fact that the lowest level of interaction you can have with a computer is writing memory. When writing device drivers, or interfacing with microcontroller hardware, the way you give commands and transfer data is by writing your command to a memory-mapped device register, or an area of memory that will be copied to the target device.

This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them. On Linux, the job of the DRM kernel driver for graphics is to mostly facilitate command buffer submission, scheduling, and results gathering. We'd really just see the same exact situation on Plan 9: user-space GPU drivers which do the work of translating graphics APIs into command buffers, and talking to a kernel-side component by submitting dedicated command buffers.

That they talk over a file interface isn't really relevant here, since it's just used as userspace -> kernel IPC.

> The other thing is, modern computers are networks in a box. For example, what if your GPU is a separate computer networked over a high-speed link. What if I could upload a texture just by opening a 'file' on the GPU, mmaping -it and memcpy-ing the data into it?

Well, first, you'd need to figure out the layout of the texture you want (e.g. AMD has these layouts https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd... ), allocate the full mip chain size, allocate your texture descriptors, then swizzle the texture data into a form that the GPU can understand.

Oh, and if you wanted a fast texture on desktop GPUs, you'd have to store it in host-inaccessible memory (host-accessible memory is often slower). So first you'd need to allocate a scratch buffer in slower, host-accessible memory, copy your texture data there, and then allocate the real texture storage in the faster host-inaccessible memory, and submit a copy command. That's a lot more work than a memmap and a memcpy.

Maybe we put all those smarts in the driver, but the driver is going to need a lot more info about the intended usage of the texture, and by that point we're basically creating /dev/vulkan rather than a low-level GPU API.

AIUI, a mmap file could in fact be "backed" by host-inaccessible memory. Then copying data to and from that memory would be a job for the driver, as for any block device. Other things can almost certainly be done in userspace, such as figuring out texture formats and converting if necessary.

> usually these devices are not designed for multiple processes to come in and start writing memory to them.

Multiplexing devices as needed can also be done in userspace. That's what, e.g. pulseaudio and pipewire do for audio devices, even those that don't support outputing audio for multiple processes at the same time.

> This is somewhat true, but usually these devices are not designed for multiple processes to come in and start writing memory to them.

You can use virtual functions for this purpose, but you only get access for a dozen-ish procceses. Also, GPUs have support for this already.

Of course, virtual machine managers and hypervisors also provide good solutions to this problem.

I've implemented high performance software atop VFIO, (roughly speaking: mmap chunks of the PCIe bus) and atop the equivalent Linux kernel APIs.

With VFIO, it is at least an order of magnitude easier to get to 90-95% of what the underlying hardware can do.

OpenBSD is a good example of an OS that tries to adhere to old school design principals while offering modern features. It has some pretty bad rough edges but is impressive nonetheless.

I use linux on my desktop but have an ancient Thinkpad that runs OpenBSD as well. I love following the changelog for each new release.

I'm in a similar space. I love OpenBSD for it's simplicity and consistency, but, to my way of thinking, it's missing to much to act at a modern desktop replacement. To that end, I've started running ChromeOS Flex on the desktop, taking advantage of it's Debian VM where ChromeOS falls short, while still using OpenBSD everywhere else that I can and makes sense.

I pretty much love all of the free-unix but dislike them for graphical use. I have generally stuck with Windows or MacOS for general desktop usage.

I've considered a combination setup of a terminal system for my unix needs and a tablet for web and video. ChromeOS would work well for this too, I think.

> However if it had become mainstream, it would be just as cluttered up with inelegant stuff as Linux is now

This is a community and distro problem. If you accept patches for the sake of adding stuff with no good reason then you're going to get linux. For example just the other day on the 9front mailing list someone submitted a patch for an ethernet driver they were working on to enable tcp/udp checksum offloading. Another user replied along the lines of "do we really need this? first thing I do as an admin is turn off weird/buggy offloading" which the submitter agreed with and that was that. No one really needs that patch; its code for ONE specific ethernet device few if any other users own.

The community strives to keep the OS small and practical as it was intended. That's a big part of the culture behind plan 9: Keep it simple, stupid!

Another thing is porting software for the sake of porting software is also discouraged. If you need it, then you port it and maintain it. Dont port things you don't need.

> But try to get that working with Bluetooth, something mainstream desktop Linux has only just recently managed (i.e. use bluetooth headsets reliably and without fuss).

Not really a fair statement. BT is a horror show with its batshit layercake of drivers, protocols and profiles. Plus the Linux audio situation has never stabilized and invents a new audio subsystem every decade: OSS, ALSA, Jack, pulse, pipewire, etc. The BT situation on Linux is the fault of the constantly moving linux dev community who's focus seems to favor server side stuff and DE colors.

> If you accept patches for the sake of adding stuff with no good reason...

Linux kernel is used on billions of devices by millions of people. If you don't see a good reason for some feature in Linux, it doesn't mean there is no such reason.

I'd even argue it is impossible to have something small, simple and practical, but simultaneously supporting such a vast sea of hardware and software combinations.

True no doubt, but as of one or at most two Fedora releases or so, you can plug in a bluetooth dongle (if you don't already have Bluetooth), pair a headset to it and use it! With selectable audio profiles even (the phone quality bidirectional one or the hifi stereo ones). And except for a rare glitch, it works. As well as Bluetooth ever does, judging from the experience in the car.

This was not so previously. I tried every release or two, and always ended up with a locked-up driver within 10 minutes of playing with it. This is totally Bluetooth's complexity's fault of course.

Reply on news.ycombinator.com