Messages in this thread | | | Date | Fri, 22 Jan 1999 15:14:19 -0500 (EST) | From | Kenneth Albanowski <> | Subject | Re: Adding checkpointing API to Linux kernel |
| |
On Fri, 22 Jan 1999, Michael Elizabeth Chastain wrote:
> 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.
Indeed. My experience is that mechanisms which attempt to "describe" stuff falls prey to complexity (and tend to invoke the halting problem if you take them too far). An nioctl call with a length would be several orders of magnitude less complex. (Quite literally.)
> > 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).
Which amounts to the same thing, save that in the kernel you can query for end-of-target-memory in a somewhat efficient manner.
> 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?
Mainly: how to implement UNIX style syscalls without memory protection. uClinux currently doesn't have any mechanism for efficiently finding what memory a user process owns (this is partially a simple implementation issue, and partially the lack of an MMU).
Actually, I'm interested in the entire aspect of checkpointing, ptrace, etc., for uClinux and in general. uClinux adds a few interesting twists, among them: binaries are executed directly from ROM whenever possible, and ptrace needs some additional concepts to indicate the base address space of a process. The first means ld.so style fixups are not an option, and the second means any debugger will need a bit of tweaking. (On that note, I wanted to set gdb up for this, but was sorely disappointed at the quality of its ptrace-based remote server.)
-- 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/
| |