Re: Please read if you use x86 -current

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Thu, 13 Nov 2008 17:58:31 +0100 (CET)
Havard Eidnes <he%NetBSD.org@localhost> wrote:

> > > I've pasted in the part of Andrew's instructions which should
> > > have been included as context in the above.
> > 
> > I'm not sure which part of Andrew's instructions you're including --
> > the business about build.sh needing modification was my text
> > (http://mail-index.netbsd.org/current-users/2008/11/12/msg005867.html).
> 
> The part I pasted in was:
> 
> > > > > > > > >       cd src/sys/modules
> > > > > > > > >       make
> > > > > > > > >       make install
> 
> and the tangent where I followed up started where you said this
> "can fail", it was replied with USETOOLS=no, and you asked the
> further question "And for folks who cross-compile?", where I
> answered "use the make wrapper for the cross compiler, then, and
> stop being so difficult :)".
> 
> 
> As I said earlier, I'm not opposed to modifying build.sh to have
> a "modules" keyword added, but that would typically only cover
> the "cd src/sys/modules; make" part of the above.  Should one
> have a separate "install-modules" keyword?
> 
That's certainly one approach.  The converse -- and this is part of a
different thread, I think -- is to always build and install all
modules, but control what is loaded.  One of the big open issues for
that is how tightly tied to a kernel version a module has to be.  If
they're tightly linked (i.e., because of references to data structures
that may change), I think that having 'build.sh install' handle
modules, too, is by far the right way.  If the coupling is looser --
say, if we had a really stable kernel ABI -- it's more debatable,
though I'd still lean in that direction.  The opposite extreme might be
creating modules.tgz as one of the sets that sysinst optionally
installs.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb