lkml.org 
[lkml]   [2001]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectprocfs bloat, syscall bloat [in reference to cpu affinity]
An argument  of `it's bloat, don't do it!' against the addition of a new 
system call (or a new
procfs entry) is somewhat meaningless, as `bloat' is a word so broad and
ill-defined that
applying it as an argument has the potential of stopping useful
enhancements to the Linux
user interface, or preventing the best possible user interface from being
implemented
at the outset. If one is going to be concerned about bloat (as I am and as
almost everyone
should be), one needs another yardstick to apply, one that can illuminate
those proposals
which are Good (and hence non-bloating) and those which are Crud (and hence
can be
safely condemned for the crime of bloat).

The yardstick I would like to apply here is: is the user's view of the new
service something
that is simple and fundamental, unlikely to change as Linux moves from
platform to platform
and evolves over time, or is it something quirky, tied to the current
implementation and
exposes its complexities to the user in ways that the interface is
guaranteed to change
as Linux evolves? Examples of the first type of interface are read(2),
write(2), open(2),
memcopy(3), cos(3). These have been with us from the beginning of time and
no one
imagines them going away or changing in any fundamental way. On the other
hand, the
IDE driver tuneables would be an example of the quirky second kind -- this
interface
will change as new IDE controller chips become available, and have few (if
any) connection
with, say, any equivalent SCSI tuneables, yet both control similiar kinds
of devices.

So my rule is, services of the first kind, the ones that are simple and
eternal, should be
system calls, while the quirky second kind should be consigned soley to the
proc fs.

I feel that the cpu affinity services are of the first kind. They are very
simple, very
conceptual services that have absolutely no tie in to any architecture
other than it
be SMP, and even on uniprocessors they reduce down gracefully to the null
state. Once
defined, if defined well, they have the potential of lasting forever much
like pipe(2) etc
does today. Part of what I see that makes affinity as being `eternal' is
that there is
nothing about the user view of affinity that is even Linux specific -- one
could see other unices having exactly the same services with exactly the
same semantics, and perhaps
even radically different OSes such as NT easily supporting identical, or
nearly identical
affinity services. It is this universality that makes cpu affinity
services likely syscall
candidates.

I am not against a proc interface per se, I would like a proc interface,
especially for the
reading of affinity values. But in my view the system call interface
should also exist
and it should be the dominate way of communicating affinity to processes.

Joe

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:18    [W:0.179 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site