On Tuesday 22 March 2011 17:24, Harald Becker wrote: > >> Can we improve Busybox and add those functionalities? Attention: > >> Modifications at this point probably introduces an incompatibility to > >> current Busybox versions, ... > > The best way would be to evolve tovards using data formats > > and command-line options which are compatible with relevant > > standard tools. > > That would be the loadkeys command and the keyboard table format > described in the keymaps(5) manual page. ... but that one is an ASCII > source table that needs complex parsing. That parsing, including dynamic > table handling, would require a lot of code and data space. I don't > think that this really hit's the Busybox "keep it small" philosophy. > > Currently I do not see any possibility to step toward standard tools > without including a full ASCII key table parser. On the other side, I > like the idea of having small binary key tables that do not consume much > resources for loading during boot (especially on init file systems). > That is really a decision conflict. Which way shall we go with Busybox? > Keeping things small and simple while providing required functionality > or stepping toward standard tools and including a full ASCII key table > parser?
On Tuesday 22 March 2011 18:06, Laurent Bercot wrote: > 'loadkeys' is just a well-known tool that manages keyboard tables > under Linux, and it is only widely used because nobody ever bothered to > design another one. That hardly makes it a standard. > > Having the same interface as "loadkeys" offers one benefit: busybox > can then be used as a drop-in replacement for original loadkeys. > This benefit should be compared to the benefit of designing and using > a leaner interface, that will not require including a full table parser > into the busybox binary. I agree with Laurent. Supporting two different tools for the same purpose fragments user base. Embedded machines are becoming bigger, and this trend will continue. What is "too big for embedded" today will be acceptable tomorrow. Heck, twenty years ago people would consider madness to run a full-fledged Unix kernel like Linux on an embedded device - "it's far too big". I think implementing loadkeys is a better solution. On Tuesday 22 March 2011 17:24, Harald Becker wrote: > I dig into loadkmap applet source and found a possibility of extending > the binary key table format in a compatible way. We can just append > binary string and diacritical tables to the binary key tables. That way > on reading the key table premature EOF means missing string and > diacritical tables (old format). On the other hand old versions of > Busybox would just stop loading after the binary key table and will > ignore the string and diacritical tables of new format files. Nice > behavior for compatibility with older versions, but than there would be > no other version check of the key table format. ... and may be there is > an incompatibility with current "loadkeys -b" output. It looks like they > add some extra information after the binary key table. This extra > information is ignored by current Busybox loadkmap applet (needs to be > investigated). Please post your finding to the mailing list before you start working on a patch to loadkmap. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
