[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200712311659.14847.mb@bu3sch.de>
Date: Mon, 31 Dec 2007 16:59:14 +0100
From: Michael Buesch <mb@...sch.de>
To: "Torsten Kaiser" <just.for.lkml@...glemail.com>
Cc: "Adrian Bunk" <bunk@...nel.org>, "Bodo Eggert" <7eggert@....de>,
"Jan Engelhardt" <jengelh@...putergmbh.de>, devzero@....de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote:
> On Dec 31, 2007 3:42 PM, Adrian Bunk <bunk@...nel.org> wrote:
> > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the
> > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes
> > of memory.
>
> One thing I always wondered about in this discussion about wasted
> EXPORT_SYMBOL's:
> Shouldn't it be possible to garbage collect these?
>
> depmod already contains code to analyze all modules to create a
> dependency tree. It should not be too difficult to extend it to create
> a list of all symbols that really are used by the current modules.
> Everything else could be stripped to save space.
>
> The problem with that:
> * out-of-tree modules would break if they don't get lucky to only use
> the remaining symbol. I would not see this as a problem, if the help
> text of the garbage-collect-option would contain a note like "don't
> enable this if you want out-of-tree modules".
> * if you later change your .config to include additional modules you
> might need to rebuild vmlinux and reboot into the new kernel.
> Currently you can probably build and load new modules without a
> reboot. (for example: usb drivers)
I'd say the practical advantage to the user would be almost zero.
Which distribution is going to enable this option and defacto
banning external modules?
--
Greetings Michael.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists