Current-Users archive

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

Re: x86 GENERIC kernels unlobotomized



On Jan 2,  6:17am, "Martin S. Weber" wrote:
} On Fri, Aug 12, 2011 at 12:24:40AM -0700, John Nemeth wrote:
} >      netbsd-5 is NOT running on modules.  A netbsd-5 kernel is capable
} > of loading modules, but it doesn't have many of the improvements made
} > in -current.  By default the mod* tools on netbsd-5 work with LKMs, not
} > new style kmods.  To get them to work with kmods, you have to recompile
} > them with -DMKMODULAR.  Out of the box, I believe the only thing
} > netbsd-5 uses kmods for is the miniroot.kmod used by the installation
} > CD.
} 
} Interesting, especially as there's an options MODULAR in netbsd-5's
} GENERIC and there's a kmod for about every filesystem netbsd supports

     You'll note that there is also options LKM and that all
filesystems are included in GENERIC.  netbsd-5 is basically a
transition from LKM to kmod and has some support for both.

} lying around in my /stand/i386/5.0 ... Why install something that won't
} be used? But ok, I guess the modular vs. monolithic debate cared for some

     It may be possible that if you remove filesystems from your
kernel, that they would get autoloaded.  I don't recall if filesystem
autoloading is in netbsd-5 or not.

} hasted commits and less holistic design than usual for NetBSD. I just hope
} the steam cools off somewhen (maybe 2012?) and the devel community of
} NetBSD will return to its 'good design first' goal, rounding off whatever
} is delivered to the end-user...

     kmods are a major improvement on LKMs.  kmods as they sit, work.
The issue seems to be around usability.  There also seems to be some
contention around a design point.  kmods were designed to work with all
kernels of a particular version.  Some people want them to be
associated with a particular kernel instead.  This is more of a
subjective preference then a design issue.  Either way can work and
function just fine for many purposes.

}-- End of excerpt from "Martin S. Weber"


Home | Main Index | Thread Index | Old Index