Date: Tue, 1 Sep 2009 17:39:39 +0000 From: "b. f." <bf1783@googlemail.com> To: Jim <stapleton.41@gmail.com> Cc: Roland Smith <rsmith@xs4all.nl>, freebsd-questions@freebsd.org Subject: Re: 32 bit ports on an AMD64 system Message-ID: <d873d5be0909011039p4f012337h5ccbfc881af87ac@mail.gmail.com> In-Reply-To: <80f4f2b20909010940u460a7b81r6372f48690ac1246@mail.gmail.com> References: <d873d5be0908310811q7974f467xf772f95c662c5e19@mail.gmail.com> <80f4f2b20909010644j7962dc4cub71e725d083072ef@mail.gmail.com> <20090901155059.GA56945@slackbox.xs4all.nl> <80f4f2b20909010940u460a7b81r6372f48690ac1246@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
You've given some of your reasons for using amd64 -- but are your reasons for using 32-bit binaries on amd64 strong enough to make all of this worthwhile? Why not just use 64-bit binaries for all but the 32-bit-only ports? Sure, some 32-bit applications will actually run faster (the opposite is also often true) or use fewer resources, but is it worth the hassle? As for your earlier question, I haven't used multiple instances of X myself, either in or out of jails, but I have seen reports of others doing so, so I think it is possible, except perhaps in a few cases where hardware balks because the graphics driver isn't good enough. I guess you'll have to make some experiments. If you don't make provisions for running a 32-bit X, then is there much point to having, for example, 32-bit window managers, windowing toolkits, or GUIs? If you use a different LOCALBASE for 32-bit ports, you are going to have to use 32-bit versions of most trunk and branch ports. I still think a jail is your best bet -- after all, a "thin" jail, which reuses those portions of your system that don't need to be different inside the jail, is just a more thorough version of what you had hoped to accomplish with your 32-bit shell scripts. If you don't use a jail ... well, I have not tried to install a large number of 32-bit and 64-bit ports in parallel, so I am not sure if the default setup for our loader will make the appropriate distinctions between 32-bit and 64-bit versions of the same libraries depending upon the executables or libraries that need them, but I think that there is a good chance that it will not, and that you will have to do some extra work to make sure that it does. In the case that it does not, your only alternative is to either patch a large number of ports (very time-consuming and error-prone), or to add loader environment variables to your 32-bit shell scripts to make the loader look in the 32-bit library directories first, or to write a custom loader script to only load the appropriate libraries depending upon whether the executable or library that needs them is 32-bit or 64-bit. It would be nice to have this flexibility, but given the current state of the base system and infrastructure, it just seems like more trouble than it is worth. b. On 9/1/09, Jim <stapleton.41@gmail.com> wrote: >>> [...] but the ability to use extra memory *and* dynamically load >>> kernel modules is a bit more important to me. >> >> All FreeBSD supported platforms can dynamically load native kernel >> modules, so >> why should that be a factor in choosing between i386 and amd64? >> >> Roland > > I didn't specify just loading modules, but extra memory as well (the > beyond 4GB addressable space). Using the options in i386 that allow > you to access memory beyond 4GB, also eliminates the ability to > dynamically load kernel modules. > > -Jim Stapleton >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0909011039p4f012337h5ccbfc881af87ac>