Jaromil <[email protected]> writes: > On Mon, 30 May 2016, Rainer Weikusat wrote: > >> I have no plans to use anything but lilo unless that's a technical >> requirement. It boots. That's all I want from it. > > having dealt with it recently, what is your opinion on the current > state of Lilo code?
"It's code"? What I've done with this so far is add a facility for include files and directories so that I can support mixed manual/ automatic management of lilo configuration more easily, short-circuited all of the 'working code' dependent on a global variable set via command-line option to enable using the parser for automated syntax checking and added a (yet untested) configuration option for incrementally building kernel command lines as I need some appends which are always there (panic=30), either VT or serial console or both, depending on the machine in question, and possibly other things in future. This means I haven't seen much of the code beyond the main function (in lilo.c) and the config parser. The main function is longer than what I'd ever write myself but reasonbly straight-forward/ easy-to-understand, ie, nothing like, say, the fetchmail code (I've also worked with that in the past). The config parser is based on building tokens based on single-character reads and putting these into 'tables' (linearly searched arrays of name/ value pairs). It's composed of small, sensibly-named function and easily understood. It's structurally limited to processing lilo.conf files, ie, there's no way to associated arbitary processing actions with tokens beyond triggering main program state transitions, eg, switching to 'image parsing mode' from 'global options parsing mode'. I've added the 'build command line incrementally' feature as special case to the 2nd level 'handle name/ value pairs' function in a slightly general way by using mock pointers (with 0xffff in the highest sixteen bit and a separator char in the lowest byte) in order to detect an option supposed to build a string piece-by-piece. There's a somewhat odd 'addappend' image option which can be used to add exactly one string to the existing append string. That's supposed to be used to add per-image parameters to the global parameter list. I strongly suspect the most recent maintainer implemented this because it was the path of least resistance wrt enabling some level incremental command-line construction. > is there any possibility that you take up its maintanance, without > adding new features and likely without having anything to do really? > its still good to have someone who knows the code of the package as a > reference for questions, CVEs and such. I'm willing to help with any such effort, eg, I can answer questions and implement minor (< 100 lines of new code) changes because other people need them, but I can't commit any time to this beyond occasional 'under the radar' activities unless I need a certain change badly enough that I can argue it through with the suit&tie people. And then, I have to take the most quick-and-dirty approach towards implementation I consider to be well-done enough that I can continue working with the code without accepting an undue, longer-term maintenance burden. I'll certainly fix any CVE-level issue I consider to be relevant for my use cases and I'll gladly share such changes if they seem generally usable (subject to me being allowed to do so, of course). _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
