"Eric S. Raymond" wrote:
>
> (Please copy any replies to me explicitly, as I'm not presently subscribed
> to the linux-kernel list -- it's not practical when I'm spending so
> much time on the road.)
I'm sure you're getting plenty of mail on the topic that you rose on
the kernel
list. There's a commercial operating system that works on pretty much
the same
concepts as EROS and it's been out since 1988. It's the IBM AS/400. I
thought
I'd just point out that this idea has been out for years and is actually
in
a production commercial OS that businesses are actually using.
http://as400.rochester.ibm.com/
> EROS is built around two fundamental and intertwined ideas. One is
> that all data and code persistence is handled directly by the OS.
> There is no file system. Yes, I said *no file system*. Instead,
> everything is structures built in virtual memory and checkpointed out
> to disk every so often (every five minutes in EROS). Want something?
> Chase a pointer to it; EROS memory management does the rest.
It's a "single level store" environment so like EROS it's all memory
and
the OS pages things in as you use it.
Also the Apple Newton worked much the same way, while the Newton
wasn't a
multiuser really full OS like the AS/400 is... they definately did some
innovative things at Apple. But back to the 400 cause it's what I know.
There is the concept of a file system on the AS/400 (Well actually it
has several) which is built on top of a relational database. Our main
"filesystem" is a library / file / member setup. And our IFS file system
is actually a full standard file system just like you see on Linux.
http://www.as400.ibm.com/techstudio is probably has a few more techie
details... but it's not quite to the depth or quality of information you
folks are talking about here...
If you're interested I'll see if I can find a better "here's the 400 and
what
it's all about" kinda information on the web or maybe better yet you
come
out and talk to us about Linux and we'll tell ya about the 400. 8-)
Anyway back to some "real" talk.
> Here's another: All disk I/O is huge sequential BLTs done as part of
> checkpoint operations. You can actually use close to 100% of your
> controller's bandwidth, as opposed to the 30%-50% typical for
> explicit-I/O operating systems that are doing seeks a lot of the time.
> This means the maximum I/O throughput the OS can handle effectively
> more than doubles. With simpler code. You could even afford the time
> to verify each checkpoint write...
I agree with you and I think from the 400's performance numbers I'd
agree that
the single level store environment gives you advantages as far as I/O is
concerned. The disadvantage tho is if you lose a disk in a multidisk
system. If you're not in a RAID environment it can make life
interesting.
Additionally since everything is just memory you have to be careful to
really
release memory if you don't it could be paged out to disk forever ... or
in the case of the 400 we have a reclaim storage command that
effectively acts
like a garbage collector.
Pointers are key to a single level store environment... on the 400 we
have
several different kinds of points and we are very stricts as to what you
can
and can not do with them. For one thing the old trick of casting a
number
to an address to dereference is gone... can't do any of that on the 400
as that'd be a bigtime security hole. We have
Open
Pointers that can hold any of the other pointer types.
Space
Generic pointers to data objects.
Function
System pointers to *PGM objects or procedure pointers to bound
ILEprocedures.
System
Pointers to system objects such as queues, indexes, libraries, and
*PGM objects.
Label
Pointers to fixed locations within the executable code of a
procedure or function.
Invocation
Pointers to process objects for procedure (function) calls under
ILE, or program calls under EPM or OPM.
Suspend
Pointer to the location in a procedure where control has been
suspended.
Interestingly enough (and you eluded to this in your initial note) the
step of saving and restoring data really doesn't go away. After all if
you
are going to ship that data over the wire that's exactly what you have
to do
and the application writers still seem to employ that concept... tho I
sure
a certain amount of that is on accout that developers haven't grok'd
what's possible on the 400.... However for
the OS hackers such as myself the ability just to stuff things into
persistent
memory is quite handy.
Well enough blathering on my part....
--
Hakuna Matata! |\ _,,,--,,_ ,)
Tom /,`.-'`' -, ;-;;'
|,4- ) )-,_ ) /\
import standard.disclaimer.*; |||| '---''(_/--' (_/-'
Tom Gall - Java Guy ____ "Where's the ka-boom? There was
IBM Rochester - Sapere aude \ /\ supposed to be an earth
(w) tom_gall@vnet.ibm.com \__/_/ shattering ka-boom!"
(h) tgall@uswest.net ------ -- Marvin Martian
"Here's to the crazy ones. The misfits. The rebels. The troublemakers.
The round pegs in the square holes. The ones who see things differently.
The ones that change the world!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/