mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: musl@lists.openwall.com, y2038 Mailman List <y2038@lists.linaro.org>
Cc: Rich Felker <dalias@libc.org>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>
Subject: Re: Data structures defined by both linux and musl
Date: Fri, 18 Jan 2019 17:50:50 +0100	[thread overview]
Message-ID: <CAK8P3a01TJ3ycbtJBGqTNi9VCGZ-CaAo48SSmE7HQP8gWzVCrA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a07mbAAxtcZkiNnxMiVmEhEyYCmW5tdLG4O_ftTcJtw0w@mail.gmail.com>

(Sorry for replying late again, I was not subscribed to the list then (I am now)
and did not get Cc'd on the follow-ups to my original mail)

On Wed, 19 Dec 2018, Rich Felker wrote:
>
> BTW regarding 64-bit time_t on 32-bit archs, Arnd has been working to
> make this happen for a long time. I believe it was over 3 years ago we
> first spoke about working on it in musl. Basically we've reached the
> point where 32-bit archs are a dead-end for developing embedded stuff
> that needs to run indefinitely without the ability to upgrade, and
> this domain is the main place where 32-bit archs are still very
> relevant. Once nice thing about making a new clean ABI is that
> embedded users who don't care about binary ecosystems can switch
> immediately, and desktop/server distros can take their time and switch
> from .1 to .2 when it works best for them.

FWIW, I have now uploaded a series that has a chance of getting
merged for 5.1 in my y2038 tree:
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038

I still have to repeat the LTP tests I did over the summer
after getting musl to build again with the changes that
happened in the meantime, but this should be fairly close to
what we get. Any comments on the kernel ABI changes
are highly welcome.

> Now, a few comments on findings so far. These won't be complete but
> they're a start:
>
> > The takeaway is that we probably need to add new definitions for
> > flock64, statfs, stat, termios, {msg,sem,shm}{buf,info,id_ds}, ipc_perm,
>
> Not clear on how flock[64?] is affected.

In my list, I had mentioned that the kernel's flock64 is different
from musl's flock structure on sparc64 (which has an extra
padding field) and on mips (I may have been mistaken there,
only flock differs on mips32, flock64 is apparently fine).

If we don't care about musl on sparc, there may be no need to
do anything here.

> stat and ipc structures contain time_t's and definitely need to
> change.

Right, the traditional kernel definitions here have numerous
problems, most importantly the fact that they are different
on each of the old architectures.

> I think termios is listed here because .2 ABI overhaul is a great
> opportunity to switch to the "termios2" interfaces, unify the
> userspace types, and make support for custom baud work right.

Correct. There is also some inconsistency between the architectures
here.

> > rlimit, rusage, sched_param, time_t, timeval, timespec, itimerval,
> > itimerspec, and timex, and then wrap all kernel interfaces that
> > use those.
>
> Not clear on how rlimit is affected, but most of these definitely are.

I probably had it mixed up with rusage here.

       Arnd
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038

  parent reply	other threads:[~2019-01-18 16:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 19:41 Arnd Bergmann
2018-12-20  0:30 ` Rich Felker
2018-12-20 10:33   ` Szabolcs Nagy
2018-12-20 18:08     ` Rich Felker
2019-01-18 16:50 ` Arnd Bergmann [this message]
2019-01-18 19:48   ` A. Wilcox
2019-01-18 21:09     ` Arnd Bergmann
2019-01-18 17:06 ` Arnd Bergmann
2019-01-18 18:55   ` Rich Felker
2019-01-18 21:07     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a01TJ3ycbtJBGqTNi9VCGZ-CaAo48SSmE7HQP8gWzVCrA@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=adhemerval.zanella@linaro.org \
    --cc=dalias@libc.org \
    --cc=maxim.kuvyrkov@linaro.org \
    --cc=musl@lists.openwall.com \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).