In article <199604091557.RAA00617@arresum.inka.de>,
Bernd Ernesti  <netbsd@arresum.inka.de> wrote in current-users:
> 
> No, your are wrong. Take a look in src/sys/conf/files:
> 
> Line 199-201:
> 
> file net/bsd-comp.c                     ppp_bsdcomp
> file net/ppp-deflate.c                  ppp_deflate
> file net/zlib.c                         ppp_deflate
> 
> You see that this three files are only included if you use this two options
> in your kernel-config.

I was just thinking, zlib.c is really quite separate from the ppp deflate
support, and could quite conceivably be used by other things in the
kernel (a "zd" compressed disk driver, or a compressed vfs layer, or for
unpacking a compressed compiled-in rootfs ramdisk image for installs,
etc.). It really doesn't belong in /sys/net, and it's inclusion should
be controlled something more generic so that more than one facility can
specify it.

I'd submit a PR, but I'm not really sure what The Right Thing is here. 
Maybe we need a generic software component directory in the kernel
source, sort of a parallel to what /sys/dev is for device drivers. 
Other things that might go there (if and when needed by something, of
course) would be MD5 hash code, DES encryption code, etc.  IE, things
that implement specific services to be used by other kernel features,
but which don't fit readily into an existing category (system call,
driver, filesystem, etc), and which aren't tied to any one kernel
feature. 

I've some ideas for a directory name (/sys/gen or /sys/generic,
/sys/{misc,component,module,feature,util,code,stuff,...}),
but I don't really like any of them.

I realize this is just one little thing right now, but it seems likely
that there will be more and more of these kinds of things as time goes
on.  Networking protocols are getting fancier and starting to include
compression and encryption, users are starting to excpect features like
compressed filesystems and so on, and hardware devices are getting
smarter and specking more complicated protocols, and may soon start to
use compression, encryption, etc.  So I think we should start to think
about where these kinds of generic capabilities (compression,
encryption, CRC or MD5 checksumming, etc) belong in the kernel source
tree, and how they should be organized. 

Comments?