Kernel size (Was: Include DaynaPort by default in GENERIC?)

[Julian Coleman <jdc%coris.org.uk@localhost>]

Hi,

[replying to several messages in one go]

I think that it makes sense to take some of these out of GENERIC, and just
picking some examples that make sense to me:

> options         SYSCTL_INCLUDE_DESCR    # Include sysctl descriptions in kernel
> <I never understood why we included the description strings in the first place>

> options         COMPAT_SUNOS    # SunOS 4.x binary compatibility
> <probably not very useful anymore, but still a nice curiorsity>

> options         NFSSERVER       # Network File System server
> <can NFSSERVER be loaded as a module?  If not, we should fix that!>

> ch*     at scsibus? target ? lun ?              # SCSI changer devices
> ss*     at scsibus? target ? lun ?              # SCSI scanners
> ses*    at scsibus? target ? lun ?              # SCSI SES/SAF-TE
> <probably not a lot of these devices hooked up to sparcs these days>

> ## SLIP and CSLIP interfaces, for IP over a serial line.
> pseudo-device   sl

Although, I'd keep this because I have RAID configured on a few of my sparcs:

> pseudo-device   raid
> options         RAID_AUTOCONFIG         # auto-configuration of RAID components
> <anyone running big RAID configs on their old Sun workstation?>

> Before:
> NetBSD 11.99.5 (GENERIC) #0: Mon Mar 23 20:54:04 PDT 2026
>    text    data     bss     dec     hex filename
> 5698534  158512  135720 5992766  5b713e netbsd
> 
> After:
> NetBSD 11.99.5 (GENERIC) #1: Mon Mar 23 21:14:46 PDT 2026
>    text    data     bss     dec     hex filename
> 4591378  144396  130624 4866398  4a415e netbsd
> 
> Could probably shave off a fair bit more.

We'd need to shave off more if we want to handle:

> I would offer the counter point that GENERIC is getting a little too
> big these days. It's already too big to boot on sun4c machines with
> the original memory config most of them shipped with. Having a unified
> kernel that boots on everything is nice on paper but on sun4 and sun4c
> the lack of RAM makes things painfully slow. I think it might be worth
> going back to the SunOS way of having a separate kernel for each
> karch.

I don't use GENERIC, but I compile separate kernels for each "karch", which
is exactly what you suggest here.  That can make a difference, for example:

     text    data     bss     dec     hex filename
  6261634  157912  137224 6556770  640c62 SUN4M_SCSI3.MP/netbsd

versus:

     text    data     bss     dec     hex filename
  5268518  147960  132480 5548958  54ab9e SUN4/netbsd
     text    data     bss     dec     hex filename
  3943341  134092  128720 4206153  402e49 SPARCBOOK/netbsd

However, depending on the options chosen, it might not make much difference:

     text    data     bss     dec     hex filename
  6197934  154992  135104 6488030  62ffde SUN4C_SCSI3/netbsd

I compile 10 kernels for a variety of machines.  I wonder if we really need
to add a lot of extra kernels, or if we could have a SMALL kernel?  If we
want to have support for just SUN4 and SUN4C, we could also reduce the size
further with things like:

  no options      SUN4M
  no options      SUN4D
  no cpuunit0     at mainbus0
  no cpuunit*     at mainbus0

and so on, i.e. removing anything that isn't present on SUN4 or SUN4C.

Regards,

Julian

PS.  Adding DaynaPort seems sensible :-)