Re: [PATCH][RFC] relayfs (1/4) (Documentation)

[Richard J Moore]

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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/