<div dir="auto">Yes, many classic commands -- cat, cp, and others -- were sleekly and succinctly written.<div dir="auto"><br></div><div dir="auto">In part because they were devoid of error checking.</div><div dir="auto"><br></div><div dir="auto">I recall how annoying it was one time in the early 70s to cp a bunch of files to a file system that was out of space.</div><div dir="auto"><br></div><div dir="auto">As I grew older, my concept of what constituted elegant programming changed.</div><div dir="auto"><br></div><div dir="auto">UNIX was a <i>research</i> project, not a production system!</div><div dir="auto"><br></div><div dir="auto">At one of the first UNIX meetings, somebody from an OSS (operations support system) was talking about the limitations of UNIX when Doug asked, "Why are you using UNIX?"</div><div dir="auto"><br></div><div dir="auto">Marc</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 19, 2024, 5:54 AM Andrew Warkentin <<a href="mailto:andreww591@gmail.com">andreww591@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, May 18, 2024 at 8:03 PM Larry McVoy <<a href="mailto:lm@mcvoy.com" target="_blank" rel="noreferrer">lm@mcvoy.com</a>> wrote:<br>
><br>
> On Sat, May 18, 2024 at 06:40:42PM -0700, Bakul Shah wrote:<br>
> > On May 18, 2024, at 6:21???PM, Larry McVoy <<a href="mailto:lm@mcvoy.com" target="_blank" rel="noreferrer">lm@mcvoy.com</a>> wrote:<br>
> > ><br>
> > > On Sat, May 18, 2024 at 06:04:23PM -0700, Bakul Shah via TUHS wrote:<br>
> > >> [1] This brings up a separate point: in a microkernel even a simple<br>
> > >> thing like "foo | bar" would require a third process - a "pipe<br>
> > >> service", to buffer up the output of foo! You may have reduced<br>
> > >> the overhead of individual syscalls but you will have more of<br>
> > >> cross-domain calls!<br>
> > ><br>
> > > Do any micro kernels do address space to address space bcopy()?<br>
> ><br>
> > mmapping the same page in two processes won't be hard but now<br>
> > you have complicated cat (or some iolib)!<br>
><br>
> I recall asking Linus if that could be done to save TLB entries, as in<br>
> multiple processes map a portion of their address space (at the same<br>
> virtual location) and then they all use the same TLB entries for that<br>
> part of their address space.  He said it couldn't be done because the<br>
> process ID concept was hard wired into the TLB.  I don't know if TLB<br>
> tech has evolved such that a single process could have multiple "process"<br>
> IDs associated with it in the TLB.<br>
><br>
> I wanted it because if you could share part of your address space with<br>
> another process, using the same TLB entries, then motivation for threads<br>
> could go away (I've never been a threads fan but I acknowledge why<br>
> you might need them).  I was channeling Rob's "If you think you need<br>
> threads, your processes are too fat".<br>
><br>
> The idea of using processes instead of threads falls down when you<br>
> consider TLB usage.  And TLB usage, when you care about performance, is<br>
> an issue.  I could craft you some realistic benchmarks, mirroring real<br>
> world work loads, that would kill the idea of replacing threads with<br>
> processes unless they shared TLB entries.  Think of a N-way threaded<br>
> application, lots of address space used, that application uses all of the<br>
> TLB.  Now do that with N processes and your TLB is N times less effective.<br>
><br>
> This was a conversation decades ago so maybe TLB tech now has solved this.<br>
> I doubt it, if this was a solved problem I think every OS would say screw<br>
> threads, just use processes and mmap().  The nice part of that model<br>
> is you can choose what parts of your address space you want to share.<br>
> That cuts out a HUGE swath of potential problems where another thread<br>
> can go poke in a part of your address space that you don't want poked.<br>
><br>
<br>
I've never been a fan of the rfork()/clone() model. With the OS I'm<br>
working on, rather than using processes that share state as threads, a<br>
process will more or less just be a collection of threads that share a<br>
command line and get replaced on exec(). All of the state usually<br>
associated with a process (e.g. file descriptor space, filesystem<br>
namespace, virtual address space, memory allocations) will instead be<br>
stored in separate container objects that can be shared between<br>
threads. It will be possible to share any of these containers between<br>
processes, or use different combinations between threads within a<br>
process. This would allow more control over what gets shared between<br>
threads/processes than rfork()/clone() because the state containers<br>
will appear in the filesystem and be explicitly bound to threads<br>
rather than being anonymous and only transferred on rfork()/clone().<br>
Emulating rfork()/clone on top of this will be easy enough though.<br>
</blockquote></div>