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:4.062 / U:0.680 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site