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    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site