Subject: Re: Upcoming security model abstraction
To: None <elad@NetBSD.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
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:

files.bsd44
	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

files.overlay
	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().

YAMAMOTO Takashi