From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4721 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Build on linux 2.6 and run on linux 2.4? Date: Wed, 26 Mar 2014 02:22:44 -0400 Message-ID: <20140326062244.GD26358@brightrain.aerifal.cx> References: <20140320231412.GG26358@brightrain.aerifal.cx> <20140321005135.GH26358@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1395814970 2605 80.91.229.3 (26 Mar 2014 06:22:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Mar 2014 06:22:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4725-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 26 07:23:00 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WShEp-0005Hc-HR for gllmg-musl@plane.gmane.org; Wed, 26 Mar 2014 07:22:59 +0100 Original-Received: (qmail 7538 invoked by uid 550); 26 Mar 2014 06:22:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7524 invoked from network); 26 Mar 2014 06:22:57 -0000 Content-Disposition: inline In-Reply-To: <20140321005135.GH26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4721 Archived-At: 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