[RFC] what to name linux 32-bit compat

[Astrodog]

On Tue, 18 Jan 2005 08:36:13 +0100, Andreas Klemm <andreas at freebsd.org> wrote:
> On Mon, Jan 17, 2005 at 09:46:17PM -0500, John Baldwin wrote:
> >
> > Personally, I think /compat/linux32 and /compat/linux (for linux64) would be
> > the best way to go.  The idea being that /compat/linux runs native binaries
> > on any given arch, and if there's more than one arch supported, the
> > non-native ones get the funky names.
> 
> Am not 100% sure but it might be a win to re-think this for port
> builders/designers.
> 
> It might be beneficial not to use such "implicit" rules for naming
> like your suggestion for taking /compat/linux as native arch.
> 
> I would perhaps name /compat/linux32 and /compat/linux64 explicitely,
> which might be a win and is IMHO not too expensive.
> 
> Uname should IMHO get a new switch to print out default architecture
> of being 32 or 64 bit.
> 
> So together with uname and the above naming scheme you have all you need
> and is compareable to what we already have (concerning uname) for
> cpu architecture.
> 
> Do perhaps other BSD teams have added an mechanism like that or
> do they get 32/4 bit out of /proc ?
> 
> Best regards
> 
>        Andreas ///
> 
> --
> Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
> Need a magic printfilter today ? -> http://www.apsfilter.org/
> _______________________________________________
> freebsd-amd64 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe at freebsd.org"
> 

Not sure if it got lost, so I'm gonna summarize what I said earlier,
Why not have /compat/linux32, and /compat/linux64 (For things that
require one or the other), then just have /compat/linux linked to the
native setup for the machine? That gives the ease of /compat/linux for
the native stuff, without causing the problems Andreas pointed out.
Also allows people with "clean" 64-bit friendly code to just use
/compat/linux on AMD64 or i386, and have things work in whatever way
is native to the machine.

This could also be extended to other archs, if that ever becomes an
issue. (linuxppc, linuxsparc64, whatever), with linux still pointing
to native.

--- Harrison Grundy