Eric W. Biederman wrote:
quoted text
> Maintenance.  What happens if I go 128bit, if I have some processes
> that are big endian and some that are little endian.  Or if I have
> some processes that are running a completely different instruction
> set with a completely different ABI than other processes.  Or
> perhaps different perhaps the processes is in a different network
> namespace than your filesystem and so it's arguments refer
> to something different entirely.  Is it a userspace bug if userspace
> does not anticipate how the kernel will change in the future?

What I don't see is how anything becomes different whether that part
is implemented in kernel or not.  For ioctls, only the implementing
code knows what the data structure should look like that's why we
can't handle 64/32 bit problems generically and has ->compat_ioctl
hook.  To me, splitting it to two pieces looks like more maintenance
overhead than the other way around.

quoted text
> If we don't look at ioctl as a set of system calls that should
> be put into an appropriate format for a filesystem we have
> a maintenance problem.
>
> If we don't have an interface clean enough we can push data
> out to a server on a remote machine have it processes the
> arguments and send the data back.  We actually have failed
> to properly abstract the interface.

I don't think that's a possible goal in generic manner.  We can't even
do that for read/writes.  At least not at FUSE's level.  We need
higher abstraction for that.  e.g. /dev/oss via CUSE, ioctl specified
machine endian 16bit format.  Supporting that in the way you described
would require a lot of logic in the kernel and I don't really see any
benefit over, say, forward the sound via pulseaudio after getting it
to userland.  I don't think the problem can or should be solved at
FUSE interface level.

quoted text
>> Well, kernel stub kind of beats a lot of benefits of FUSE - no
>> specific kernel dependencies, easy development and distribution,
>> etc...
> 
> Of course FUSE has specific kernel dependencies.  It depends
> on the implementation of fusefs in the kernel to talk to it.
> The reason you don't need a specific kernel today is that
> the kernel dependencies are well defined.  You are talking
> about using a very poorly defined interface to talk to the
> filesystem.  At which point it would be better to open
> a separate channel and talk to the filsystem directly.

The difference is that FUSE servers depend on FUSE and each server
doesn't require separate new pieces to get working and ioctl is poorly
defined by nature.

quoted text
> Being able to add a kernel system call (ioctl) with no review is a
> total maintenance disaster.  It is impossible to maintain because
> there is not a process to even discover what is going on.

How about adding whole FSes w/o a review?  That's the whole point of
FUSE.  Seriously, there are infinite number of ways to break the
regular defined filesystem semantics using FUSE.  FUSE should provide
mechanism and protects against certain fundamental things.  It can't
enforce correct semantics on everything.

quoted text
> We have to have a kernel stub to support other system calls
> and I don't see why individual ioctls should be different.
> 
> If you want to support forwards compatibility reserving
> some ioctl numbers and saying these numbers will always
> be parsed this way.  Which would allow you to write
> a common stub that can be implemented before the ioctls
> are implemented.

ioctls is most likely to be used to emulate legacy or proprietary
devices.  If you're worried about filesystems abusing it, maybe the
solution is to only allow CUSE to use ioctls but I really don't see
what the problem is here.  If the userland FS server wants to shoot
itself in the foot, it's not really the kernel's problem.

quoted text
> If you really don't want new kernel dependencies you can hook up to
> the process via ptrace and intercept the ioctls before they even get
> to the kernel.  If you can open /proc/<pid>/mem you have the rights
> to ptrace the process.

Aieee.. The same goes for the whole FUSE.

Thanks.

-- 
tejun
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/