How to config timezone of linux_base-f8
Alexander Leidinger
Alexander at Leidinger.net
Tue Mar 10 13:26:03 PDT 2009
On Tue, 10 Mar 2009 13:34:45 -0500 (CDT) "Sean C. Farley"
<scf at FreeBSD.org> wrote:
> On Tue, 10 Mar 2009, Alexander Leidinger wrote:
>
> *snip*
>
> >> It's on my TODO list but not the first one. ATM I'm working on new
> >> linux infrastructure ports. And as always patches are welcome. ;-)
> >
> > I want to add that there's still hope that the timezone stuff in
> > -current gets updated soonish (which means we don't need tzdata in
> > f8, as 7.1 will not switch to f8 by default as it would 1. violate
> > POLA and 2. does not have the necessary emulation stuff to be
> > compatible with 2.6.16).
>
> Out of curiosity, when you say necessary emulation stuff to be
> compatible with 2.6.16, how compatible is it? I use it on 7-STABLE
> quite well with Skype and Acroread8, somewhat well with Flash plugin
> 9 and not well at all with linux-ut (at least with the nvidia driver).
I would say it is compatible enough to run Skype Acroread8 and a little
bit of Flash... ;-)
What is missing is for example the *at() funktions. Soon there will be
a different futex implementation in -current. There may be more which
escapes my memory ATM.
> Will all that is necessary to use full 2.6.16 emulation be eventually
> MFC'd, or will only some of it? Of course, keeping the default at
> 2.4.2 emulation is perfectly fine.
The *at() stuff can not be MFCed, as it depends upon VFS stuff which
will not be MFCed due to API/ABI concerns. The futex stuff can maybe
MFCed, but I don't really know.
> On a related note, would it be possible to be able to run one
> application under 2.4.2 emulation while another is under 2.6.16 in
> the future? I thought it may help in some situations. There could
> be a /compat/linux.f8 (with /compat/linux linking to it) and
> /compat/linux.fc4 where the application can be told via an
> environment variable to use a specific install.
Currently it's either 2.4 or 2.6 (don't switch while a linux process
is (still) running), and with the current implementation I don't really
see an easy way to do this.
Someone could make a copy of the current linuxulator and use a
different ELF-brand for the copy. The copy would then have to be
modified to use a different path for the linux base, and every
non-static function/symbol would need to be renamed. Praktically I
would say too much work, not enough return of investment.
Would be cool to have from a geeky point, but if you really _need_
this (business stuff instead of "I would like to"), take an older
version of FreeBSD and let it run on another machine.
Bye,
Alexander.
More information about the freebsd-emulation
mailing list