The only way way to go, unless there is a local driver to interpret
the IOCTL, collect the needed data, then transfer it (only once..) and then
transfer the return value back.
>Hmm..
>
> ssize_t write(int fd, const void *buf, size_t count);
>vs
> newioctl(fd, ptr, length);
or even
ioctl(fd, ptr,...)
No difference. other than the inability to distinquish from the data transfer
read/write...
IOCTLs (no matter what you call them) are there for out-of-band data. What
the control data is happens to be is up to the filesystem/driver. Some of them
have standardized interfaces, many more do not. As far as security goes,
they still have to be optionally audited. Control over what is transferred
doesn't have to be enforced - the open of the fd covers that.
The only time I can think of that would require more is when removable media
has a mandatory lable - Users shouldn't be able to overwrite the label. I
do think that this can be handled in a relatively simple way (of course I
don't happen to have one handy...).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/