Re: what's the rationale behind kbuild "depends on m"?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 25 Mar 2007, Randy Dunlap wrote:

> On Sun, 25 Mar 2007 08:40:49 -0400 (EDT) Robert P. J. Day wrote:
>
> >
> >   i'd never noticed this before, but a small number of Kconfig files
> > have some variation of "depends on m":
> >
> > $ grep "depends on m" $(find . -name Kconfig)
> > ...
> > ./drivers/scsi/pcmcia/Kconfig:  depends on m && !64BIT
> > ./drivers/scsi/pcmcia/Kconfig:  depends on m
> > ./drivers/scsi/pcmcia/Kconfig:  depends on m && !64BIT
> > ./drivers/scsi/pcmcia/Kconfig:  depends on m
> > ./drivers/scsi/pcmcia/Kconfig:  depends on m
> > ./drivers/isdn/hysdn/Kconfig:   depends on m && PROC_FS && PCI && BROKEN_ON_SMP
> > ./crypto/Kconfig:       depends on m
> >
> >   what's the rationale here?  one consequence of this is that, even
> > when you "make allyesconfig", these features will be built as modules.
> > that is, here's the tail end of the build output after "make
> > allyesconfig":
> >
> >   CC      crypto/tcrypt.mod.o
> >   LD [M]  crypto/tcrypt.ko
> >   CC      drivers/i2c/busses/i2c-stub.mod.o
> >   LD [M]  drivers/i2c/busses/i2c-stub.ko
> >   CC      drivers/isdn/hardware/eicon/diva_mnt.mod.o
> >   LD [M]  drivers/isdn/hardware/eicon/diva_mnt.ko
> >   CC      drivers/net/wan/cosa.mod.o
> >   LD [M]  drivers/net/wan/cosa.ko
> >   CC      drivers/net/wan/dscc4.mod.o
> >   LD [M]  drivers/net/wan/dscc4.ko
> >   CC      drivers/net/wan/hostess_sv11.mod.o
> >   LD [M]  drivers/net/wan/hostess_sv11.ko
> >   CC      drivers/net/wan/sealevel.mod.o
> >   LD [M]  drivers/net/wan/sealevel.ko
> >   CC      drivers/net/wan/z85230.mod.o
> >   LD [M]  drivers/net/wan/z85230.ko
> >   CC      drivers/scsi/pcmcia/aha152x_cs.mod.o
> >   LD [M]  drivers/scsi/pcmcia/aha152x_cs.ko
> >   CC      drivers/scsi/pcmcia/fdomain_cs.mod.o
> >   LD [M]  drivers/scsi/pcmcia/fdomain_cs.ko
> >   CC      drivers/scsi/pcmcia/nsp_cs.mod.o
> >   LD [M]  drivers/scsi/pcmcia/nsp_cs.ko
> >   CC      drivers/scsi/pcmcia/qlogic_cs.mod.o
> >   LD [M]  drivers/scsi/pcmcia/qlogic_cs.ko
> >   CC      drivers/scsi/pcmcia/sym53c500_cs.mod.o
> >   LD [M]  drivers/scsi/pcmcia/sym53c500_cs.ko
> >   CC      sound/oss/msnd.mod.o
> >   LD [M]  sound/oss/msnd.ko
> >   CC      sound/oss/msnd_classic.mod.o
> >   LD [M]  sound/oss/msnd_classic.ko
> >   CC      sound/oss/msnd_pinnacle.mod.o
> >   LD [M]  sound/oss/msnd_pinnacle.ko
> >
> >   what's so special about those features that they're built as
> > modules even with "make allyesconfig"?  just curious.
>
> This is all fairly old stuff.  I think that someone decided long ago
> that using these drivers only made sense as loadable modules. This
> was probably before hotplug was working, and much much before udev
> was born.  So before hotplug worked, this was a reasonable thing to
> do.
>
> (Well, the crypto module isn't old, but it's just a testing
> module, so why build it into the kernel binary file?)

oh, it's fairly clear that *some* of that stuff makes sense only as
modules (such as that crypto module).  and there's certainly no point
wasting any cleanup time on anything OSS-related.

but the rest of it certainly deserves a closer look -- i posted to
LKML on the weirdness behind the PCMCIA stuff.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux