Subject: Re: Upcoming security model abstraction
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 09/05/2006 23:12:18
> > of course, my "overlay" won't pick up the file.
> I think you are looking at the current (only) implementation of a
> security model, bsd44, and base this statement on it alone. Once
> we introduce (if any, again) somewhat more.. "complicated" security
> models, this won't be possible without dividing the new model to
> more files.
> I think that in the longer term, the way we're doing it now will
> prove cleaner.
what's wrong with "dividing the new model"?
(i think i'm not sure what's your goal wrt "overlay".)
your overlay method seems to need cooperation between models anyway.
eg. "bsd44" needs to know what's needed by "overlay", and "overlay"
needs to know internal details of "bsd44".
> >> __CONCAT() actually simplifies things by calling the "real"
> >> model used.
> > i know what it does. i'd like to call it complicate.
> > maybe it's a matter of taste... i don't like inventing this unusual trick
> > while it can be perfectly done with existing config facilities and normal C.
> Maybe.. we'll need to use config facilities anyway for the model
> dependencies anyway and I'm not yet sure how to do that. :/
i'd suggest something like the following:
defflag secmodel_bsd44 : secmodel_bsd44_logic
file secmodel/bsd44/secmodel_bsd44.c secmodel_bsd44
file secmodel/bsd44/secmodel_bsd44_foo.c secmodel_bsd44_logic
file secmodel/bsd44/secmodel_bsd44_bar.c secmodel_bsd44_logic
defflag secmodel_overlay : secmodel_bsd44_logic
file secmodel/overlay/secmodel_overlay.c secmodel_overlay
secmodel_bsd44.c only contains "bsd44" version of secmodel_start().
secmodel_overlay.c contains "overlay" version of secmodel_start().