Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a Unix clone in about a month

drewdevault.com

Post reply on HN
Print view View original

111–120 of 140 posts

Re: Writing a Unix clone in about a month

#111

Post by mananaysiempre »

KerrAvon wrote: post #104
mananaysiempre wrote: post #95

Earlier quoted context omitted.

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.

SIGHUP and SIGINT have no CPU-level equivalent.

Sure. What I meant is, a CPU’s trap/interrupt mechanism is very often used to signal both problems that arise synchronously due to execution of the application code (such as an illegal instruction or a bus error) and hardware events that happen asynchronously (such as a timer firing, a receiver passing a high-water mark in a buffer, or an UART detecting a break condition). This is not that far away from SIGSEGV vs SIGHUP.

Some things (“imprecise traps”) sometimes blur the difference between the two categories, but they usually admit little in the way of useful handling. (“Some of the code that’s been executing somewhere around this point caused a bus error, now figure out what to do about it.”)

Re: Writing a Unix clone in about a month

#112

Post by lproven »

dboreham wrote: post #93
mtillman wrote: post #15

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

So was MS-DOS. Sold in the tens of millions and kick-started the entire x86 PC industry, though.

Sometimes small and simple is good.

Re: Writing a Unix clone in about a month

#113

Post by AlexeyBrin »

mtillman wrote: post #15

This 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)

I think you are confusing Dennis Ritchie with Ken Thompson.

Re: Writing a Unix clone in about a month

#114

Post by amelius »

sph wrote: post #109
amelius wrote: post #27

Waiting for an OS that treats GPU(s) as a first class citizen ...

If programming GPU drivers was not something only a handful of employees with NVIDIA or AMD badges could do (because of NDAs, non-public documentation and immense complexity), somebody would have tried.

The point (for some) of writing your own OS is that you do something only a handful of people can do ...

Re: Writing a Unix clone in about a month

#115

Post by westurner »

westurner wrote: post #92

From "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

And a new one, a new syscall this year: mseal()

"Memory Sealing "Mseal" System Call Merged for Linux 6.10" https://news.ycombinator.com/context?id=40474551

Re: Writing a Unix clone in about a month

#116

Post by okanat »

lelanthran wrote: post #108
pcwalton wrote: post #38

Earlier quoted context omitted.

"signalfd is useless" is a good article: https://ldpreload.com/blog/signalfd-is-useless It goes into the problems with Unix signals, and then explains why Linux's attempt to solve them, signalfd, doesn't work well.

That is a good article. I found myself nodding in agreement while reading it, thinking "Yeah, I've been bitten by that before". How does Windows handle this? There's still signals, but I believe/was under the impression that signals in Windows are an add-on to make the POSIX subsystem work, so maybe it isn't as broken (for example, I think it doesn't coalesce signals).

Windows has a slightly better concept: Structured Exceptions (https://learn.microsoft.com/en-us/windows/win32/debug/struct...). It is a universal concept to handle all sorts of unexpected situations like divide by zero, illegal instructions, bad memory accesses... For console actions like Ctrl+C it has a separate API which automatically creates a thread for the process to call the handler: https://learn.microsoft.com/en-us/windows/console/handlerrou... . And of course Windows GUI apps receive the Window close events as Win32 messages.

Normal windows apps doesn't have a full POSIX subsystem running under them. The libc signal() call is a wrapper around structured exceptions. It is limited to only a couple well-known signals. MSVCRT does a bunch of stuff to provide a emulation for Unix-style C programs: https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

In contrast to Unix signals, structured exceptions can give you quite a bit more information about what exactly happened like the process state, register context etc. You can set the handler to be called before or after the OS stack unwinding happens.

Re: Writing a Unix clone in about a month

#117

Post by lelanthran »

okanat wrote: post #116
lelanthran wrote: post #108

Earlier quoted context omitted.

That is a good article. I found myself nodding in agreement while reading it, thinking "Yeah, I've been bitten by that before". How does Windows handle this? There's still signals, but I believe/was under the impression that signals in Windows are an add-on to make the POSIX subsystem work, so maybe it isn't as broken (for example, I think it doesn't coalesce signals).

Windows has a slightly better concept: Structured Exceptions ( https://learn.microsoft.com/en-us/windows/win32/debug/struct... ). It is a universal concept to handle all sorts of unexpected situations like divide by zero, illegal instructions, bad memory accesses... For console actions like Ctrl+C it has a separate API which automatically creates a thread for the process to call the handler: https://learn.microsoft.c…

I am such a moron. Every one of those three links above is colored as 'visited' for me.

I have obviously read this up before and just didn't remember :-(

Re: Writing a Unix clone in about a month

#119

Post by lupire »

pushedx wrote: post #14
andsoitis wrote: post #2

Impressive, super cool, and inspiring! Example of “creating something impressive in X days” requires a lot of experience and talent that is built over years .

Also the creator of KnightOS, written entirely in Z80 assembly, more than 12 years ago! https://www.ticalc.org/archives/files/fileinfo/463/46387.htm...

https://drewdevault.com/2020/01/27/KnightOS-was-interesting....

Sadly defunct. I guess the real OS was the syscalls we made along the way.

Re: Writing a Unix clone in about a month

#120

Post by smugma »

saagarjha wrote: post #80
andsoitis wrote: post #2

Impressive, super cool, and inspiring! Example of “creating something impressive in X days” requires a lot of experience and talent that is built over years .

Drew is smart and his timeline is short but I think it’s the wrong way to look at it if you just put him on a pedestal for it. Making a UNIX clone is a typical undergrad project at most universities. Extending that to something that is complete is something that requires perseverance, not special genius.

NachOS was developed at Berkeley and maintained at UW. Both are top-ranked CS programs. Undergraduates are expected to add features to the core OS e.g. virtual memory, not build it from scratch.

https://en.wikipedia.org/wiki/Not_Another_Completely_Heurist...

https://homes.cs.washington.edu/~tom/nachos/

Post reply on HN