Messages in this thread | | | Date | Fri, 22 Jan 1999 13:53:36 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Adding checkpointing API to Linux kernel |
| |
On Fri, 22 Jan 1999, Michael Elizabeth Chastain wrote:
> Hi Pavel, > > > PS: How many things would break if we forced ioctls to _always_ pass > > > > struct foo { > > int len; > > char data[len]; > > } ? > > Everything would break. Remember that lots of programs use terminal > control ioctls. > > So far I've seen two design ideas. One is an new 'nioctl' system call > which takes 'len' as a fourth parameter. The other is to add > 'ioctl_register' and 'ioctl_unregister' to the kernel, so that the > kernel knows this information and can export it, even though the > information is not present in the API.
These can't accomplish the same thing: ioctl_register won't help the ioctl handler figure out how many bytes you passed it for a variable-length block. If the registration mechanism would simplify some other stuff, go right ahead, but I'd definitely like to see an nioctl, and similar routines anywhere that length isn't explicity passed.
Also, 2.0.x, at least, had some places where routines used the MM layer to calculate a true maximun length for a buffer. While accurate, this is a remarkable amount of work to go to because a length field wasn't available, and also broke for uClinux. Note that this was actually in the fs code, and not actual ioctls. sys_mount is one these, but you might be surprised at the others: every syscall that takes a filename.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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/
| |