[Debootloaders-miboot] Proposal for continued development

Mon Oct 16 04:54:23 UTC 2006

On Oct 15, 2006, at 2:30 PM, Aurélien GÉRÔME wrote:

> Hi Daniel,
>
> I am sorry that I did not get to you earlier...
>
> On Tue, Sep 26, 2006 at 12:05:08PM -0700, Daniel Gimpelevich wrote:
>> On Sep 26, 2006, at 10:18 AM, Aurélien GÉRÔME wrote:
>>> I was planning to contact you at some point in the future, it is nice
>>> you did it first. :)
>>
>> I would have done so earlier if it were possible; however, it was not,
>> for a rather varied list of reasons, including the fact that I was
>> unaware of exactly what may have been discussed without my
>> participation. Such reasons are unimportant now that I have made this
>> contact.
>
> Sure. :)
>
>> When I was reading the archives of this list a short time ago, I was
>> unaware that anyone else brought up to speed on the progress made in
>> the course of that exchange. It unexpectedly saves me from having to
>> reiterate its content in greater detail, at least as far as you
>> personally are concerned. I have no idea who else may have been privy
>> to the text of the discussion, but feel free to give copies of it to
>> whomever else is involved, upon Sven and Piotr's consent.
>>
>> I did read most of the archives, but skipped over a few messages that
>> seemed to be solely related to rsrce. I did not see a specific
>> TODO-list anywhere in there. Using BenH's last miBoot as a base was an
>
> The TODO-list is located at [1].

Regarding the points on that list:
1) Re-implementation might not be necessary for replacement; this still  
needs to be investigated.
2) Might I have a list of those 6 funcs? I can't say more on this point  
until I know which ones they are.
3) This makes very little sense as UniversalInterfaces isn't supposed  
to contain any code. It's just headers. They cannot be replaced with  
something free. If a loophole is not found in their licensing, the  
project is dead in the water already. Free code from libmacos, if any,  
would be a supplement, not a replacement for headers.
4) AIUI, the PEF dependency is limited to the generation of parts of  
the code in the build process, which would mean there is no dependency  
since PEF was designed to be interchangeable with XCOFF.
5) This point is trivial.

>> idea that I had in 2002, but upon closer examination, I decided it
>> would be more worthwhile to use Jeff Carr's modification of that
>> version, and I then began to look for some kind of archive where I
>> could find the source to it. I later wrongly concluded this was not
>> possible and made no progress until, at the end of 2004, I stumbled
>> onto that source along with Etsushi Kato's modifications to it. I
>> believe porting Etsushi Kato's version is the way to go, as i have
>> hinted all along. Porting BenH's last miBoot is at least a far better
>> idea than anything that would involve the early versions Sven used to
>> use. If that's what has already begun, then no effort has been wasted,
>> because practically any adaptation that would apply to that version
>> would also apply to the EK version.
>
> OK, I suppose there are more MacOSROM primitives used by the EK's
> version, such as what is used to manage keyboard input. Therefore,
> they would need to be reverse-engineered along the ones already used
> by BenH's version.

What's of paramount importance is whether the primitives are in m68k  
code or PPC code. Use of primitives in m68k code is inconsequential,  
because that does not involve putting non-free code into the binary.  
Was there really anything like that added to the PPC code?

>>> We already have a SVN at [2], so it might be possible. However,
>>> it depends on what you want to commit. :) If I understood clearly
>>> your mails on the nubus-pmac-users mailing-list, you want to setup
>>> everything to be able to build your (Jeff Carr + Etsushi Kato) miBoot
>>> fork with a CWPro version you can provide?
>>
>> Pretty much, yes. The Apple boot block that BenH threw in would be
>> perfectly omittable in doing so. That might very well still not be  
>> free
>
> Are you absolutely sure? I do not think so, this code is *really*
> used to boot the machine. The proof is that if it is not present, the
> machine cannot boot. Maybe are you saying that it could be simplified,
> because it is not *entirely* used?

Have you verified this by fabricating a boot block that is structurally  
correct and contains the correct data, but no code other than 0x4afc?  
Otherwise, you have no proof.

> In any case, we have the specifications from Piotr and the EMILE
> bootblock to help us. It is also a task which I volunteer for, I just
> need to sit down an afternoon to get it done. :)

It may not be necessary to have any code there at all, and if code has  
to be there, it may not need to do what the Apple code does.

>> enough for alioth, but I'm not aware of any compelling reason for
>> alioth to specifically be the central point of SVN development for  
>> this
>> project, other than the need to use the same SVN repo for both  
>> branches
>> to promote the sharing of code already freed, and the fact that the  
>> SVN
>> repo is already on alioth. I would have preferred to have settled this
>> concern, which I had from the beginning, prior to setting up SVN, but  
>> I
>> did not get the opportunity.
>>
>>> I am quoting you from [3]:
>>>
>>>  Also, it would be necessary to standardize a build environment
>>>  to prevent the kind of breakage present in EK's binary. IMO, one
>>>  of the easiest ways to do that would be to designate exactly one
>>>  person to be the only person ever to compile the code, with all
>>>  the changes everybody makes. I hereby volunteer to be that person.
>>>
>>> I disagree on that, I would like to be able to build it too, so maybe
>>> you can provide instructions and the necessary non-free software
>>> to build it? I have a copy of CWPro4, but surely not the same as
>>> yours. Otherwise, I fail to see what a distributed development model
>>> will bring to us. :)
>>
>> I agree with your disagreement, because that indeed makes very little
>> sense conceptually and would be full of problems in practice. However,
>> I think it could still serve as a reasonable shortcut while the  
>> project
>> is just getting off the ground. Obviously, it wouldn't be especially
>> practical to have Piotr commit patches, me build the binary, and then
>> Sven test the binary I built with Piotr's patches, although that would
>> be an example of what advantage a distributed development model could
>> still bring to the table. In any case, the arrangement would only
>> persist during an indefinite transitional period, which would end  
>> after
>> ALL the existing functional code is freed, and any further  
>> improvements
>> may be freely made to the freed version without even needing to refer
>> to the legacy builds. Indeed, CWPro4 is different from the toolchain I
>
> Sven who read your mail, but who did not get the time to answer,
> suggested me (in a real life meeting) that maybe you might setup a
> kind of auto-builder. We would send the source code via email to an
> email gateway. With black magic that you would code both on your unix
> email gateway and on your legacy MacOS, the source code would be built
> on your CWPro toolchain and the resulting binary would be emailed
> back to the sender. What do you think of that? Is it even possible
> (from the MacOS viewpoint, of course)?

I had not thought of this, so I have now looked into it, and it is in  
fact possible to set up, but I have doubts as to how feasible it may be  
in practice.

> Personally, I think it is too much hassle for everyone. I would settle
> for reverse-engineering from the beginning and I believe that it is
> everyone's idea too.

I don't see the reverse-engineering effort as replacing further  
development, only as yet more things that need to be done.

>> have set up, which is a collage of CWPro5 (fortuitously obtained with
>> difficulty through eBay), additional patches and components from
>> Metrowerks, stuff from Apple, and various other additions and tweaks,
>> primarily very tangential to the strict purpose of building nothing  
>> but
>> miBoot, but it has the advantage that it happens to work at the given
>> moment without requiring further investigation as to what's going
>> wrong. The need for this is exemplified by both the horribly broken
>> binary Etsushi Kato built from his perfectly sound patch, and the  
>> still
>> unidentified brokenness BenH introduced to BootX 1.2.1 by upgrading
>> from CWPro4 to CWPro5, thus necessitating the hasty throwing together
>> of another CWPro4 for the purpose of providing 1.2.2 as a last-second
>> solution. I only needed to make relatively cosmetic changes to the
>> Etsushi Kato source release to get it to build properly, which I
>> determined by attempting to build the Jeff Carr version from source  
>> and
>> diffing the result against the stock binary until I was able to  
>> produce
>> one that was virtually identical, and then applying the adjustments
>> that revealed to be necessary to the Etsushi Kato version. I doubt it
>
> By reading that, I see that you seem to master assembly and MacOS
> legacy stuff, we could really use your help for reverse-engineering.

Yes, particularly the m68k side of things. Unfortunately, much of that  
originally came at the expense of disassembling Apple code.

>> would be acceptable to the affected parties for me to distribute  
>> copies
>> of the CWPro5 discs that I have while I keep mine. In summary, there  
>> is
>
> True.
>
>> definitely work to be done here, and there is definitely plenty of  
>> room
>> for everybody to play large roles in it, regardless of what path we
>> take.
>
> Well, sure for the work and the credits, there is plenty. :)
>
> Cheers,
>
> [1]  
> <http://lists.alioth.debian.org/pipermail/debootloaders-miboot/2006- 
> July/000006.html>
> -- 
>  .''`.   Aurélien GÉRÔME
> : :'  :
> `. `'`   Free Software Developer
>   `-     Unix Sys & Net Admin
> _______________________________________________
> Debootloaders-miboot mailing list
> Debootloaders-miboot at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/debootloaders-miboot