Subject: Re: Google SoC 2007 Project: Subsystem Conditional Building (resend)
To: David Young <firstname.lastname@example.org>
From: Brian A. Seklecki <email@example.com>
Date: 03/20/2007 23:27:15
> 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
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
> 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
libbfd/libiberty, crypto (idea), cvs, gcc, ipfilter, gnu info(5), lint,
nls, pf(4), pam, postfix, s/key, uucp, yp, kerberos, hesoid.
> 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
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
Example: Google search, PineApp MailSecure,
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)
> David Young OJC Technologies
> firstname.lastname@example.org Urbana, IL * (217) 278-3933
-lava (Brian A. Seklecki - Pittsburgh, PA, USA)