Re: [ckrm-tech] RFC: Memory Controller

[Paul Jackson <pj@sgi.com>]

> - they require touching every architecture to add the new system calls
> - they're harder to debug from userspace, since you can't using useful
>   tools such as echo and cat
> - changing the interface is harder since it's (presumably) a binary API

To my mind these are rather secondary selection criteria.

If say we were adding a single, per-thread scalar value that each
thread could query of and perhaps modify for itself, then a system call
would be an alternative worthy of further consideration.

Representing complicated, nested, structured information via custom
system calls is a pain.  We have more luck using classic file system
structures, and abstracting the representation a layer up.  Of course
there are still system calls, but they are the classic Unix calls such
as mkdir, chdir, rmdir, creat, unlink, open, read, write and close.

The same thing happens in designing network and web services.  There
are always low level protocols, such as physical and link and IP.
And sometimes these have to be extended, such as IPv4 versus IPv6.
But we don't code AJAX down at that level - AJAX sits on top of things
like Javascript and XML, higher up in the protocol stack.

And we didn't start coding AJAX as a series of IP hacks, saying we can
add a higher level protocol alternative later on.  That would have been
useless.

Figuring out where in the protocol stack one is targeting ones new
feature work is a foundation decision.  Get it right, up front,
forevermore, or risk ending up in Documentation/ABI/obsolete or
Documentation/ABI/removed in a few years, if your work doesn't
just die sooner without a whimper.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/