[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 18 Jan 2019 17:50:50 +0100
From: Arnd Bergmann <arnd@...db.de>
To: musl@...ts.openwall.com, y2038 Mailman List <y2038@...ts.linaro.org>
Cc: Rich Felker <dalias@...c.org>, Adhemerval Zanella <adhemerval.zanella@...aro.org>,
Maxim Kuvyrkov <maxim.kuvyrkov@...aro.org>
Subject: Re: Data structures defined by both linux and musl
(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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
