Re: Mapping a piece of one process' addrspace to another?

[Alexander Viro <viro@math.psu.edu>]

On Wed, 7 Mar 2001, Abramo Bagnara wrote:

> > No, they don't. OOB data is equivalent to data on parallel channel.
> 
> Al, you're perfectly right in principle (although last time I've checked
> pipe and unix socket did not support OOB data. Is this changed
> recently?).

ioctl() is OOB stuff. Replace with second pipe and you don't need it
anymore.

> But you're forgetting that we need to cope with non collaborative
> applications (that *use* ioctl).

Erm. If ioctls are device-specific - the program is already bound to
specific driver. If they are for class of devices (and if I guessed
right that's the case you are interested in - sound, isn't it?) we
could let the stub driver in kernel open two pipes and redirect
read()/write() on device to the first one turn ioctls into read()/write()
on the second. That way you can get userland programs serving that
stuff with no magic required.

I mean something along the lines of

foo_write(struct file *file, char *buf, size_t size, loff_t *ppos)
{
	return f1->f_ops->write(file, buf, size, ppos);
}
foo_ioctl(struct file *file, int cmd, long arg)
{
	loff_t dummy;
	switch (cmd) {
		case SNDCTL_DSP_RESET:
			f2->f_ops->write(file, "dsp_reset", 10, &dummy);
			return 0;
		....
	}
}
where f1 and f2 are named pipes opened at init time. Notice that
it doesn't introduce extra copying - just splits the stream with OOB data
into two normal byte streams that can be served by naive userland code.
After that any client that uses current sound API is able to talk to
userland drivers and said drivers don't have to pull any special tricks -
they just open two pipes and do usual select()/read()/write() loop.
Kernel side is also quite simple that way - plain redirect for read/write
and trivial decoder for the sound ioctls.
							Cheers,
								Al