lkml.org 
[lkml]   [2003]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH][RFC] relayfs (1/4) (Documentation)
    Date
    I have read the RCF and I have to say that  I am left with the impression that 
    relayfs and netlink are more or less orthogonal in what they try to achieve.
    If I'm wrong in this I'd like to know as I have no wish to push an
    alternative to any existing function of equivalent or superior capability.

    In messaging terms relayfs is more about he collation of parts of a message
    rather than the sending of multiple messages to a session partner. There are
    three aspects in which relayfs radically differs from netlink:

    1) it does not require a partnership -- a client and serve, or session pair --
    it is simply a buffering mechanism that allows data be deposited. There is
    no expectation that the data will be consumed or that there is a listening
    partner. The reason fore this design point comes from the origin of relayfs
    as a buffering mechanism that satisfies the needs of a low-level system
    trace. Data from a trace might never be consumed if the system, sub-system or
    component never fails.

    2) data can be deposited from any context - interrupt time, task time, sysinit
    in particular.

    3) the depositing of data with relayfs has to depend one a very simple
    interface and infrastructure in order to function under a severely damaged
    system. My impression is that netlink depends a significant infrastructure.

    Are these three points catered for by netlink?

    --
    Richard J Moore
    IBM Linux Technology Centre

    On Tue 14 October 2003 4:44 pm, David S. Miller wrote:
    > On Tue, 14 Oct 2003 11:32:28 +0000
    >
    > Richard J Moore <rasman@uk.ibm.com> wrote:
    > > Interesting, that assumes sequential processing, if not semi-synchronous
    > > processing of events on the receiver side, which is far from guaranteed
    > > when considering low-level tracing especially for flight-recorder
    > > applications.
    >
    > With netlink you may receive the data asynchronously however you
    > wish after you've requested a dump.
    >
    > I would like to ask that you go study how netlink works and is used
    > by things like routing daemons before we discuss this further as
    > it looks to me like half the conversation is going to be showing
    > you how netlink works. And hey there's even an RFC on netlink :)
    > -
    > 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/
    -
    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:49    [W:0.021 / U:0.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site