Fwd: Request for review of SCOPE gaps document

[dan@xxxxxxxxxxx (Dan Kohn)]

Jonathan Corbet, the editor of LWN <http://lwn.net/> and the Linux
Weather Forecast <http://www.linux-foundation.org/lwf>, generously
gave the SCOPE gaps document a quick review, attached below.  He can't
make the call today, but hopefully will be able to participate on the
next CGL call.

- dan

-- 
Dan Kohn <mailto:dan@xxxxxxxxxxx>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>


---------- Forwarded message ----------
From: Jonathan Corbet <corbet@xxxxxxx>
Date: Nov 15, 2007 8:59 AM

OK, I've spent a moment looking through it.  There is community
sensitivity about being handed a shopping list, but there is also value
in knowing what our users would like to have.  As long as the attitude
is right, there should be no harm in this sort of exercise.

My immediate impression is that a lot of what they want is already in
the works.  The following is all very much my own opinion only, some of
it's probably wrong.  But what the heck...

Fault resistant filesystem: much of what they want exists with current
journaling filesystems.  Some of what they ask for (allocation
reservations) is falling into place now.  Other parts (online
defragmentation) are slowly being worked on.  Some of the rest (block
checksums, fast/writable snapshots) is called Btrfs, which would
certainly come along faster if they put some resources into helping its
development.

Documentation of tunable parameters: not what it should be (hey, let's
hire a doc writer to do that!), but not really a big job to take care
of.  The effort which went into creating this "gaps" document could have
made some serious progress against this "high priority" (meaning "start
implementation now") objective.

Trust mechanisms: getting things like remote attestation into the kernel
is likely to be controversial, but I would *guess* that Linus would be
inclined to let it in.  The code for all of this stuff exists, and has
for a few years, it's mostly a matter of getting it into shape for
merging.  The current developers seem to post it once every other year,
get a bunch of comments, then vanish.

Signed executables: I believe patches exist for this too.

Unified crypto framework: I don't know as much about this as I would
like to.  The key management infrastructure in the kernel now should be
part of what they want.  There's also quite a bit of crypto capability
in the kernel, including some hardware acceleration support.  I'm not
sure what has been done to export those capabilities to user space,
though.

Role-based access control: see SELinux (long since merged) or SMACK
(coming soon).  File capabilities also went in; they could also be used
to implement this sort of scheme.

"Efficient process CPU usage": (really "efficiently-obtained information
on process group CPU usage").  I do believe the group scheduler (2.6.24)
has the necessary pieces for that.  Certainly the information is there,
it's mostly a matter of how hard it would be to get it out.

CGL 4.0 tests.  Nobody's stopping them from writing them anytime they
want.

Persistent shared memory: something along these lines could be
implemented now with SYSV SHM and a process to save it to persistent
storage and bring it back.  If they want a region of RAM which remains
untouched over unexpected reboots and is waiting for them when the
system comes back, that's not there now.  It could be implemented
without *too* much trouble, I think - it would be a mechanism not to
dissimilar to the crash dump kernel stuff that's done now.  Merging it
could require some persuasion.

Tracing framework: see SystemTap, LTTng, etc.  Pieces are (very) slowly
making their way into the mainline, this should be a nicely solved
problem eventually.  The needed components exist now.

Coarse resource enforcement: this looks like a combination of the group
scheduler and the various resource controllers which are in the works
now.

IP routing and forwarding: I could have sworn we could route IP
already...  Maybe what they want is some combination of IP aliases and
the network namespace stuff?  I'm not too clear on it.

IPv6 in NFS and NIS: there are people working on NFS.  If CGL really
depends on NIS, I worry about any network which is using it.  That's a
user-space problem, in any case.  But...these people really use NIS?

Layer 2 tunneling: I can't really speak to this one.  Ask Mr. Hemminger,
he'll know.

Discovery of platform architecture: much of the info they want is in
/sys now, right?  Adding the rest should not be hard.

Latency domains: sounds like cpusets and memory policy.  It looks like
what they need in addition is better access to information about the
system architecture, so this looks like the previous item.  Ulrich
Drepper's libNUMA might help here.

jon