On 09/14, Kirill Tkhai wrote: > > On 14.09.2014 21:27, Oleg Nesterov wrote: > > > > That said, I do not really understand 2/3. Not only I do not understand > > this kbuild magic, I am not sure I understand what /proc/built-in will > > actually show. > > It's a list of drivers, one driver per line: > > loop > ipv4 > ipv5 > ipv6 > ipv7 > ipv8 > etc ;) which drivers ? ;) OK, I blindly applied this series to my test kernel tree and the output is: $ cat /proc/built-in proc devpts ext3 jbd ramfs hugetlbfs debugfs crypto crypto_algapi pcieportdrv acpi acpica pnp pnpacpi 8250 input-core netfilter unix and where is, say, af_packet driver? I have CONFIG_PACKET=y. Or, where is my deadline_iosched/cfq_iosched modules compiled in? > > To me it would be better to change the "ifndef MODULE" version of > > module_init() to add KBUILD_MODNAME into __builtin_drivers_list[]. > > > > Yes, module_init() is overused. Say, why does kernel/kprobes.c use > > module_init() ? This looks confusing, this code can't be compiled as a > > module. And it seems that it has a lot more users which should have used > > __initcall() instead > > Yeh, the realization may be different. I do not insist on additional > section. The additional sction is fine, I think. I only meant that module_init() itself can be used to add a module name into that section. But of course I won't insist. And again, module_init() is abused by the non-modular kernel code. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
