Messages in this thread | | | Subject | autoconf.h #defines different names for modules/non-modules | From | Ben Gertzfield <> | Date | 08 Sep 1998 13:08:37 -0700 |
| |
I've been working on a port of CMU's DFSTrace disk-event tracing software from their Mach kernel to the Linux kernel, and until this week I'd been extremely stumped why my #ifdef'd kernel changes weren't taking effect.
Basically, I've made a char device that's a circular buffer to be written to from within the kernel, so we can report open()s, close()s, fork()s, et cetera to the DFSTrace software for analysis. To do this, I added to drivers/char/Config.in:
tristate 'DFS Trace support' CONFIG_DFS_TRACE
in the CONFIG_UMISC section (it's the only one that looked appropriate).
Correspondingly, in drivers/char/Makefile:
ifeq ($(CONFIG_DFS_TRACE),y) LX_OBJS += dfs_trace_buffer.o else ifeq ($(CONFIG_DFS_TRACE),m) MX_OBJS += dfs_trace_buffer.o endif endif
This would make one think that for all cases, CONFIG_DFS_TRACE is definitely #defined -- but I just discovered that when the user chooses the module support for DFSTrace from make menuconfig, the following appears in include/linux/autoconf.h:
#undef CONFIG_DFS_TRACE #define CONFIG_DFS_TRACE_MODULE 1
Yipes. This certainly isn't apparent from the Makefile! Why has this been decided to be the proper behavior for tristates from make menuconfig?
In any case, I hope the proper way to #ifdef out code that needs to go into the kernel proper (i.e. not a driver) whether or not something is compiled in as a module is:
#ifdef CONFIG_DFS_TRACE || CONFIG_DFS_TRACE_MODULE ... #endif
but that looks awfully silly. Why is this necessary?
Ben
-- Brought to you by the letters K and B and the number 19. "More testicles means more iron." -- Lunchlady Doris, The Simpsons Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html
| |