Re: [PATCH] Add SELinux module to 2.5.74-bk1

[Jeff Garzik <jgarzik@pobox.com>]

Stephen Smalley wrote:
> On Thu, 2003-07-03 at 13:51, Jeff Garzik wrote:
>>2) stick includes in the standard include/ directory.  I would suggest
>>include/security (if the headers are general) or
>>include/security/selinux.
> 
> 
> Even if the headers are private to the SELinux "module"?  No other
> kernel code uses them.  


It's a tough call, so I won't shed a tear if I'm ignored here :)

It's mainly a matter of number of headers, to me.  If the module gets so 
huge that the number of headers is climbing towards ten or so, and 
doesn't look to stop anytime soon, I tend to feel include/ is more 
appropriate.

Example:  drivers/acpi/include became include/acpi.  A few of the 
headers are used publicly, but most are private to the ACPI driver.

Adding -I to certain directories or files is easily doable, but it tends 
to break in subtle ways on occasion.  The makefiles are already set up 
to include $topdir/include, so one only needs to carve our your own 
namespace in include/.  Anyone doing something weird like building when 
objdir != srcdir or similar uncommon cases won't have to worry about 
your Makefile being a special case.

Example:  SCSI low-level driver headers were until recently 
drivers/scsi/{hosts,scsi}.h.  This is awful for out-of-tree drivers, and 
for in-tree drivers not in drivers/scsi.  There were all manner of 
"-I../../../blah" type stuff in Makefiles, which often break in uncommon 
situations.  If there are ever SELinux sub-modules that live out-of-tree 
for a while, you'll be glad the headers are in include/... things will 
Just Work(tm).

	Jeff