It was meant to be a UNIX replacement. It was written by the same AT&T group that developed UNIX and C and, indeed, many of the same people too. However, it never seems to gave caught on before becoming a casualty of the Lucent buy-out. There's quite a decent summary of all this and of the Plan9 architecture here:
PS: I like the name too: a nod to the late, great Ed Wood.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Do not feed the troll ...
-- Adrian C
Sure, but up to that point it seems to have been only available on a commercial license. Once Lucent drop kicked it, what commercial interest the was seems to have died and AFAICT the FOSS versions only came later.
Pity: its an OS I always wanted to use. It looks to have something in common with the Mach kernel architecture. I used a Mach-based UNIX on DEC Alpha servers in the late '90s. It was quite impressive (though the Alpha RISC chip was even more impressive), but it had one major flaw: there was only one ever running instance of each module implementing a kernel SVC and this could lead to dire performance in some circumstances (SVCs that did fs related activities), probably because there was no mechanism for forking additional copies of such potentially slow modules.
The Plan9 kernel was and still is tiny by comparison with Linux. I do wonder at what point of kernel embiggenment Linus and crew will write an entirely new kernel based on Plan9 principles.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
IIRC kernel size is more about what things you think need to runs at kernel privilege and protection than how the actual architecture is organised.
E.g. there is some debate about moving networking out of the kernel into user space to improve performance.
Smaller kernel, but same RAM print for a working system.
-- Ideas are more powerful than guns. We would not let our enemies have guns, why should we let them have ideas? Josef Stalin
It is not easy to use as anything other than a programming environment. The OS is there but a lot of device drivers aren't. I got a binch of students to try it a few semesters ago, and that was their biggest complaint.
Yes, agreed - sort of, though I think the hardware rings of protection concept (as originated in Multics and implemented later in VME/B and, IIRC, OS/400) is much superior as it extends the kernelspace/userspace concept by allowing more than one protection level within both kernel and userspace.
Dunno if it would help performance as much as doing something finer grained to the process scheduler(s). However, it might help security by keeping everything out of kernelspace that doesn't absolutely have to be there. Though here again using page-level protection to prevent anything in a data page being executed and anything in a code page being written or read (as distinct from being fetched for execution).
That depends on linkage and dependencies. I think that a Mach-style kernel may have a smaller RAM image simply because no code is loaded unless it is about to be executed.
Extend this idea by splitting the code handling a kernel function into two modules (the expected path and the error handler) and you reduce the RAM image still further as well as speeding up execution simply because the vast number of invocations don't cause an error. If one does, the slowdown caused by loading the error handler is unimportant because (a) this is a rare event and (b) the chances are high that the process is about to be terminated, so who cares of error handling is a bit slower.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Since `wily` for RPi is one of my favourite utilities, I expect it's origin: plan9 to be no disappointment.
But I see that comp.os.plan9 has had no traffic since 2013 !
What's going on?
In every modern PC (Intel 80386 and up), there is a 4 ring protection hardware. It is just being ignored.
That was a known decision when Linux memory management was designed. The paged memory management could allow kernel code being pageable, in the same way as user code. The kernel code paging was dropped to prevent possible deadlocks from kernel code being paged out and needed to initiate the page-in.
What do you mean by 'error'.
All disk reads in Linux are triggered by page faults.
-- -TV
Yes, I know that: I think ignoring it is a mistake, but it seems to be a minimal implementation. Having a few more levels may add security: IIRC VME/B used separate protection levels to isolate user code from standard library functions as well as preventing it from executing its data space.
I was talking about dynamic loading rather than paging for Mach kernels: AFAIK if a seldom used SVC hasn't been executed since the last boot it won't occupy any address space. Once it has been loaded, of course its subject to the standard kernel paging algorithms.
Sure, but that's not an error in this context because it is part of normal operation. Its just a 'next block not in memory yet' state that you'd expect the relevant i/o module to deal with.
By 'errors' I mean situations that will prevent the SVC from completing successfully, such as an invalid call parameter or an attempt to access memory outside the process's stack frame or heap space. The 'mainline' SVC has to detect this type of error but will hand off dealing with it to another chunk of code. Its this error clean-up stuff I was referring to. It is only rarely used (how often do malloc/free get bad calls compared with the number of times they're used without any problem) so there's an advantage to putting it in a separate module that's only loaded if/when needed and can be either swapped out or unloaded when its job is done: this load/run/unload cycle will happen so rarely that its impact on performance is undetectable. Of course its effect on the kernel's memory footprint used to be a lot more important than it is now, but the increased modularity this approach offers may well help kernel maintenance and may even save code if an error module can be used by all the functions that can throw the same type of error.
-- martin@ | Martin Gregorie gregorie. | Essex, UK org |
Yes, it was supposed to be: "the 1st one is for learning, which you throw away, and then do the proper one".
Sure, I know about that. I'm asking about the sociology of plan9. The membership/useage. That's also what made RPi a success.
Since there's a public domain version, it shouldn't depend on Lucent. Or perhaps it's the herd effect: lack of critical mass?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.