Messages in this thread | | | Date | Sun, 20 May 2001 12:20:26 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.) |
| |
On Sun, 20 May 2001, Edgar Toernig wrote:
> IMHO any scheme that requires a special name to perform ioctl like > functions will not work. Often you don't known the name of the > device you're talking to and then you're lost.
ls -l /proc/self/fd/<n>
and think of the results. We can export that as a syscall (fpath(2)), BTW.
Again, folks, there are two things that are no going to happen:
1) sys_ioctl() going away from syscall table. Binary compatibility with existing userland stuff that deals with networking ioctls. Unlike special-case device ones, they really have a lot of users. Standard rules are "2 stable releases until we remove a syscall".
2) semi-automatic conversion of existing applications. To hell with the way we are finding descriptor, we need to deal with arguments themselves. And no extra logics in libc will help - the whole problem is that ioctls have rather irregular arguments.
So "make it look as similar to ioctl() as possible" is not a good gaol. It would be, if we were preparing to do mass switching to new mechanism with minimal changes to existing codebase. Not realistic.
What we need is "make it sane", not "inherit as many things from the old API as possible". And obvious first target is Linux-specific device ioctls, simply because they have fewer programs using them.
Networking ioctls are there to stay for quite a while - we'll need at the very least to implement old ones in a userland library. Portability issues will be nasty, since _that_ stuff is used by tons of programs.
- 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/
| |