On Sat, Jun 09, 2001 at 02:13:06AM -0500, Brian Chase wrote:
> Bahhhh... You're seeing the world through PeeCee tinted eyes.  You must
> remember that one of NetBSD's major focal points is its portability.  And
> given this, that means it runs on quite a few more systems than just Intel
> PCs with lots-o-memory -- or the 8Meg PC freebies you're taking jabs at
> here.  Most of the older machines which are supported tend to have very
> modest amounts of both memory and CPU cycles.  This includes systems such
> as the MicroVAX-II on which a memory config of 8Megs or less is fairly
> common.  I myself have a number of VAX systems with as little as 4-6Megs.

Why don't you use 1.4.X or 1.5.X? They are much lesser feature-rich
compared to -current and even smaller in sizes. Why weren't you 
against UBC when it was committed for the first time? There are a
number of features that will make the kernel even bigger by _default_
to be committed in the near future, such as new pipe, kqueue, etc.

> > Why should we have anything in the kernel at all? Micro-kernels have
> > proved to be pretty useless in reality, so why not strive in that
> > direction?
> 
> I don't know... Linux has sort of strived in the opposite direction.
> Do you really want the NetBSD kernel to become what the Linux kernel has
> evolved into?

Has Linux evolved in a wrong way? I don't think so. It has a number  
of features and advantages NetBSD doesn't yet (no, I don't want to
start an OS holy war here).

> I've no problems with these sorts of additions to the kernel as long as
> they're made optional through the kernel configuration file.  But, it is
> actually important to keep in mind that NetBSD isn't just an OS for modern
> desktop systems and servers.  It also supports a wide variety of older
> systems as well as more conservatively equipped contemporary embedded
> system platforms.

I'm surprised at so many objections to addition of such a little
feature to the kernel which I think good to have.

Anyway, in order to satisfy more people it should be:

 * configurable at compile time via 
   options WSCONS_SCROLLBACK
 * able to be disabled with sysctl(8) or wsconsctl(8) once it's
   compiled into the kernel.
 * machine-independent, hopefully 

Jun-Young

-- 
Bang Jun-Young <bjy@mogua.org>