[Debootloaders-miboot] Proposal for continued development

[Aurélien GÉRÔME]

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].

> 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.

> >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?

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. :)

> 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)?

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.

> 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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debootloaders-miboot/attachments/20061015/54e16aab/attachment.pgp