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

From: Jeff Garzik (
Date: Fri Jul 04 2003 - 10:41:43 EST

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
> 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

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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:23 EST