[Toybox] Put syslogd and logger into the same file?
Rob Landley
rob at landley.net
Tue Aug 20 01:57:56 PDT 2013
On 08/18/2013 11:55:22 AM, Felix Janda wrote:
> Rob Landley wrote:
> > On 08/10/2013 04:22:58 PM, Felix Janda wrote:
> > > Right now syslogd.c contains code from <sys/syslog.h> declaring
> the
> > > arrays
> > > prioritynames and facilitynames, which map human readable strings
> to
> > > numerical ids. logger.c contains very similar array definitions.
> > >
> > > <sys/syslog.h> declares these arrays only when SYSLOG_NAMES has
> been
> > > #defined. The structure with the descriptive name "CODE" used for
> the
> > > array members is also only defined conditionally. Something like
> > >
> > > #ifndef SYSLOG_NAMES
> > > extern CODE prioritynames[];
> > > extern CODE facilitynames[];
> > > #endif
> > >
> > > is also missing in <sys/syslog.h>.
> > >
> > > IMO the least bad way to use the arrays from <sys/syslog.h> would
> be
> > > to
> > > combine syslogd.c and logger.c into one file and there define
> > > SYSLOG_NAMES before including toys.h.
> >
> > It's a good idea, but:
> >
> > What I haven't figured out yet is how to do the argument parsing.
> > syslogd and logger have very different option strings.
> >
> > Right now there's only one GLOBALS block per file. That's easy
> enough
> > to fix, and we can #undef TT and #define TT toys. But the FLAG_*
> macros
> > are also defined based on FOR_command. And that's harder to clean
> up...
>
> I was aware that there might be some problems with the build
> architecture
> but couldn't name them. Thanks for the clarification.
>
> I have no idea how to get two commands with overlapping conflicting
> options
> to work when put into the same file.
Neither do I, which is the problem. :)
In theory I could do a second #include to get different FLAG macros,
but it would have to #undefine all the current flag macros first, which
means I'd have to tell it which version I was switching _from_, so it'd
look something like:
#define FROM_command
#define FOR_command
#include "generated/switchflags.h"
As with the OPTSTR_name stuff for oldtoy, the complexity of the
infrastructure to implement this (and resulting large and ugly
generated/blah.h) makes the mechanism less attractive even if using in
commands can then be very simple. I don't like having the common
infrastructure be incomprehensible black magic even if it "just works"
when you use it.
Tradeoffs. Lots and lots of tradeoffs. I still might do it, but I have
to get comfortable with the idea of adding more crap to generated/*.h...
> So how about the following hack?
>
> Keep them in separate files. Have one common config symbol,
Which implies one common .c file because the top level config symbols
determine which toys/*/*.c files get fed to the gcc command line.
Ok, that's no longer ENTIRELY true. It used to be that the config
symbol CP would include cp.c but CP_MORE wouldn't becuase ther was an
underscore in it. Then I needed to support stuff like switch_root and
nbd-client which have underscores in their config symbols (- gets
squashed to _ and then everything is uppercased), so now what it does
is checks each config symbol to see if their _is_ a corresponding .c
file and assembles a gcc command line from the ones that match.
http://landley.net/hg/toybox/rev/654
So it'll work, but it's confusing. (I normally try to put common code
in lib, or not have it.)
> tear everything
> out of logger.c but logger_main, declare SYSLOG_NAMES in syslogd.c,
> put
> something like the current lookup() in logger.c to syslogd.c and make
> an
> extern declaration in logger.c. The new lookup() (better use a less
> generic
> name then) should accept an integer as its first argument instead of
> the
> table, say 0 stands for facilities and 1 for priorities.
I've read that twice and am not following it, which is not a good sign.
Alas, "how to be simple" is not, itself, always simple.
Could you poke me about this again next week? I want to try to clear
some of the other pending stuff of my plate. (Todo stack too deep.)
> Felix
Rob
1376989076.0
More information about the Toybox
mailing list