From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4868 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing for releases 1.1.0 and 1.0.1 Date: Thu, 10 Apr 2014 21:39:11 -0400 Message-ID: <20140411013911.GQ26358@brightrain.aerifal.cx> References: <20140410024045.GA6538@brightrain.aerifal.cx> <20140410131122.GR3034@port70.net> 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 1397180372 8899 80.91.229.3 (11 Apr 2014 01:39:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Apr 2014 01:39:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4872-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 11 03:39:25 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 1WYQRB-0004u3-96 for gllmg-musl@plane.gmane.org; Fri, 11 Apr 2014 03:39:25 +0200 Original-Received: (qmail 16247 invoked by uid 550); 11 Apr 2014 01:39:23 -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 16236 invoked from network); 11 Apr 2014 01:39:23 -0000 Content-Disposition: inline In-Reply-To: <20140410131122.GR3034@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4868 Archived-At: On Thu, Apr 10, 2014 at 03:11:23PM +0200, Szabolcs Nagy wrote: > * x32 timex is broken (should use long long on x32) > > diff --git a/include/sys/timex.h b/include/sys/timex.h > index 2e68888..e404e8b 100644 > --- a/include/sys/timex.h > +++ b/include/sys/timex.h > @@ -17,6 +17,9 @@ struct ntptimeval { > }; > > struct timex { > +// TODO: x32 > +// 7fb30128527a4220f181c2867edd9ac178175a87 2013-12-27 > +// x32 adjtimex system call is the same as x86-64 adjtimex system call, > unsigned modes; > long offset, freq, maxerror, esterror; > int status; Uhg, so do we need to move this to bits or do some ugly hack? Or rewrite it in the syscall wrapper code like for timespec? > * math alias issues on non-x86 archs (about +80bytes) > (either this or __may_alias__) I prefer the +80 bytes; the other may_alias uses are optional and have a portable fallback. > * use 1/eps for rounding check (with *4 it's nicer, ymmv) Could you explain why? I would prefer a change that doesn't require so many lines changed since they're all places errors could hide. Just getting rid of the CONCAT hack seems preferable to me, but I don't mind hearing the reason you like the *4. > * only use nanosec for entropy I just worry on some archs with bad timer, this could prevent getting sufficiently many temp names (of course the problem already existed). Is there more non-valuable entropy we could merge into it? One idea was the bytes of struct stat from stat() on /proc/self (this is like using pid, but better). But perhaps there's more we could do with just time. > * broken legacy header.. > > diff --git a/include/sys/procfs.h b/include/sys/procfs.h > index f7936c4..a1fcabf 100644 > --- a/include/sys/procfs.h > +++ b/include/sys/procfs.h > @@ -40,7 +40,7 @@ struct elf_prpsinfo > char pr_zomb; > char pr_nice; > unsigned long int pr_flag; > -#if UINTPTR_MAX == 0xffffffff > +#if UINTPTR_MAX == 0xffffffff && !defined __powerpc__ I'm ok with this hack I think. > unsigned short int pr_uid; > unsigned short int pr_gid; > #else > > * linux 3.14 stuff > (sched_setattr/sched_getattr syscall numbers, new sockopt flag, new arphdr type) This should probably be held until a later release. We need to consider ABI issues. I believe we have sufficient room to put a union (rather than the kernel's silly non-union approach) over top of our schedparam struct and fit all the values needed without ABI breakage, but this requires some code to convert to/from the kernel format. > * makefile/config changes for out-of-tree build Last I checked you were still finding breakage in it. When I get done with the release and other higher-priority things I'm trying to get done, maybe I should look at it and give it a proper review. Sorry I haven't gotten around to that yet. Rich