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

How it can be used? Well, say it you've mounted JFS on /usr/local

There's a lot of cool simplicity in this, both in implementation and application, but it leaves something to be desired in functionality. This is partly because the price you pay for being able to use existing, well-worn Unix interfaces is the ancient limitations of those interfaces -- like the inability to return adequate error information.

Specifically, transactional stuff looks really hard in this method. If I want the user to know why his "defrag" command failed, how would I pass that information back to him? What if I want to warn him of of a filesystem inconsistency I found along the way? Or inform him of how effective the defrag was? And bear in mind that multiple processes may be issuing commands to /mnt/control simultaneously.

With ioctl, I can easily match a response of any kind to a request. I can even return an English text message if I want to be friendly.

hmm... open("defrag-error") first, then read from it if it fails?

you should probably serialise them. you probably have to do this anyway.

yes, one of the nice plan9 changes was the change to returning strings instead of numerics.

Revolutions do not require corporate support.

Or just do
(echo $cmd; read reply) <file >&0
and make write() queue a reply. Yup, on the struct file used for write().

You _will_ need serialization for operations themselves, but for getting replies... Not really.

So you can with read(). You know, the function that is intended to be used for reading stuff into user-supplied buffer...

I can imagine a solution to this using the _same_ method - extend /proc/*/ with a new entry (say, trace) for dumping errors. Put data in there from every failing function in your code. Normally, this will not introduce overheads (not unless you use error conditions to pass on useful information), however, in case of errors, you can get the backtrace (together with any info you want to put in there) immediately.

That's all up to you. Informational messages can go to /proc. Transactions/serialization can be done in your filesystem's implementation. Maybe glibc guys would even want to extend strerror() to handle these cases?

Cheers,

Pjotr Kourzanov

In article <OF791BBBC5.E3FCBEEE-ON87256A18.005BA3B7@LocalDomain> you write:

But ioctl requires allocation of numbers. Ugly and hard to scale.

Alex Viro's idea is cleaner, but still requires a fair amount of coding even for simple interfaces.

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.

Chip Salzenberg              - a.k.a. -             <[email protected]>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

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.

According to [email protected]:

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. -             <[email protected]>
 "We have no fuel on board, plus or minus 8 kilograms."  -- NEAR tech

[email protected] (Chip Salzenberg) wrote on 01.04.01 in <E14jdkF-0007Ps-00@tytlal>:

You can, of course, transfer the exact same RPC messages over a file descriptor on your metadata fs. It doesn't *have* to be ASCII, especially not for purely internal-use interfaces.

And for ioctl() fans, you could transfer the exact same data via read()/ write() again. That's not significantly harder. Especially if you write a wrapper around the calls. If you want to be perverse, you can probably even transmit user space pointers.

But I suspect there are really only two generally useful interfaces:

1. A text based interface for generally-useful stuff you might want to manipulate from the shell, or random user programs. (From the shell _is_ random user programs.)

2. A RPC based interface for tightly-coupled fs utilities. (I don't know off the top of my head what the kernel already has - ISTR networking has _something_.)

Don't forget a version marker of some kind. Sooner or later, you'll be glad you have it.

MfG Kai

Not really. We can both open /proc/partitions, read one char at a time, and the kernel won't confuse our read positions. Different file opens create different instances of state. See struct file, void *private_data for how to store arbitrary data.

tv@{{hq.yok.utu,havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
unix, linux, debian, networks, security, | First snow, then silence.
kernel, TCP/IP, C, perl, free software,  | This thousand dollar screen dies
mail, www, sw devel, unix admin, hacks.  | so beautifully.