Are there "waypoint" commits for major milestones? Id really like to see those.
Like PC bootstrap, basic kernel action loops, process forking, yada yada
Writing a Unix clone in about a month
91–100 of 140 posts
Re: Writing a Unix clone in about a month
#92From
"Linux System Call Table – Chromiumos" https://www.chromium.org/chromium-os/developer-library/refer... https://news.ycombinator.com/item?id=33395777 :
> google/syzkalleR
> Fuschia / Zircon syscalls: https://fuchsia.dev/fuchsia-src/reference/syscalls
Re: Writing a Unix clone in about a month
#93This is really cool. Reminds me of the original Unix was invented in a couple weeks while Ritchie's family went on vacation to CA to visit his in-laws. Source: UNIX: A History and a Memoir Paperback – October 18, 2019 by Brian W Kernighan (Author)
But Unix itself took many years to write (if you count V7 as "properly finished Unix"). The first version was only a filesystem, for example.
Re: Writing a Unix clone in about a month
#94Earlier quoted context omitted.
If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…
I believe this was the 3rd time I’ve seen this book being recommended this week. It must mean something.
It's well written and full of practical advice and fun to read.
Re: Writing a Unix clone in about a month
#95Earlier quoted context omitted.
Signals are at the intersection of asynchronous IO/syscalls, and interprocess communication. Async and IPC are also weak points in the original Unix design, not originally present. Signals are an awkward attempt to patch some async IPC into the design. They're prone to race conditions. What happens when you get a signal when handling a signal? And what to do with a signal when the process is in the middle of a system…
As I wrote in some older discussion about UNIX signals on HN, the root problem (IMHO, of source) is that signals conflate three different useful concepts. The first is asynchronous external events (SIGHUP, SIGINT) that the process should be notified about in a timely manner and given an opportunity to react; the second is synchronous internal events (SIGILL, SIGSEGV) caused by the process itself, so it's basically lo…
At least the first two are also conflated in a typical CPU’s trap/interrupt/whatever-your-architecture-calls-it model, which is what Unix signals are essentially a copy of. So this isn’t necessarily illogical.
Re: Writing a Unix clone in about a month
#96> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!
Signals are at the intersection of asynchronous IO/syscalls, and interprocess communication. Async and IPC are also weak points in the original Unix design, not originally present. Signals are an awkward attempt to patch some async IPC into the design. They're prone to race conditions. What happens when you get a signal when handling a signal? And what to do with a signal when the process is in the middle of a system…
A story about the problem with delivering interrupts to a process in kernel mode in unix:
Re: Writing a Unix clone in about a month
#97I was interested in Hare until I found this immensely self-defeating FAQ item: https://harelang.org/documentation/faq.html#will-hare-suppor... As a baseline, I support developers using whatever license they would like, and targeting whatever operating systems, indeed, writing whatever code they would like in the process. That doesn't make this specific policy a good idea. Even FSF, generally considered the most extre…
There's no purity test and the Hare devs aren't prohibiting you from using Hare on macOS or any other platform.
They just don't want to maintain Mac/Windows ports themselves. If somebody else is interested, they can maintain a port. Like that macOS one that you've already found.
Re: Writing a Unix clone in about a month
#98> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!
Unix signals do... a lot of things that are separate concepts imo, and I think this is why there are people who don't like it or take issue with it.
You have SIGSTOP/SIGCONT/SIGKILL, which don't even really signal the process, they just do process control (suspend, resume, kill).
You have simple async messages (SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU, etc) that get abused for reloading configuration/etc (with hacky workarounds like nohup for daemonization) or other stuff (gunicorn for example uses the latter 2 for scaling up and down dynamically). There's also in this category bizarrely specific things like SIGWINCH.
You also have SIGILL, SIGSEGV, SIGFPE, etc for illegal instructions, segmentation violations, FP exceptions, etc.
And also things that might not even be good to have as async things in the first place (SIGSYS).
---
As an aside, it's not the only approach and there's definitely tradeoffs with the other approaches.
Windows has events, SEH (access violations, other exceptions), handler routines (CTRL+C/CTRL+BREAK/shutdown,etc), and IOCPs (async I/O), callbacks, and probably some other things I'm forgetting at the moment.
Plan 9 has notes which are strings... which lets you send arbitrary data to another process which is neat, but it using the same mechanism for process control imo has the same drawbacks as *nix except now they're strings instead of a single well-defined number.
Re: Writing a Unix clone in about a month
#99> I also finally learned how signals work from top to bottom, and boy is it ugly. I’ve always felt that this was one of the weakest points in the design of Unix and this project did nothing to disabuse me of that notion. Would love any resources that goes in more details, if any HN-er or the author himself knows of some!
Unix signals do... a lot of things that are separate concepts imo, and I think this is why there are people who don't like it or take issue with it. You have SIGSTOP/SIGCONT/SIGKILL, which don't even really signal the process, they just do process control (suspend, resume, kill). You have simple async messages (SIGHUP, SIGUSR1, SIGUSR2, SIGTTIN, SIGTTOU, etc) that get abused for reloading configuration/etc (with hack…
The Windows mechanisms you're mentioning were also added over the course of many, many years. Much of Windows also happened a long time after UNIX signals were invented.
If you're including all that other stuff, it's probably fair to include all of the subsequent development of notification mechanisms on the UNIX side of the fence as well; e.g., poll(2), various SVR4 IPC primitives, event ports in illumos, kqueue in FreeBSD, epoll and eventually io_uring in Linux.
Re: Writing a Unix clone in about a month
#100Earlier quoted context omitted.
If you haven't already, I would start with Advanced Programming in the Unix Environment by Stevens https://www.amazon.com/Advanced-Programming-UNIX-Environment... It is about using all Unix APIs from user space, including signals and processes. (I am not sure what to recommend if you want to implement signals in the kernel, maybe https://pdos.csail.mit.edu/6.828/2012/xv6.html ) --- It's honestly a breath of fresh air…
Not positive, but pretty sure that this, and the Unix Network book were golden for us in the 90s when we were writing MUDs. Explained so much about Socket communications (bind/listen/accept,...) Been a long time since I looked at that stuff, but those were fun times.
I believe that's the book I still have on my shelf. IIRC "UNIX Network Programming" and I learned a lot about networking and a lot about how UNIX works reading it cover to cover. I think I learned more from that book than any other.
Mr Stevens replied to something I wrote back in the day. I can't recall if it was a Usenet post or email, but I was over the moon!