Wookey [mailto:[EMAIL PROTECTED] wrote:
>
> On Wed 16 Aug, Jason Gunthorpe wrote:
> >
> > On Tue, 15 Aug 2000, Joey Hess wrote:
> >
> > > It's been pointed out that emdebian (http://www.emdebian.org/) is
> > > essentilly an effort to do just this. [shrink debian to fit
> > > handhelds]
> >
> > It is? I use their stuff and the main focus is cross compilers and cross
> > environments for debian, not really shrinking and porting debian proper.
> >
> > That it is, it is more tools for embedded development rather than an
> > embedded operating system.
>
> We (emdebian) want to do both these things. The latter is what is urgent
> right now for developers of 'funky handhelds', but the former is also
> needed for those handhelds to be of much use beyond specific vertical
> applications. http://www.handhelds.org/ (the compaq research lab, who did
> the port to the ipaq) is encouraging development of small-platform linux
> software. Emdebian intends to use the resulting good stuff to produce a
> proper small-device distro.
>
> The needs of genuinely embedded devices and general-purpose handheld
> computers are not quite the same, but the restrictions are similar so we
> hope that a distro can be produced that covers both these areas. It's an
> interesting area.
Emdebian *has* been focussed on cross tools so far, but that's about to
change.
Right now, I'm working on the 'shrinking Debian' problem, and I think I've
come up with an interesting solution. I'll be making an initial release
within the next week or so, but until then I'll give you a short rundown.
The problem can be split into two subproblems:
1. Specification of the system (i.e. binaries, libs, utilities
to include, network configuration, username/password configuration,
etc...)
2. Generation of the system.
1. Specification
----------------
The kernel has a specification (configuration) tool. Why not use the same
tool to specify the operating system? One advantage of this approach is
that you can build an operating system tightly coupled to the kernel.
For example, if you've built a kernel without modules support, then you
shouldn't offer the user the chance to include module utilities in the
operating system that goes with it. If you haven't enabled SCSI, then
why should you have /dev/sd* etc. on your filesystem. Etc, Etc.
The following screenshots are a prototype of what I mean. I'm basing the
work I'm doing on CML2, Eric Raymond's next generation kernel configuration
system (see http://www.tuxedo.org/~esr/kbuild). Please keep in mind that
the following menus have been slapped together with very little thought
in order to build a prototype:
===============================================================================
> Network Configuration (netcfg)<
User Configuration (usrcfg)
Editors (editors)
Shells (shells)
BSD Utilities (bsdutils)
Debian Utilities (debianutils)
Diff Utilities (diff)
EXT2 Filesystem Programs (e2fsprogs)
Floppy Disk Utilities (fdutils)
File Utilities (fileutils)
Find Utilities (findutils)
Grep (grep)
GNU Zip Utilities (gzip)
Login Utilities (login)
Kernel Module Utilities (module)
Mount Utilities (mount)
Network Utilities (netbase)
Password Utilities (passwd)
/proc Utilities (procps)
Shell Utilities (shellutils)
Debugging Utilities (sysdebug)
System V Init (sysvinit)
TCP Wrappers (tcpd)
===============================================================================
===============================================================================
Network Configuration
>192.168. Host IP Address (OS_HOST_IP)<
emdebian Host Name (OS_HOST_NAME)
255.255. Netmask (e.g. 255.255.255.0) (OS_NETMASK)
nowhere. Host Network (OS_NETWORK)
192.168. Gateway IP Address (OS_GATEWAY_IP)
192.168. DNS Server 1 (OS_DNS_1)
0 DNS Server 2 (OS_DNS_2)
0 DNS Server 3 (OS_DNS_3)
===============================================================================
===============================================================================
User Configuration
[*] Use Shadow Passwords (OS_SHADOW_PASSWD)
Root Root Password (OS_ROOT_PASSWD)
[*] User 1 (OS_USR1)
guest User 1 Name (OS_USR1_NAME)
Guest User 1 Password (OS_USR1_PASSWD)
1000 User 1 User ID (OS_USR1_UID)
1000 User 1 Group ID (OS_USR1_GID)
>[ ] User 2 (OS_USR2)<
===============================================================================
===============================================================================
Editors
>[ ] ae: Tiny full-screen text editor (OS_AE)<
[ ] elvis-tiny: Tiny vi-compatible editor (OS_ELVISTINY)
===============================================================================
===============================================================================
Shells
>[ ] ash: Command interpreter (shell) (OS_ASH)<
[ ] bash: GNU Bourne-Again SHell (OS_BASH)
===============================================================================
===============================================================================
File Utilities
>[ ] chgrp: Change group ownership (OS_CHGRP)<
[ ] chmod: Change file access permissions (OS_CHMOD)
[ ] chown: Change file owner and group (OS_CHOWN)
[ ] cp: Copy files and directories (OS_CP)
[ ] dd: Convert and copy a file (OS_DD)
[ ] df: Report filesystem disk space usage (OS_DF)
[ ] dir: List directory contents (OS_DIR)
[ ] dircolors: Color setup for ls (OS_DIRCOLORS)
[ ] du: Estimate file space usage (OS_DU)
[ ] install: Copy files and set attributes (OS_INSTALL)
[ ] ln: Make links between files (OS_LN)
[ ] ls: List directory contents (OS_LS)
[ ] mkdir: Make directories (OS_MKDIR)
[ ] mkfifo: Make FIFOs (named pipes) (OS_MKFIFO)
[ ] mknod: Make block or character special files (OS_MKNOD)
[ ] mv: Move (rename) files (OS_MV)
[ ] rm: Remove files or directories (OS_RM)
[ ] rmdir: Remove empty directories (OS_RMDIR)
[ ] shred: Delete a file securely, first overwriting it to hid(OS_SHRED)
[ ] sync: Flush filesystem buffers (OS_SYNC)
[ ] touch: Change file timestamps (OS_TOUCH)
[ ] vdir: List directory contents (OS_VDIR)
===============================================================================
2. Generation
-------------
I can imagine many different ways of building the operating system image.
The one I'll be working on initially is a "Snarf 'n' Pick" implementation.
Basically it will work by snarfing Debian packages and picking subsets of
files from the packages. To my understanding, boot-floppies works in a
similar way to create rescue disks.
Thoughts?
-Frank.
---
Frank Smith, MCompSci
Principal Software Designer [EMAIL PROTECTED]
AMIRIX Systems Inc. http://www.amirix.com/
Embedded Debian Project http://www.emdebian.org/
77 Chain Lake Drive 902-450-1700 x289 (Phone)
Halifax, N.S. B3S 1E1 902-450-1704 (FAX)
