Messages in this thread | | | From | Richard J Moore <> | Subject | Re: [PATCH][RFC] relayfs (1/4) (Documentation) | Date | Wed, 15 Oct 2003 16:56:06 +0000 |
| |
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/
| |