Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 03 Sep 2008 14:51:10 -0700 | Subject | Re: [PATCH 5/7] FUSE: implement ioctl support |
| |
Tejun Heo <tj@kernel.org> writes:
> Eric W. Biederman wrote: >> I really think that if an ioctl is passing through the kernel we >> should know how to parse and understand it's options. Otherwise >> we won't have the option of doing backwards compatibility when something >> changes, like we can with the 32->64bit ioctls. > > There's no reason 32->64bit can't be handled in userland? What's the > difference?
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.
>> That seems to imply that you need a stub in the kernel to handle >> really weird ioctls. >> >> The upside is that because you know what the inputs and outputs are >> and where the inputs and output are you can support that ioctl well >> into the future, and you can do it with an unprivileged file >> system server. > > 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.
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
| |