Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)

[Chip Salzenberg]

According to [e-mail]:
>[e-mail] (Chip Salzenberg) wrote:
>>Why not have a kernel thread and use standard RPC techniques like
>>sockets?  Then you'd not have to invent anything unimportant like
>>Yet Another IPC Technique.
>
>kerneld (kmod's late unlamented predecessor) used to use Unix sockets
>to communicate from the kernel to the daemon.  It forced everybody to
>link Unix sockets into the kernel but there are some people out there
>who want to use it as a module.  Also the kernel code for communicating
>with kerneld was "unpleasant", see ipc/msg.c in a 2.0 kernel.

I see.

On the other hand, file-style (e.g. /proc-style) access works in Plan9
at least inpart because each client makes his own connection to the
server.  Thus, the question of how clients know which response is for
them is trivially solved.  ('Server' would in this case be the JFS
kernel thread.)

Sockets are apparently not the right way to go about getting
transaction support for kernel threads.

AFAIK, Alex Viro's idea of bindable namespaces provides effective
transaction support *ONLY* if there are per-process bindings.  With
per-process bindings, each client that opens a connection does so
through a distinct binding; when that client's responses go back
through the same binding, only that client can see them.

I hope that Alex's namespaces patch, implementing per-process
bindings, goes into the official kernel Real Soon Now.
-- 
Chip Salzenberg              - a.k.a. -             <[e-mail]>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech