Hallo Denys! > Embedded machines are becoming bigger, and this trend will continue. > What is "too big for embedded" today will be acceptable tomorrow.
That's true ... remembers me about the sentence said to be from Bill Gates: "640 kB RAM ought to be enough for everyone". But there are not only embedded systems where size matters. My concern is for an init RAM file system usage, where the complete root file system is bundled with the linux kernel and loaded as a single file. I'm currently working toward a solution where that image fits ISO9660 boot image requirements. There we have a 2880 kB limit. And my indention is a completely working root environment not only a boot system that loads some modules and swaps in another root system. > I think implementing loadkeys is a better solution. What about implementing a separate loadkeys applet, that is based on the "-b" option. That is: Parsing the ASCII key table and writing a binary keyboard table on stdout. After doing some extension to loadkmap that could be used in a modular and compatible fashion (internally loadkeys always works in that two step fashion, only without the pipe). loadkeys -b KEYBOARD_DEFINITION | loadkmap For those purposes where the ASCII table parser is to be excluded the loadkeys applet can be disabled in the configuration. That leaves Busybox at the current usage level: loadkmap <BINARY_KEY_TABLE or zcat BINARY_KEY_TABLE_GZ | loadkmap What about that type of solution? > Please post your finding to the mailing list before you start > working on a patch to loadkmap. True. That was my intention. Had been busy that week and didn't do much at Busybox (watched to much those pictures from Japan the weeks before). -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
