Jaromil <jaromil@???> 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).