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
On Tue, 27 Nov 2001, Joe Korty wrote:
> 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. [...]
yep, agreed. Also, /proc might not be mounted in eg. a chroot environment.
(a number of security-conscious servers do this.) Or it might not be
mounted at all, for whatever reason.
> 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.
i'm not against the /proc interface either - on the contrary, i've picked
it when implementing /proc/irq/<NR>/smp_affinity.
Ingo
On Tue, 2001-11-27 at 06:32, Ingo Molnar wrote:
> > 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.
>
> i'm not against the /proc interface either - on the contrary, i've picked
> it when implementing /proc/irq/<NR>/smp_affinity.
What if we kept the procfs interface for read only and keep both
syscalls for read and write ?
The proc read interface is 2 lines of code in one function ... very much
of my patch would be gone. Again, personally, I'd like to see proc for
writing and reading, but ...
Robert Love