From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13560 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Data structures defined by both linux and musl Date: Thu, 20 Dec 2018 11:33:59 +0100 Message-ID: <20181220103358.GB21289@port70.net> References: <20181220003044.GK23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1545301927 27723 195.159.176.226 (20 Dec 2018 10:32:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Dec 2018 10:32:07 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13576-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 20 11:32:03 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gZvcZ-00076W-EO for gllmg-musl@m.gmane.org; Thu, 20 Dec 2018 11:32:03 +0100 Original-Received: (qmail 11819 invoked by uid 550); 20 Dec 2018 10:34:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11798 invoked from network); 20 Dec 2018 10:34:11 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20181220003044.GK23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13560 Archived-At: * Rich Felker [2018-12-19 19:30:44 -0500]: > On Tue, Dec 18, 2018 at 08:41:53PM +0100, Arnd Bergmann wrote: > > I recently discussed with Rich about the work needed to get 64-bit time_t > > support into musl. One of the first steps he identified was to find out which > > interfaces we would want to abstract or wrap for a new ABI given that we > > have to make a binary incompatible interface anyway. > > > > I have found all the data structures that are provided by both the kernel > > headers and the musl headers now, and annotated what I think we the > > path forward could be. I already provided the same list on IRC, but > > here is a (slightly updated) copy for everyone else. > > Thank you. For those just joining now, the context of this is that > support for 64-bit time_t on 32-bit archs probably requires, and at > least is best done with, a new ABI, so far known as the ".2" ABI > (because the ldso would end in ".2" instead of ".1"). This would be an > opportunity to fix lots of ABI mistakes where extensibility of even > support for current functionality is lacking. If done, this would not > be a fork of musl and would not be dropping existing ABIs. Rather, > internal refactoring would eliminate the assumption that the > ABI-with-application types match the ABI-with-kernel/syscall types, > performing translation back and forth where needed. On the existing > ".1" ABIs, this translation would mostly be the identity > transformation, but on archs where we're already doing some hacks to > fix up kernel ABI bugs (sysvipc on big endian, mips stat structure, > x32 stuff, etc.) the hacks could be replaced by used of this > translation infrastructure. lesson of ilp32 was that libc cannot generally translate between a user and kernel abi (otherwise it could be done in userspace). the problematic cases are when user talks to the kernel directly using libc types in a way that the libc cannot do the translation. interfaces where the libc does not know the type, just an opaque pointer: ioctl, fcntl, getsockopt, setsockopt, raw syscall interfaces where translation would require malloc, but should be as-safe and not fail with ENOMEM: sendmmsg, readv, writev,... direct communication channel to the kernel that may expose the abi incompatibility: netlink, sysfs, procfs types related to signal handling that may require sighandler wrapping to translate: siginfo_t, ucontext_t time_t may not be affected by these, but it shows that translation is fragile in general, i wonder if we can ensure correct behaviour in all cases. there is also the problem of linux headers which may use and redefine libc types and user code may need to use those.