14 ms·
Towards userspaceification of POSIX – part I: signal handling and IO
- tom_ 2y agoThose who understand Unix are condemned to reproduce it exactly.
- Aerbil313 2y agoWhich is why the next OS might be written by younglings who know little to nothing about "modern" OSes and just design from first principles, instead of being beholden to a gigantic historical architecture debt. We're still running on kernels written in 1990. Time for an upgrade?
- blueflow 2y agoCommunicating using a protocol from the 90ies, using a network stack from the 80ies, running an CPU architecture from the 70ies. Being old and being unsuitable for its purpose are orthogonal.
- exe34 2y agowe still use roads and wheels, which are positively antique.
- Aerbil313 2y agoI disagree. While some amount of stability is a precursor to usability, it does hold us back from progress. I posit we hit a [complexity] ceiling and we need to do a clean rewrite. Maybe hardware guys in the back can't, but we software people surely can.
- deleted 2y ago[deleted]
- blueflow 2y agoYou are not disagreeing with me.
- Aerbil313 2y agoYeah, sorry for not expressing this clearly: I believe software also ages with literal time. Because the real world changes, and software ultimately runs in the real world. Being old and being unfit for its purpose are pretty much linked when it comes to software.
- jbernsteiniv 2y agoWe still have banks running code even older than that. Do you want banks to take a large risk and potentially impact millions of people because "old code is bad code"? There is a time for an upgrade where things make sense. Not everything needs to be re-developed. We discovered fire a very long time ago. I don't think we need to retire fire because its so ancient.
- eddd-ddde 2y agoI wholly believe it's impossible to get out of our "local minimum" without re developing from zero at some point. So many of our technologies are just there because they solve some problem we created ourselves.
- Aerbil313 2y agoI don't think it's possible at all. Entertain the thought. If not for anything for social reasons. A hard fork of the entire ecosystem is the only way. Every single piece of software we write today depends on every other. It's not a tree like commonly thought, it's a cyclic graph.
- mananaysiempre 2y ago> POSIX allows file descriptors to be shared by an arbitrary number of processes, after e.g. forks or SCM_RIGHTS transfers (even though this use case is most likely very rare, so it’s not entirely impossible for this state to be moved to userspace). Normally it’s rare, except shell functionality crucially depends on it[1]. The way to think about this, IMO, is that while a disk file is more or less random-access, when you open it unavoidably turns into strange hybrid of a random-access byte array and a (seekable) byte stream (classically, the “file description”), and that is what the resulting fd and any of its copies point at. Seekable streams made some sense in the age of tape drives, but nowadays it seems to me that random-access files and non-seekable streams have enough of a gulf between them that forcing both to appear like the same kind of object is more confusing than helpful. (I don’t know what my ideal world would look like, given I still like to direct streams from/to files. I still dislike the “file description” business rather strongly.) [1] https://utcc.utoronto.ca/~cks/space/blog/unix/DupSharedOffsetNecessary https://utcc.utoronto.ca/~cks/space/blog/unix/DupSharedOffse...
- raggi 2y agoabsolutely right re. shells, there's a lot in core old unix that depends on dup and a lot from the 90s/00s that depends on dup2 as well, with all the pain in the butt that it comes with (for multi-threaded and userspace implementors). readat and friends are certainly becoming more popular in various domains, particularly as they're cheaper in highly parallel programs avoiding the locking on seeks, and avoiding the stalls on mappings (unless you can afford gigantic / up-front & static mappings). At this point what we really need is thread independent mapping solutions, a solution to request a mapping be bound to a thread, and the ability to also pass that around. Mapping will never be free, but if we can avoid whole process stalls and giant mapping pressure both of which are painfully common today that's a big step forward.
- wahern 2y agoHow would that work in practice? Each thread has their own memory map, but with one shared branch where all the normal process-global virtual memory is mapped, and a non-shared branch for per-thread virtual memory? Seems like there's the potential for surprise, accidental overlapping of non-shared VM mappings. But I guess this is purely a performance thing; caveat emptor, etc.... How easy would that be to hack into Linux's existing page table structures?
- throwaway93982 2y ago[flagged]
- tbrownaw 2y agoWould shared pipes not have approximately the same issue wrt file positions being shared state? A process group (cron job, systemd service) sharing a pipe for error output is probably a bit more common than directly having an on-disk file.
- 4lDO2 2y agoPipes lack a file cursor, but they still need to store the fcntl file description flags, so yes. This is emulated by the Redox kernel for old schemes, by inserting fcntl calls between the legacy read/write calls that don't allow passing the offset and flags. However, I'd argue that the fcntl flags are even more client-oriented than the cursor, say, O_NONBLOCK. Should it really be possible for isolated processes to set each others' nonblock flag (unless using preadv2/pwritev2 which is non-POSIX)?
- Animats 2y agoWhy emulate POSIX signal semantics? Those are a holdover from the single-thread UNIX era. Events should be delivered by threads or async calls. Signals should be reserved for exceptions, things you don't return to, like segfaults.
- 4lDO2 2y agoThe rationale was discussed in-depth earlier on LWN (https://lwn.net/Articles/982186/ https://lwn.net/Articles/982186/). Signals are useful as a software analogue to hardware interrupts, even though they are probably too low-level for most application use cases. They are for example used by the Golang runtime to preempt threads AFAIU, which wouldn't otherwise be possible non-cooperatively. Intel even included an ISA extension called user-IPIs, which is similar to signals.
- up2isomorphism 2y agoThis is very typical rust project. Trying to change the old world while tightly following the old world in a very unimaginative way. Maybe too much memory safety is bad for creativity?
- throwaway984393 2y agoI love how "secure" just translates to "memory safety" now. Apparently OpenBSD could have just been a basic Rust kernel and stopped thinking about all the other security mechanisms they have
- techbrovanguard 2y agoquality post from `throwaway984393`.
- techbrovanguard 2y agomaybe too little memory safety means your wit overflows back to 0?
- tredre3 2y agoRust overflows in the same way (granted it does provide convenient built-in wrappers to check for overflows).
- actionfromafar 2y agoIt's the way of the world. Once memory safety has properly infiltrated most of the world, we can move on to (re-)discover other kinds safety.