[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 26 Mar 2014 02:22:44 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Build on linux 2.6 and run on linux 2.4?
On Thu, Mar 20, 2014 at 08:51:35PM -0400, Rich Felker wrote:
> > However, Linux 2.4 is not officially supported since it lacks a lot of
> > functionality needed to provide a modern POSIX conforming environment.
> > The most notable is that it can't do threads. If you're ok with that,
> > the other problems might be small enough that you don't mind. I
> > remember some people in Freenode #musl trying out 2.4 recently and
> > finding that a few of the busybox applets didn't work right, though,
> > due to missing statfs64 syscall.
> >
> > This page has details on which kernel versions added which syscalls:
> >
> > http://man7.org/linux/man-pages/man2/syscalls.2.html
>
> I looked through this list, and statfs64/fstatfs64 seem to be the only
> two syscalls where the 32-bit off_t version was all that's available
> in 2.4 and the 64-bit version was added in 2.6. So if we could provide
> a fallback for them, this might make 2.4 a fairly viable target for
> single-threaded programs built with musl. (Despite 2.4 being ancient
> and generally a bad idea to use, there are some devices where
> replacing the kernel is hard or where the patches to support the
> device have not been ported to 2.6, so this isn't just a useless
> exercise.)
>
> The big question that remains of course is how ugly the fallbacks
> would be, and whether we'd need a lot more arch-specific definitions
> _purely_ for 2.4 fallback.
While investigating possible thread pointer fallbacks for phase 2 of
the lazy thread pointer init removal, I discovered that it seems
possible to provide threads even on 2.4, at least for i386. The
modify_ldt-based approach to setting the thread pointer should work
for multiple threads, not just the main thread. However there are
definitely other syscalls 2.4 is missing that would need some
fallbacks to achieve reasonable behavior, even for non-multithreaded
programs. For example, even raise() is likely to be failing now due to
missing tgkill.
So I think we can fairly safely say up til now musl on Linux 2.4 is
quite broken and unlikely to work, even for many simple apps. In a way
that's good because it means it's very unlikely that changes related
to removing lazy thread-pointer init are breaking anything that worked
before. But it's also unfortunate that users who want to run static
musl binaries on ancient kernels might encounter a lot of breakage.
I *think* basic, reasonable support for 2.4 (in the sense of having at
least code that worked back when 2.4 was current still work now) could
probably be achieved without significant complexity or bloat. If
anyone wants to research this, it's basically just a matter of looking
at what functions, other than think syscall wrappers for the new
syscalls themselves, depend on syscalls added after 2.4. In most cases
I think reasonable fallbacks (using whatever old syscalls were used
back then) should be possible, and with inline syscalls such fallbacks
are unlikely to consume more than a few bytes of additional size.
Is anyone interested in looking into this?
[Note that none of this affects John Mudd's (OP's) usage case since
his kernel, despite calling itself 2.4, is a RHEL kernel that's
essentially 2.6.]
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
