[BusyBox] Could proc be a kernel module?

[bug1]

Pavel Roskin wrote:
> 
> Hello, Erik!
> 
> > It could be done.  As you say though it will take a fair bit of work.  Also, to
> > maximize the effect, there is a lot of procfs support code in the kernel as
> > well, so it might be a nice idea to identify all those dependancies and move as
> > many as possible into the procfs code.  For example, in fs/super.c there is
> > get_filesystem_info() and get_filesystem_list() that are used _only_ be procfs,
> > and yet that are unconditionally compiled right into the filesystem code.
> > Modularizing/moving that type of code could greatly increase the benefits of
> > the modularization.
> 
> It is not so simple. If you make procfs a module you have an interesting
> situation.
> 
> Suppose, you compile procfs and foofs (which is a filesystem for hard
> drives) as modules. When both modules are in memory you want foofs to
> announce some information by the means of procfs. You need some code for
> that.
> 
> Now, you don't want that code to be in memory when only one of those
> modules (procfs or foofs) is in memory. The question is - where should
> that code be. The only decent answer - in a separate module that depends
> both on procfs and foofs. But implementing such "glue" modules doesn't
> seem to be worth the trouble in most cases.
> 
> Moving code from one place to another doesn't solve the problem. The more
> stuff you drag into procfs, the more is the overhead for the vast majority
> of people using procfs.
> 

e.g. function proc_foofs() that is used only by proc when foofs is
loaded

The code for proc_foofs() should be in a seperate module that is only
loaded when both procfs and foofs are loaded.

If it gets loaded with either the procfs or foofs module then it is an 
unwelcome overhead unless both modules are loaded.

> Eliminating the unused code should ideally be done by the linker, not by
> ifdef's. Busybox would be a nice testbed for the features that are already
> in the GNU ld. Having tried that, we could do the same to the kernel.
> 
> For now, let's stick with ifdef's in the kernel. And please, don't move
> the code from one place to another without serious reasons.
> 

What is the problem with using "glue" modules, wouldnt they be a better
solution than either ifdef or better linking.

Glenn