makesyscalls

[David Holland <dholland-tech%netbsd.org@localhost>]

Between various forms of prompting I got tired of waiting for a gsoc
student to take up code generation for syscall argument handling. We
should really be generating all the calls to copyin/copyout, not to
mention all the compat32 and compat_* glue, not maintaining them by
hand. More on that later.

In the meantime the first step on this was to assess the current
makesyscalls.sh and decide whether to (a) leave it alone as a separate
mechanism, (b) integrate it into the new stuff, or (c) ignore it and
write new stuff from scratch.

My conclusion after wading into it is that between additions for rump,
dtrace, and other things it's become quite a bit too large for an awk
script. (Experience suggests that the limit is about 1000 lines,
depending on how well structured the script is and what it's doing.
Beyond this point, between there being no variable declarations,
function arguments being unchcked, and other properties of awk, it
becomes difficult to modify the script safely and alterations made
regardless tend to resort to cutpaste and make the situation worse.
This script is 1200 lines and it's definitely showing signs of
deterioration.)

This means that regarding (a) it shouldn't be left alone because it's
itself becoming a problem. Meanwhile, regarding (c), it does too many
things and has too many tentacles to be safely ignored or easily
reimplemented. Consequently, as a step towards (b) I have translated
it into Python; Python is still untyped but is substantially more
robust than awk and has a decidedly larger size limit.

The question is: do we want the Python version in the tree now, or
should I just treat it as an intermediate development prototype that
nobody has to see?

Arguments pro:
   - this is definitely a step forward for maintainability
   - having it in the tree means other people can work on it readily
   - having it in the tree means it's there even if my future plans
     get derailed or don't materialize

Arguments con:
   - it's Python and we don't have Python in base (and don't
     particularly want it)
   - Python being Python all the code paths I haven't managed to test
     by the time it's committed will probably crash the first time
     they're reached
   - definitely a risk of having introduced bugs (also found some, but
     so far all of them have been cosmetic things that awk doesn't
     trap on, like passing extra arguments to printf)

Arguments I'm not interested in listening to:
   - it's Python and Python is a terrible language (might be so but
     see below)
   - it should be Lua (don't see any reason Lua beats awk for this)
   - sh/awk is fine for this and you're doing it wrong (no I'm not, I
     think I have as much experience using sh and awk on nontrivial
     things as anyone)

There are not many languages to choose from: in base we have sh, awk,
lua, and C (or C++), and of languages not in base I think Python is
the only one sufficiently ubiquitous to justify using it for important
build infrastructure. Well, maybe Perl is, but I'm trying to make the
script _more_ maintainable :-)

Note before flaming that it doesn't actually run during builds, only
when someone regenerates the outputs after changing syscalls.master.
Needing to have Python installed for this is not a showstopper.

Rewriting in C is a possible future step. The code generator I have in
mind going forward should not be done in Python. But again, more on
that later.

-- 
David A. Holland
dholland%netbsd.org@localhost