Re: ctnetlink questions

[Balazs Scheidler <bazsi@balabit.hu>]

On Mon, Oct 20, 2003 at 08:37:42PM +0200, Harald Welte wrote:
> On Mon, Oct 20, 2003 at 08:43:02PM +0200, Patrick McHardy wrote:
> 
> > >The dump operation should be connetion oriented with the userspace 
> > >application, not purely datagram based. The kernel should know for certain 
> > >if the userspace application terminates a dump operation mid-air.
> > >
> > 
> > Actually the kernel knows. If the socket is closed cb->done() is called.
> > However the kernel can not know if userspace still keeps the socket open
> > but doesn't read anymore. Connection oriented sockets don't help with this.
> 
> yes, but if the application is broken, that's not our problem.  If the
> API and the behaviour is documented, I don't see any problems with this.
> If an app wants to intentionally allocate many opjects in kernel space,
> there's nothing we can do.  Also, since we are sending to userspace, we
> could actually allocate this as virtual memory, right?

Sorry to jump into the conversation, it just occurred something I've read
about relayfs:

quoting from the announcement:

"relayfs is a filesystem designed to provide an efficient mechanism for
tools and facilities to relay large amounts of data from kernel space
to user space.  Full details can be found in Documentation/filesystems/
relayfs.txt.  The current version can always be found at
http://www.opersys.com/relayfs."

This _might_ be of interest when complete tables are to be dumped, though
the ctnetlink based interface is better when the userspace app provides more
specific queries.

-- 
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1