Messages in this thread | | | Date | Fri, 04 Jul 2003 11:41:43 -0400 | From | Jeff Garzik <> | Subject | Re: [PATCH] Add SELinux module to 2.5.74-bk1 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |