Design for 'Ioctl'
Michael Elizabeth Chastain
<mec@duracef.shout.net>
Sat 18 Nov 1995

Copyright 1995 Michael Chastain
Licensed under the Gnu Public License, Version 2



Ioctl calls are a pain in the butt.  Tracking their ever-evolving values
takes up way too much of my time.

I found 439 ioctls defined in Linux 1.3.42.  Each of them takes its own
argument type.  Some 'ioctl' calls encode the length of the argument
block.  It would be nice if *every* ioctl honored this length.  But
noooo ...

So I have data structures and code to track ioctl values.

'struct RiLine' is a data structure for one ioctl.  Each line contains
one ioctl number, one ioctl name, the input argument type (as a tySeg),
and the output argument type (again as a tySeg).  It's legal for the
same ioctl number to appear more than once in the table.

'RiLineLix.cc' describes all the known ioctl's in Linux.  It contains a
main table and a TIOCLINUX auxiliary table.

'RiLineLix.cc' is painfully revision-locked to the Linux kernel.  If you
have compiler errors, and just want to smash them, simply remove
offending lines from 'RiLineLix.cc' until they go away.

'FetchInIoctl' and 'FetchOutIoctl' fetch segments for ioctls. These
functions look up the ioctl request in the table and fetch the
appropriate segments.

If no matches are found, this is a model failure.  The target could be
invoking a non-existent ioctl, or it could be a good ioctl which I don't
know about.

If one or matches are found, segments from -all- the matches are
fetched.  This models correctly even for duplicate ioctls.

About 30 ioctls have auxiliary segments beyond their main segments.
'FetchInIoctl' and 'FetchOutIoctl' have custom code for these.  Lots of
these cases have never been executed.

'TIOCLINUX' is a special case, with about ten sub-cases.  Yet more
custom code.  It works, though.  Please, kernel hackers, don't add any
new TIOCLINUX cases, and please obsolete the old ones.

'SIOCDEVPRIVATE' and 'SIOCPROTOPRIVATE' ioctls are special.  I don't
model them yet, although I will in the future.  Right now, I simply
devolve to 'FetchAllArea', which fetches the entire address space of the
target!  That ought to cover almost anything!

One particularly nasty set of 'KD*' ioctl's is unreplayable because it
enables direct port access!  (This is why unknown ioctl's don't simply
call 'FetchAllArea', because the ioctl might be pulling this stunt.)
