Re: Connector - how to start?

[Evgeniy Polyakov]

On Sat, Apr 15, 2006 at 03:24:26PM +0200, Libor Vanek (libor.vanek@xxxxxxxxx) wrote:
> > > However, with 256 I get "File name too long", as you did.
> >
> > Sure, as pointed in previous e-mail, several concatenated directories can exceed any resonable limit,
> > even PATH_MAX (4k):
> > $ pwd | wc
> >       1       1    4113
> >
> > So it is wrong idea to transfer the whole name in one message, which
> > will not only add huge overhead (for each subdir one must transfer the
> > whole path for the parent dir), but can be impossible to allocate such a
> > buffer in kernelspace to store the whole pathname.
> 
> OK, so what would you suggest as the right "tool" to transfer these
> (full path text) information?
> 
> I see these options:
> 1, Keep using procfs (I don't like it)
> 2, Use connector and create such "communication protocol" that it'll
> be able to transfer such long messages in more datagrams (even if
> 99.99% of messages will fit 1 datagram)
> 3, Some other API to transfer information to user-space and back?
> 
> I'll probably go with 2, but I'd be more then happy to hear any
> comments about this...


In general case using any tool you will be unable to transfer the whole
path in one shot, consider low memory condition and you try to allocate
a page with high order.
So it is required to split your path into multiple blocks, I would
recommend to use messages with names between slashes, i.e.
/home/test/aaa/bbb/ccc will be sent as 5 messages with /home, test, aaa,
bbb and ccc data, this will also reduce overhead when there are several
files or directories in one parent dir. Each message should also include
some reference to which parent dir it belongs. This will also speed
things up noticebly, since you will not rescan the whole path when new
file is created, only parent dir.

I wish you success in this hacking journey.

> Libor Vanek

-- 
	Evgeniy Polyakov
-
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/