Date: Mon, 18 Aug 2008 12:11:27 +0200 From: "Alexander Leidinger" <Alexander@Leidinger.net> To: "Adrian Penisoara" <ady@freebsd.ady.ro> Cc: freebsd-emulation@freebsd.org, Chagin Dmitry <dchagin@freebsd.org> Subject: Re: x86_64 linuxulator patches Message-ID: <20080818121127.745322h5l2ufrxs0@webmail.leidinger.net> In-Reply-To: <78cb3d3f0808180138o6c2e7c3bhf6f49b4de547b218@mail.gmail.com> References: <20080810072013.GA15196@dchagin.dialup.corbina.ru> <20080810115406.GR97161@deviant.kiev.zoral.com.ua> <20080810120424.GA15768@dchagin.dialup.corbina.ru> <20080810122124.GS97161@deviant.kiev.zoral.com.ua> <20080817181757.GA2940@dchagin.dialup.corbina.ru> <20080818100541.20073jcxqbtyci80@webmail.leidinger.net> <78cb3d3f0808180138o6c2e7c3bhf6f49b4de547b218@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting "Adrian Penisoara" <ady@freebsd.ady.ro> (from Mon, 18 Aug 2008 =20 10:38:02 +0200): > Hi, > > On Mon, Aug 18, 2008 at 10:05 AM, Alexander Leidinger > <Alexander@leidinger.net> wrote: >>> in my opinion the best decision for amd64 looks so. >>> we use two modules. linux.ko for x86_64 and linux32.ko for ia32, >>> option COMPAT_LINUX for x86_64 and COMPAT_LINUX32 for ia32. >>> and two linux_base directories: /compat/linux for x86_64 >>> and /compat/linux32 for ia32. >>> >>> there are other opinions? >> >> I propose: >> - /compat/linux64 for 64bit stuff >> - /compat/linux32 a symlink to /compat/linux >> - /compat/linux for 32bit stuff (we can think about having) >> > > I agree with this later proposition, it's a bad thing to break the > already established purpose for /compat/linux (32bit binaries). > > Here is yet another variation: > /compat/linux64 -- 64bit > /compat/linux32 -- 32bit > /compat/linux -> linux32 -- symlink, would this break anything in > the current ports/packages ? Making linux a symlink to linux32 will not work. I made the proposal =20 the other way around on purpose. If an user does not update after the =20 changes are introduced, any new installation (without the update) will =20 mess-up the installation. If you don't have to worry about backwards =20 compatibility, it's ok (and I would prefer it), but unfortunately it =20 will create more hassle than it will help in the real world (there are =20 too much people which will not make the right thing in such a case). I also thought about workarounds, by e.g. checking if all involved =20 paths are of the correct type and refuse to work or to adjust the =20 paths if they aren't, but this will make the LINUXBASE handling very =20 complicated, more than it is worth (there's already a lot of work to =20 do to get all infrastructure for this together). > I strongly oppose having linux.ko as the 64bit version, rather there > should be linux64.ko (linux-x86_64.ko ?) and linux32.ko (linux-ia32.ko > ?) and perhaps we should make linux.ko try loading both of these > (since the user did not specify the intended platform). I like this. linux.ko as a meta module which depends upon linux32 and =20 linux64 on amd64, and depends upon linux32 on i386. This way POLA is =20 preserved, the documentation is not wrong (to enable linux emulation =20 load the linux.ko), and people which only want one can load the =20 specific one. Bye, Alexander. --=20 =09A domineering man married a mere wisp of a girl. He came back from his honeymoon a chastened man. He'd become aware of the will of the wisp. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080818121127.745322h5l2ufrxs0>