We were discussing this in IRC and the response to ELF was basically,
"whats wrong with a.out?", which is a very reasonable question. What are
the tradeoffs involved with these binary formats?

Anyone?

JAn

On Sat, 26 May 2001, Ian Mondragon wrote:

> i think ELF is the way to go for now (once we get these problems sorted out, of
> course), but i do find the thought of mach-o/fat binaries on xMach intriquing.
> i pulled down the kernel source for darwin last night (xnu) and started checking
> out the files dealing with mach-o binaries (after expanding the tarball, you'll
> find the headers in "xnu-3-1/libkern/mach-o").  i was also going over the APSL
> to see how that would play into everything, assuming that we did eventually
> either modify darwin's code or mimic it in some way, and the liscence didn't
> seem to be *too* harrowing...here's the part that would pertain to us utilizing
> it in xMach:
>
> /*============== snip from Apple Public Source Liscence ==============*/
>
> 2.2 You may Deploy Covered Code, provided that You must in each
>   instance:
>
>   (a) satisfy all the conditions of Section 2.1 with respect to the
>   Source Code of the Covered Code;
>
>   (b) make all Your Deployed Modifications publicly available in Source
>   Code form via electronic distribution (e.g. download from a web site)
>   under the terms of this License and subject to the license grants set
>   forth in Section 3 below, and any additional terms You may choose to
>   offer under Section 6.  You must continue to make the Source Code of
>   Your Deployed Modifications available for as long as you Deploy the
>   Covered Code or twelve (12) months from the date of initial
>   Deployment, whichever is longer;
>
>   (c) if You Deploy Covered Code containing Modifications made by You,
>   inform others of how to obtain those Modifications by filling out and
>   submitting the information found at
>   http://www.apple.com/publicsource/modifications.html, if available;
>   and
>
>   (d) if You Deploy Covered Code in object code, executable form only,
>   include a prominent notice, in the code itself as well as in related
>   documentation, stating that Source Code of the Covered Code is
>   available under the terms of this License with information on how and
>   where to obtain such Source Code.
>
> /*============================= end snip =============================*/
>
> ...so it doesn't appear to me to be *completely* evil.  if i'm wrong and missed
> something, and it really *is* evil in terms of the goals the xMach core team
> are seeking to achieve, feel free to bean me upside the head the next time you
> see me.  otherwise, i think mach-o/fat binaries wouldn't be such a shabby idea
> in the long run, and i would be happy to help out in any way i can with the
> development whenever it comes time.
>
> - ian mondragon
>
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [05/25/01 23:55]:
> > We are heby requesting proposals on the issue of binary formats for xMach.
> > The obvious ones are ELF and a.out. Less obvious would be mach-o for fat
> > binary capability, since we eventually want to get this baby on different
> > architectures.
> > If you have suggestions and comments, please submit them. This is for the
> > mid-term, probably post 1.0, but we need to get the discussion going
> > already.
> >
> > JAn
> >
> >
>
> --
> @end
>
> Ian Mondragon  - < copal @ dragonhelix . org >
>
> < h t t p : // d r a g o n h e l i x . o r g >
>
> <<< F r e e B S D -- O b j e c t i v e - C >>>
>

Reply via email to