> Brian,
>
> I have found in my work on a network appliance that NetBSD is already
> modular through the use of syspkgs, however, several modules I desire
> to put on networked appliances are way too big.

They seem to have extended the deadline.

> In CUWiNware, we use the combination of syspkgs and a "trim list" to 
> filter the NetBSD METALOG before doing an unprivileged "install" and 
> creating either an NFS root + kernel, a kernel w/ MD root, or an FFS or 
> ISO9660 image for CF or ISO9660, respectively.  syspkg helps us filter 
> the system with about the same granularity as you desire. In more recent 
> work, my colleague Bryan has introduced a new "crunched" build using 
> crunchgen(1).  Our goal is to fit a NetBSD router onto the Meraki Mini's 
> cramped flash (8MB - 1.5MB overhead = 6.5MB!).  [This is all open source 
> at <http://svn.cuwireless.net/svn/cuw/trunk/src/boot-image/>. I'm sorry 
> our server is so slow.]

This is very exciting as soon as I have free time I will have to explore 
your work and explore the possibility of integrating.  Thank you.

>
> We have found at CUWiN that even at the level of modularity you propose, 
> it is tremendously difficult to create a miniature NetBSD router. 
> Suppose we leave out these modules:

Right, because POSIX systems are not historically designed to be embedded.

>> tcpdump(8), GNU diff(1)/patch(1), ISC NTP, RAIDFrame (userland), LFS 
>> (userland), systrace (userland), ISDN4BSD, CGD (userland), CCD 
>> (userland), AltQ (userland), Racoon, LP Utilies, SUP, Kerberos 
>> (userland), NFS (userland), Quota Utilities (userland), AMD, OpenSSH, 
>> iSCSI/libiscsi (userland) libradius (pam),
>
> Already I am a little uneasy, having left out OpenSSH, ALTQ, and 
> TCPDump.

I'm not asserting that any particular combination is ideal for any 
particular appliance.  But certainly there is no harm in making these 
optional for ISVs.  Once again, the embedded/appliance environment's 
userland features will be implementation specific.

The optional build flag can also be useful for custom/pruned NetBSD 
installs on production servers.  For example, if you run portable OpenSSH 
or ISC named from Pkgsrc and don't want it to be overwritten after every 
upgrade....

> Note that by my omissions, I have ruled out such uses as embedded storage
> appliance or embeddd print server.  For a router, we simply cannot leave
> the following modules out---or, more abstractly, we cannot leave out
> the capabilities they provide:
>
>> libpcap, ISC DHCP, WPA Supplicant (userland), HostAP, PPP / SLIP / 
>> PPPOE, libevent, libprop
>
> At least three of these modules present a problem.  ISC DHCP is huge. 
> Last time I checked, wpa_supplicant and hostapd were inexplicably big, 
> too.  libpcap, which hostapd uses, is big, as well.
>

> So, I would like to suggest that the problem of breaking NetBSD into 
> modules for embedded systems is handily solved by syspkg + CUWiNware 
> build scripts,

Yes, which is the current approach.  Disable subsystems at build with 
existing mk.conf(5) flag, then manually prune from there.

I'm just suggesting more flags to help embedded developers make those 
solutions.  Consider what FreeBSD allows:

pxe(8), kerberos, wpa, bluetooth, CVS, C++, Fortrain, GPIB, ISDN4BSD, 
Ipfilter, PF, Audit Tools, Authpf, Inet6/IPv6, ATM, USB Utils, LPR and 
Friends, Netcat, NIS, OpenSSL, OpenSSH, sendmail, tcsh, crypt, games, GNU 
info(5), ISC Bind, PPP

v.s. NetBSD:

libbfd/libiberty, crypto (idea), cvs, gcc, ipfilter, gnu info(5), lint, 
nls, pf(4), pam, postfix, s/key, uucp, yp, kerberos, hesoid.

v.s. OpenBSD:

$SKIPDIR

> while the problem of the modules each being too big to
> combine usefully and "embed-ably" with others badly needs a solution.

Maintaining a prune list is extremely cumbersome.  For example, because it 
doesn't nessecarily ensure that non-pruned binaries aren't linked against 
pruned libraries.  It also compells the ISV to monitor the CVS commit logs 
for file system object additions.

Just some final thoughts, there seem to be three general types of embedded 
appliance setups:

1) Heavyweight:  High power CPU, multiple fans, one or two U server
    appliance, fixed disks, full feature OS, often vendor managed.
    OEM hardware like a Dell PowerEdge.  These are your Web Proxy,
    E-mail Spam Filtering, Application Delivery appliances.  Basially full
    OS install.

    Example: Google search, PineApp MailSecure,
                 http://bridgewerx.com/products/appliance.htm

2) Lightweight: Low power CPU, <=32mb RAM, stateless, CF booting, single
    or dual-function traditional network device.  Crunchgen binaries and
    and extreme lightweight file system.

    Example: Routers, Firewalls, APs, etc...
               WRT54 and early Soekris, Gumstix

3) Everything in between... Print Servers, Transparent Proxy Server,
    Environemtanl Sensors, SAN Fillers, Load Balancers, IDS Sensors.

You need just enough resources to make #2 impracticle but #1 means too 
great an investmentment in hardware ("Just run it off a poweredge" as my 
boss likes to say.  He's in love with Dell's web site)

~BAS

>
> Dave
>
> -- 
> David Young             OJC Technologies
> dyoung@ojctech.com      Urbana, IL * (217) 278-3933

l8*
 	-lava (Brian A. Seklecki - Pittsburgh, PA, USA)
 	       http://www.spiritual-machines.org/