lkml.org 
[lkml]   [2007]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [perfmon] Re: [perfmon2] perfmon2 merge news
    David Miller writes:

    > > You're suggesting that the behaviour of a read() should depend on what
    > > was in the buffer before the read? Gack! Surely you have better
    > > taste than that?
    >
    > Absolutely that's what I mean, it's atomic and gives you exactly what
    > you need.
    >
    > I see nothing wrong or gross with these semantics. Nothing in the
    > "book of UNIX" specifies that for a device or special file the passed
    > in buffer cannot contain input control data.

    Ohhhhh.... kayyyyy.... *shudders*

    It really violates the abstract model of "read" pretty badly. "Read"
    is "fill in the buffer with data from the device", not "do some
    arbitrary stuff with this area of memory".

    I'd prefer to have a transaction() system call like I suggested to
    Nick rather than overloading read() like this.

    > > Then you end up with two system calls to get the data rather than one
    > > (one to send the request and another to read the reply). For
    > > something that needs to be quick that is a suboptimal interface.
    >
    > Not necessarily, consider the possibility of using recvmsg() control
    > message data. With that it could be done in one go.
    >
    > This also suggests that it could be implemented as it's own protocol
    > family.

    There's all sorts of possible ways that it could be implemented. On
    the one hand we have an actual proposed implementation, and on the
    other we have various people saying "oh but it could be implemented
    this other way" without providing any actual code.

    Now if those people can show that their way of doing it is
    significantly simpler and better than the existing implementation,
    then that's useful. I really don't think that doing a whole new
    net protocol family is a simpler and better way of doing a performance
    monitor interface, though.

    Paul.
    -
    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: 2007-11-14 22:53    [W:4.173 / U:0.732 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site