lkml.org 
[lkml]   [1999]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.029 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site