RFD: Rework/extending functionality of mdev

[Harald Becker]

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