Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
On Sun, 20 May 2001, Edgar Toernig wrote: > IMHO any similar powerful (and versatile) interface will see the same > problems. Enforcing a read/write like interface (and rejecting drivers > that pass ptrs through this interface) may give you some knowledge about > the kernel/userspace communication. But the data the flows around will > become the same mess that is present with the current ioctl. Every driver > invents its own sets of commands, its own rules of argument parsing, ... > Maybe it's no longer strange binary data but readable ASCII strings but > that's all. Look at how many different "styles" of /proc files there are. Too many people who don't know C and manage to get their crap into the tree. Shame, but that is _not_ a technical problem. > IMHO what's needed is a definition for "sane" in this context. Trying > to limit the kind of actions performed by ioctls is not "sane". Then > people will always revert back to old ioctl. "Sane" could be: network > transparent, architecture independant, usable with generic tools and non > C-like languages. /me points to UNIX-like OS that had done that. BTW, network-transparent means "no pointers"... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
Alexander Viro wrote: > > 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/ Oh come on. You made most of the VFS and should know better. Since when is it possible to always get a "usable" name for an fd??? The ls -l will give me "deleted", "socket", "...". If I try to access the name given by procfs I may get EPERM, etc etc. And then, it's pretty strange to append a "ctl" to some arbitrary name and I get a control device for that name??? No. Using names is __wrong__! > [not going to happen:] > 1) sys_ioctl() going away from syscall table. I would never suggest that. > 2) semi-automatic conversion of existing applications. Same. Much too dangerous. > 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. Don Quijote II.? ;-) IMHO any similar powerful (and versatile) interface will see the same problems. Enforcing a read/write like interface (and rejecting drivers that pass ptrs through this interface) may give you some knowledge about the kernel/userspace communication. But the data the flows around will become the same mess that is present with the current ioctl. Every driver invents its own sets of commands, its own rules of argument parsing, ... Maybe it's no longer strange binary data but readable ASCII strings but that's all. Look at how many different "styles" of /proc files there are. > 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. You can impose some rules like "must support" commands, something of how arguments are encoded, errors reported and so on. But I wouldn't like to see an SNMP like mess... IMHO what's needed is a definition for "sane" in this context. Trying to limit the kind of actions performed by ioctls is not "sane". Then people will always revert back to old ioctl. "Sane" could be: network transparent, architecture independant, usable with generic tools and non C-like languages. Ciao, ET. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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/ 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
Alexander Viro wrote:
>
> For the latter, though,
> we need to write commands into files and here your miscdevices (or procfs
> files, or /dev/foo/ctl - whatever) is needed.
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.
So, if you want an additional communication channel to a device why
not introduce an fcntl or system call like
cltrfd = fcntl(fd, F_CTRLFD)or openctrl(fd) ?
That way you can always get access to the control channel and use
regular read/write for communication [1]. To make it more versatile,
you may want to extent the shell syntax, i.e. a '@' in redirection
operators get the control fd:
echo "eject" >@/dev/cdrom
{ echo "b19200,onlcr" >@1 ; echo "Hello World!" ; } >/dev/ttyS0
Yes, requires support in user space apps but doesn't mess around
with the file namespace. It's too precious to sacrifice ;-)
I don't know how much infrastructure in the kernel is required for this
- i.e. add readctrl/writectrl methods or create virtual inodes/devices
on the fly? There are more capable people than me to judge on that...
Ciao, ET.
[1] If you want you can even allow this flag as an open mode to
open the ctrl channel without opening the dev.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
Alexander Viro wrote:
For the latter, though,
we need to write commands into files and here your miscdevices (or procfs
files, or /dev/foo/ctl - whatever) is needed.
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.
So, if you want an additional communication channel to a device why
not introduce an fcntl or system call like
cltrfd = fcntl(fd, F_CTRLFD)or openctrl(fd) ?
That way you can always get access to the control channel and use
regular read/write for communication [1]. To make it more versatile,
you may want to extent the shell syntax, i.e. a '@' in redirection
operators get the control fd:
echo eject @/dev/cdrom
{ echo b19200,onlcr @1 ; echo Hello World! ; } /dev/ttyS0
Yes, requires support in user space apps but doesn't mess around
with the file namespace. It's too precious to sacrifice ;-)
I don't know how much infrastructure in the kernel is required for this
- i.e. add readctrl/writectrl methods or create virtual inodes/devices
on the fly? There are more capable people than me to judge on that...
Ciao, ET.
[1] If you want you can even allow this flag as an open mode to
open the ctrl channel without opening the dev.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
On Sun, 20 May 2001, Edgar Toernig wrote: IMHO any similar powerful (and versatile) interface will see the same problems. Enforcing a read/write like interface (and rejecting drivers that pass ptrs through this interface) may give you some knowledge about the kernel/userspace communication. But the data the flows around will become the same mess that is present with the current ioctl. Every driver invents its own sets of commands, its own rules of argument parsing, ... Maybe it's no longer strange binary data but readable ASCII strings but that's all. Look at how many different styles of /proc files there are. Too many people who don't know C and manage to get their crap into the tree. Shame, but that is _not_ a technical problem. IMHO what's needed is a definition for sane in this context. Trying to limit the kind of actions performed by ioctls is not sane. Then people will always revert back to old ioctl. Sane could be: network transparent, architecture independant, usable with generic tools and non C-like languages. /me points to UNIX-like OS that had done that. BTW, network-transparent means no pointers... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: F_CTRLFD (was Re: Why side-effects on open(2) are evil.)
Alexander Viro wrote: 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 Oh come on. You made most of the VFS and should know better. Since when is it possible to always get a usable name for an fd??? The ls -l will give me deleted, socket, If I try to access the name given by procfs I may get EPERM, etc etc. And then, it's pretty strange to append a ctl to some arbitrary name and I get a control device for that name??? No. Using names is __wrong__! [not going to happen:] 1) sys_ioctl() going away from syscall table. I would never suggest that. 2) semi-automatic conversion of existing applications. Same. Much too dangerous. 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. Don Quijote II.? ;-) IMHO any similar powerful (and versatile) interface will see the same problems. Enforcing a read/write like interface (and rejecting drivers that pass ptrs through this interface) may give you some knowledge about the kernel/userspace communication. But the data the flows around will become the same mess that is present with the current ioctl. Every driver invents its own sets of commands, its own rules of argument parsing, ... Maybe it's no longer strange binary data but readable ASCII strings but that's all. Look at how many different styles of /proc files there are. 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. You can impose some rules like must support commands, something of how arguments are encoded, errors reported and so on. But I wouldn't like to see an SNMP like mess... IMHO what's needed is a definition for sane in this context. Trying to limit the kind of actions performed by ioctls is not sane. Then people will always revert back to old ioctl. Sane could be: network transparent, architecture independant, usable with generic tools and non C-like languages. Ciao, ET. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
