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 dholl...@netbsd.org