> 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/