Messages in this thread | | | Date | Sun, 14 Sep 2014 22:00:07 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 0/3] Implement /proc/built-in file similar to /proc/modules |
| |
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.
| |