[syslinux] Thoughts: chaindev -> altchain

[Shao Miller]

On 8/1/2011 14:07, H. Peter Anvin wrote:
> On 03/06/2011 01:26 PM, Michal Soltys wrote:
>> On 11-03-06 22:16, H. Peter Anvin wrote:
>>> On 03/06/2011 12:58 PM, Michal Soltys wrote:
>>>>
>>>> It's superset with compatible command line options. It should work for
>>>> anyone as a drop-in replacement.
>>>>
>>>> doc/chain.txt lists all the currently implemented features
>>>>
>>>> git://git.hasevolq.net/syslinux.git chaindev
>>>>
>>>
>>> I would like to aim for merging it after 4.04 is released, unless there
>>> is a reason not to.
>>>
>>> -hpa
>>>
>>
>> Sure thing.
>>
>
> Hi Michal,
>
> I'm horribly sorry for being this late... I kept thinking I had already
> dealt with this. I can't get to your git server at the moment; any way
> I could get a copy of your tree?

I think that I've reproduced two of Michal's branches in the 
'soltys_chaindev' and 'soltys_disklibdev' branches here:

   http://git.zytor.com/?p=users/sha0/syslinux.git;a=summary

Michal had some remarks:

> disklibdev has one small commit more on top of origin. Namely:
>
> 45e8e56953e74c7bb
>
> This one basically removes redundant code, as functions responsbile for
> reading and writing were practically identical (HPA recommended doing
> that, though a while later he said to try to just base everything on top
> of core/fs functions).
>
> Earlier few of my commits were merged w/o problems.
>
> I'm still not sure, if disklib is to be merged with syslinux or not. In
> the latter case, disk.c/h can be simply moved back to chain
> subdirectory, and simplified towards core/fs wrapper over time. Or
> something similar.
>
> chaindev:
>
> - documentation (doc/chain.txt) needs some updates. Both for proper
> english syntax and some details/flow information
> - one more option I plan to add is 'setos', which will be minor
> variation of some existing mangle_pe* function.
> - most files still need license thingy at the top
> - the code might seem over-paranoid with sanity checks (especially in
> partiter.c), though I think it's a good thing considering what the
> module is responsible for (esp. regarding writing - 'save', 'fixchs', 
> etc.)
>
> I'll try to do the additions soon (though my inet access is still from
> work only).
>
> Early commits don't necessarily go from compilable to compilable
> version, so they will need squashing or some careful rebasing (if "every
> commit must compile" is mandatory).
>
> The code has been pretty thoroughly tested, though obviously it was only
> me that did the testing. Still, I have checked functionality with weird
> layouts (out of order, holes) and if it bails out properly as soon as
> something really broken is encountered.