Ben --- I'd very much like a change to this patch. Introducing the 'cmd' member of cmd_parms constitutes a change to the API; I really think these should be discussed on the list before being committed. This one, in any case, is unnecessary. The cmd_data of the callback structure already exists precisely to allow a command handler to behave differently depending on which command table entry caused it to be invoked; if the relevant command table entries looked like
{ "RLimitCPU", no_set_limit, "RLimitCPU", ... }, { "RLimitNPROC", no_set_limit, "RLimitNPROC", ... }, the name under which no_set_limit was invoked would be in cmd->info. As long as I'm looking the code more over with a tighter eye than formally (sigh...), I just noticed the use of RAW_ARGS; this is something we may want to change before final release --- the problem with it is that while TAKE1, TAKE2, and the like provide some sort of guidance to an external agent which is trying to parse the config file (perhaps through a mod_info-style intermediary), RAW_ARGS is essentially useless. I understand that you aren't personally responsible for this, but still, in the long run, we ought to change it. (I've been thinking that maybe adding a TAKE2OPT-style command-handling directive, which would be like TAKE2 except that it allowed the args to be missing, would be a good idea). One last gripe --- the command handlers seem to be logging errors in cases where they really ought to be returning a syntax error string --- i.e., in cases where the args are just syntactically invalid. This really ought to change... rst