Date: Wed, 7 Oct 1998 09:58:38 -1000 From: dan bigelow <danno@mindsong.com> To: "'freebsd-small@FreeBSD.ORG'" <freebsd-small@FreeBSD.ORG> Subject: what constitutes 'stripped' (basic needs)? was Re: new micro drives... Message-ID: <01BDF1D9.0F1D0800@m142.mindsong.com>
next in thread | raw e-mail | index | archive | help
given the following edited stuff... >> ...I think that it is >> important to focus on what the embedded world needs, and make sure we >> can STRIP it to fit on a floppy, but not that we obsess over making >> sure it fits in all forms. > > Thats just what I was trying to say about size & embedded >systems... > >Peter Wallace How about a quick baseline... what constitutes the 'stripped' - basic machine? As a framework to work from, let's assume the function of the 'basic' machine (either in the building stage or initial run stage), is to boot, run, and be able to start included programs, or add/start kits at will. I think this has to be distinguished from any other function of the box (routing, file-server, web-server, ???) to be a useful discussion... e.g. before the box is useful, when is it 'alive' and what does it take to get to that point...and beyond! So - naturally we need a kernel and basic file system (ramdisk or flash or floppy or...). To be minimal, the kernel, modules/drivers for the chosen hardware and filesystem need to be selectable and available quite early (true minimums). At the build stage, only the desired stuff can be added. Not very generic, but nice and small! Next, add the tools to get the system resources (mount, a shell(?), inits, updates, crons, etc.) up, and the actual system resources (init, crond...)... here's where the idea of minimum get's interesting and relative... What shells and start-ups are really the minimums before we go 'useful'? Next, the archiving, compression, and related kit management tools (tar, cpio, gunzip, etc) to extract the desired kits from the chosen fs or tftp (if they've been separated...) - net stuff may go here in some configs, later if possible... Process control utils (basically ps and kill to start with), maybe the /proc fs Then, shell utils for file handling (mknod, chmod, chown, ls, rm, mv, cp, ln, ...) can be built into a single busybox... - (charles, remember 'PIP' ? peripheral interchange program on the rsx-11s?) Then, the system monitor/control programs (ps, df, du, top...) Then phase 2 function adding? network tools (ifconfig, netstat, route, ppp, diald, etc.), hardware drivers to work the interfaces The good stuff - server daemons, data, mail, remote access (telnetd sshd), small editors, backup utils to save system states... Then the luxuries - vi, emacs(so much for flash disk ;^), perl, shells, file utils (head, od, tail, ?), docs, ??? Comments? things out of order? missed things? To define these layers may actually help enhance the build and install process of these systems by grouping the design decisions coherently at each layer - birth then life then communication then interaction then learning then function then stability... i dunno - but i'd like to. --danno (hormel@mindsong.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01BDF1D9.0F1D0800>