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