Hi Laurent !
> Out of curiosity: what are, to you, the benefits of this approach ?
What are the benefits of preferences? ... good question!? ;)
Does it actually save you noticeable amounts of RAM ?
May be a few bytes ... noticeable? what is your level to noticeable
here? ... otherwise I would say *NO*
of disk space ?
Which disk space? ... which disk? ... looking around ... not seeing a
"disk" (in your sense) ... shot: complete system from initramfs ... disk
in this sense is some external USB data storage (only data, never used
for system purposes).
Is it about maintenance - just copy one binary file from a system to
another ?
Hit!
(But you'd also have to copy all your scripts...)
Second file, a tar, but all architecture independent,
third file, a tar, with pre-configured setups.
Is it about something else ?
Yes, the most important! ... It's my way, the way I did it for several
commercial projects ... and the way I like to do it ... clarity /
simplicity / puristic ... preference! :)
If it's just for the hacking value, I can totally respect that, but it's
not an argument you can use to justify architectural modifications to a
Unix tool other people are using, because it kinda goes against the Unix
philosophy: one job, one tool. Busybox gets away with it ...
Better to call Busybox a tool set, it is several commands and a library
linked together to share some code size. Beside the invoking logic of
the applets (multicall) the applets has to be considered separate
commands ... though some commands tend to forget that.
I won't try to hide fixed system functionality in a binary (better say
program or command here), except for fall back operation (e.g. last
resort handling). My usual approach is to spawn a script when it's time
to handle system depended things (or need to be under admin control).
... but I like to describe in configuration what to do, not how to do
(as it's done in scripts). So I like to have simple lists, describing my
system, let a one-shot command parse that list, and call the required
programs / commands / scripts with the configured information from the
lists, to do the job.
e.g.
# required virtual file systems
/proc root:root 0755 %proc
/sys root:root 0755 %sysfs
/dev root:root 0755 %tmpfs size=64k
/dev/pts root:root 0755 %devpts
(describes my system setup - selected part - without describing how to
go there)
... and yes that could be done with shell scripting ... the way I'm
doing it since years ... but still things tend to be scattered around,
so i liked to add setting up the virtual file systems (excluding /tmp,
which I setup in fstab) and preparing the device file system (including
the device descriptions) in one central place (that was mdev.conf).
Currently I put those lines in comments and filter them out into a shell
script, but this is sometimes confusing.
(and I believe that inclusion of supervisors and super-servers is already
too much).
ACK ... but what do you think about e.g. tcpsvd (accepting incoming tcp
connections), or netlink reader?
My fifo watcher does comparable job as tcpsvd (brings me to the idea to
create it as fifod applet in BB with appropriate options). We could use
TCP connections, but system cost for fifo's named pipe should be below
the cost of running through network stack.
Even on a noMMU system, I think what you'd gain from having one single
userspace binary (instead of multiple small binaries, as I do on my
systems) is negligible when you're running a Linux kernel in the first
place, which needs at least several megabytes even when optimized to
the fullest.
Linux kernel including cpio to setup initramfs is around 6 to 8 MByte on
modern kernel versions (complete system kernel + system tools +
application scripts) ... running on a system with 64 MByte or even 16 to
20 MB. No disks at all. Boot from CD-ROM drive, then turn it of. ... but
nowadays more likely boot from USB stick :) ... 256 MByte stick :) ...
vintage ... 32 MB Boot partition, boot loader files + boot images +
System Config, rest of stick is data storage.
I know a guy who manages to run almost-POSIX systems in crazy tiny
amounts
of RAM - think 256kB, and the TCP/IP stack takes about 40 kB - but that's a
whole other world, with microcontrollers, JTAG, a specific OS in asm, and
ninja optimization techniques at the expense of maintainability and
practicalness.
Full duplex serial bridging between an PLC bus system and special
synchronous clocked bus system for hazardous areas with a bit rate of 31
kbps and manual Manchester code detection and bit shifting, with a 8 bit
CPU of 8 to 12 MHz, 16 kB EPROM and 1 kByte RAM and a frame size of up
to 300 Byte in each direction ... and at least one bus side required
sending packet check sum in the header :( ... microcontroller ... and
OS? what's that? which OS? first instruction executed by CPU after reset
at address X ... that was my job world ;)
This is definitely not what we're doing here - if I can run
Linux, I can run a few dozens of separate binaries and a few hundreds of
long-lived processes, if they're small enough.
Do you remember those 386SX ITX board based systems ... at the upcome of
ADSL connections there where no router boxes, and DSL modem needed PPPoE
connection ... there existed quickly several systems, but required at
least 16 MB RAM and a hard disk ... then I did go a different way and
packed all together in one initrd (initramfs came later), dropped the
hard disk (ahhh, that silenence), switched the CPU (4 to 8 MByte RAM)
clock to lowest and removed the fan (quiet now) ...
... can you please check the router in the other room for me? ...
router!? ... in this room is no running computer! ... it is! ... no,
never! ... here! ... oghhhhhh! :)
... started with a simple DSL router with firewall, than adding this and
that functionality (applications) for customers, watching / controlling
phone systems and fax machines, sending informations to specific users,
accepting incoming modem calls with data exchange to / from external
employees, acting as alarm system, watching heat system and room
temperatures, doing data logging, etc. ... so it's my Linux way, about
20 years now ...
... and have you ever tried to teach an old dog new tricks? :)
Do I know how to do it in different ways? Yes
Do I like to it different? NO!!!
You understand?
--
Harald
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
