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?
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.
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.
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.
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.
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.
Eric
--
