From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13622 Path: news.gmane.org!.POSTED!not-for-mail From: Arnd Bergmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Data structures defined by both linux and musl Date: Fri, 18 Jan 2019 22:07:38 +0100 Message-ID: References: <20190118185500.GP23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1547845563 19404 195.159.176.226 (18 Jan 2019 21:06:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 18 Jan 2019 21:06:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13638-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 18 22:05:59 2019 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 1gkbKw-0004tf-91 for gllmg-musl@m.gmane.org; Fri, 18 Jan 2019 22:05:58 +0100 Original-Received: (qmail 1797 invoked by uid 550); 18 Jan 2019 21:08:07 -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 1746 invoked from network); 18 Jan 2019 21:08:06 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=e4HPDEFHLPKd1WAK5UJUVtXHPjRQ4v5l2bKQgxk2HH4=; b=A0tV1qr+9/1DUZs6S65kF7rxhszE193qDja4TrzzcljoI0CZIwEpRP8ZiHfynHT1eU zkms7McU+7yWi3knStnFKFn8Gr1dVtApiG6pz4riiGgHJaEq/jDqHGmC3Bk0iuNw8gEG B9V94UZtHLAbbjzNt+hWN6/ZiW05XK9KGtSIlMFOanAwgJlGZ6eTmqwbMUyrWsnq5HQy kjCIyznmRWEGxfDWpYUzfDbYDf8ifeQ+cBnJ4y4UVsYmA6pElYQMqB3RFqtAeZCw0YuB MjYI2VEGP9nKw1kBDF6YKB6jI5U36gAH/LiH7/HLRYV0QJUMBPkCsfZfwMmF2Iy++4XY /xsw== X-Gm-Message-State: AJcUukfpEUT4K8dccVau+hOb+Kk+lu5nZvfRkroN1T2+GLFC/IR79JQf QzyGTWeZucmj8f+aHxD8sAnNvg1Y+KekmJwF6Tn/Aw== X-Google-Smtp-Source: ALg8bN7Bn9Een2RWBMcN2mxpjSbC6Og0ghmYHovE8YJLvFH/bb7LCKNr7ptQeI8FKL3aKib/v6LTiHyBZleiDHOBb/8= X-Received: by 2002:ac8:1d12:: with SMTP id d18mr17316603qtl.343.1547845674457; Fri, 18 Jan 2019 13:07:54 -0800 (PST) In-Reply-To: <20190118185500.GP23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13622 Archived-At: On Fri, Jan 18, 2019 at 7:55 PM Rich Felker wrote: > On Fri, Jan 18, 2019 at 06:06:01PM +0100, Arnd Bergmann wrote: > > #if __BITS_PER_LONG == 64 > > #define LPSETTIMEOUT LPSETTIMEOUT_OLD > > #else > > #define LPSETTIMEOUT (sizeof(time_t) > sizeof(__kernel_long_t) ? \ > > LPSETTIMEOUT_NEW : LPSETTIMEOUT_OLD) > > #endif > > > > This way, we guarantee that we can still detect the data type > > expected by an application calling LPSETTIMEOUT. > > The same approach is used for setsockopt and some other > > interfaces. > > Unless I'm misunderstanding something, this still leaves new programs > using 64-bit time_t unable to make the ioctls on old kernels that lack > the updated ioctl command. There's probably some significant subset of > important commands that ioctl.c needs to be able to intercept and > emulate. That is correct. The number of ioctls that are affected here is fairly small, and some of them are in rather obscure drivers, but I was still hoping that we could avoid emulating them in libc, and just require newer kernels for anyone who really wants to run 64-bit time_t and use those drivers. > > In other cases (in particular when we never pass absolute > > CLOCK_REALTIME data), we changed the type inside > > of a structure from time_t to 'long' or 'unsigned long', in > > order to keep the ABI unchanged. The disadvantage here > > is that it requires user space to use updated kernel headers, > > which is a problem for applications that ship with a copy of > > the kernel header. > > I think this is reasonable. It's not reasonable for kernel structures > to have standard userspace types like time_t in them (except > fixed-size ones like uint32_t, but kernel has __u32 for that anyway) > and shipping copies of such headers was likewise a bug that should be > corrected. It may be a moderate pain for distro ppl fixing this until > the affected upstreams do, tho. A lot of those structures have a long history, e.g. rusage has always been defined in terms of timeval. I'd like to change this, but it will be a lot of work to go through all uapi structures. I can also understand the reasons for shipping copies of the latest kernel headers in packages, this is not unlike what you do in musl with its own version of the files. When a user space package only cares about one header for a particular subsystem, it tends to be easier to have a current copy of that header, and just deal with binary compatibility for old kernels in the package, than to have to support all combinations of library, header and running kernel. > > The same is true > > for read/write based chardev interfaces such as /dev/input/eventX, > > which we had to redefine to use a structure based on 'unsigned long' > > Uhg. How does this work with a 32-bit userspace running on a 64-bit > kernel?! These should never have used long, only u32 or u64. Is it > fixable? Or is there some reasonable way for userspace to detect which > protocol the kernel is using? We have a hack in that driver that detects when it's being called by a compat mode thread, and another hack to detect x32 mode on top of the first. Unfortunately, the kernel cannot detect the definition of the time_t type that was used in the process reading the file descriptor, so after long discussions we settled on leaving it at the ABI and not adding more hacks to it, but requiring user space to be aware that it has to use the updated kernel headers in this case (which don't use time_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. > > > > > > Redefining libc types is already broken, and the kernel headers that > > > do it can't be used from userspace when libc headers are included. > > > This issue is independent of type sizes/layouts matching. > > > > > > I don't think any kernel headers _use_ libc types either. They > > > generally use their own stuff. > > > > 'struct timespec' is a notable exception here, but probably not > > the only one. At the moment, both libc and kernel define this > > structure (and timeval, itimerval, itimerspec, ...), and in my > > work on the kernel interfaces I assumed that the libc version > > is the one that will prevail, while the kernel version should get > > removed. > > Yes, I think any type defined by userspace standards/interface > definitions inherently belongs to userspace implementation, and kernel > headers should not touch it. That is a sensible rule, it just doesn't match what has been done historically. Now we have to retrofit it while trying to break as little as possible in the process. Arnd