Re: kern/41668: MONOLITHIC should probably also be included in HEAD builds

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR kern/41668; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/41668: MONOLITHIC should probably also be included in HEAD
 builds
Date: Fri, 17 Jul 2009 07:54:40 -0400

 On Thu, 16 Jul 2009 12:04:39 +0000
 ad%NetBSD.org@localhost wrote:
 
 > The monolithic kernel an aid for people developing core kernel code,
 > compiling their own kernels, and generally playing about in areas where one
 > can shoot oneself in the foot rather easily.  I have never had the need for
 > it but I can see the utility.
 > 
 > When considered in the frame of a NetBSD release it offers nothing. 
 > Releases are all about a shipped product for end users ... unless the
 > landscape has changed so dramatically that releases are all about us
 > hackers and our toys, which would be a desperately sad state of affairs.
 
 Unfortunately, our notion of what toys might and might not be seems to
 differ significantly :)
 
 Personally, using a dedicated build host, it doesn't matter much if a
 MONOLITHIC binary kenel isn't provided, although I sure hope that the
 configuration file will be maintained (your answer raises doubts
 about this, describing it as a "toy" you never used).  I admire your
 work on the modular system which will probably prove useful to many use
 cases, but I don't agree that the most straightforward approach to a
 working system should suddenly be delegated to the level of a luxury
 developer toy.
 
 However, when I filed the PR I was thinking of end users who I
 occasionally meet on IRC, needing to try a -current kernel and finding
 it non-trivial.  Of course, in an ideal world, they wouldn't have to,
 but it does happen.
 
 They end up either having to mess with GENERIC and modules from a daily
 build or having to read tracking-current documentation and build their
 own kernel from source (also realizing that they need MONOLITHIC and
 not GENERIC for the documented procedure to work properly), when they
 could simply download a single kernel image to test.  Even for
 developers, an end user being able to confirm if a kernel problem
 subsists or not on HEAD is useful.
 
 Thanks,
 -- 
 Matt