[Gllug] Modules vs Static in Kernel

Stephen Harker steve at pauken.co.uk
Fri Jul 18 16:31:49 UTC 2003


On Friday 18 July 2003 14:53, Richard Jones wrote:
> On Fri, Jul 18, 2003 at 03:47:17PM +0100, Dylan wrote:
> > On Friday 18 July 2003 15:18, t.clarke wrote:
> > > Personally, I prefer to have the drivers that are in constant use
> > > linked statically into the Kernel.  OK, if I change the motherboard, I
> > > might have to recompile - but this is unlikely to be a frequent event;
> > > more likely the kernel will be upgraded before the motherboard !
> > >
> > > The other reason for preferring static drivers is that I got a bit fed
> > > up with gratutious messages being splattered onto the console every
> > > time the printer driver module was re-loaded (usually when printing
> > > something); since the module was being automatically removed after so
> > > many minutes of disuse !
> >
> > As a matter or further interest - If a module for a NIC gets unloaded,
> > how does the machine know to reload it when a remote connection is made?
>
> It doesn't. It would only get added when you bring up the interface
> (ifconfig eth0 up), and _might_ get removed when you bring down the
> interface (depending on whether you have a working kmod, which I
> don't).
>
> Drivers compiled into the kernel seem to be a bit happier for me on
> Debian. I've never really got Debian to bring up PCMCIA interfaces in
> particular on boot (except by explicit modprobe), and I think it's
> something to do with PCMCIA devices always being modules.

It's much easier on Debian (in my experience) to not require an initial RAM 
disk which means (on SCSI machines) compiling in at least the low-level 
driver for your SCSI card, the other scsi stuff and the filesystem for your / 
partition.

Can make for a largish kernel (about 1MB with some scsi, xfs and ext3 compiled 
in) but that doesn't really matter unless your trying to boot from a floppy.

SteveH

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list