Messages in this thread | | | Date | Fri, 22 Jan 1999 13:13:43 -0600 | From | Michael Elizabeth Chastain <> | Subject | Re: Adding checkpointing API to Linux kernel |
| |
Hi Kenneth,
> 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.
That is true for a simple ioctl_register. A complex complete ioctl_register has to handle variable-length blocks, blocks with secondary ioctl blocks like 'struct ifreq' ioctls. And then some ioctls take different parameters in different drivers.
> 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.
I wouldn't be surprised -- I had to dig through all these cases. sys_mount is just gratuitous lack of a length parameter. I handled the filename stuff by reading to the end of the string or until ptrace gave me errors back (end of target memory).
For my application I can get away with reading more than the actual changes. For some of the hairier ioctls like FDRAWCMD, I just fall all the way back to "snapshot the entire target memory space", which works for me.
I am curious, what is ucLinux's interest in this stuff?
Michael
- 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/
| |