[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-discuss
Subject:    Re: [osol-discuss] OpenSolaris cancelled,
From:       "Richard L. Hamilton" <rlhamil () smart ! net>
Date:       2010-09-09 15:25:09
Message-ID: 1453343359.411284071140212.JavaMail.Twebapp () sf-app1
[Download RAW message or body]

> Are you speculating or do you have some substance?
> You seem to know a bit about AIX kernel code?

He's not wrong about AIX history - it has had parts of its
kernel pageable for a long time.  But that is less important now
than it was once, esp. since CPUs are so fast, and disks, while large
capacity, haven't kept up in terms of speed increases.

But I don't know that there's reason to believe that IBM would dump
the AIX kernel, although they might well want to simplify it.

As a matter of history, while most other Unix implementations didn't
have pageable kernels, they did have a vestige of swapping, which
let one particular per-process kernel data structure be written out
to swap when the process was seriously idle.  The original division
struct proc and struct user dates back to before demand paging, when
entire processes were swapped out (no V-to-P translation and memory
management hardware back then).  At that time, struct proc was an
array (later, other structures to make it dynamically resizable; but
originally one had to recompile some kernel object files to tune) of
all the per-process data that had to be in memory at all times, with
a pointer to a struct user; struct user for the current process could
be accessed via "struct user u" (but not by interrupt handlers, which
didn't have process context), while others would be elsewhere in
memory or written off to swap.  I'd written a user-space implementation
of "fuser" for an SVR2 based system; demand paging at that time,
but still with the ability to swap out the user struct.  It had to look
read the proc array in from /dev/kmem, and then look at each one
and try to track down whether the user struct for that process was
in memory or on disk, so that it could fetch it to follow the file
descriptors to the file table and then to the inode table, to eventually
see if the inode matched that of the file whose use one wanted to
check on.

At some point (I don't recall if SunOS 4.x kept struct user in RAM or
swapped it out), SunOS/Solaris went to keeping the user struct in
RAM at all times.  Probably as memory got bigger and cheaper, it
wasn't worth the bother of swapping out the user struct anymore,
and gave better performance not to.  So now, struct user is
entirely within struct proc on Solaris.

(And don't even think about systems that used a microkernel,
which could have done even stranger things.  Not just Mach-based,
either.  Remember Apollo Domain OS?  Or Sun's experimental "Spring" OS,
from which came the doors mechanism?  Or Chorus, which Sun owned
for awhile, before releasing the parts they owned?  (That's changed hands
a couple of times since then.))

So the history part rings true enough.  But since AIX as we know it
now is only on Power CPUs, it's not like IBM needs all those x86
drivers from BSD or Linux anyway.  So replacing their kernel with
something else (with all the work required to keep binary application
compatibility and performance) may well not make sense.
-- 
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]