[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190729211154.GV1506@brightrain.aerifal.cx>
Date: Mon, 29 Jul 2019 17:11:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Final (?) time64 proposal
On Wed, Jul 24, 2019 at 01:31:42AM -0400, Rich Felker wrote:
> My plan to go ahead looks like:
>
> [...]
> - struct shmid_ds, msqid_ds, semid_ds layout kept, extended with
> 64-bit time_t's on the ends
This looks like the unnecessarily painful course of action. I worked
out a grid of all the existing archs' quirks, and except for mips and
mipsn32, all archs admit a solution that's just endian-swapping the
time_t members in-place.
The mips awfulness is isolated to shmid_ds and semid_ds (not affecting
msqid_ds). It's only shmid_ds where 64-bit time_t actually _doesn't
fit_ in the existing structure (the kernel limits high bits to 16-bit
so it can pack them in the limited available unused space). For
semid_ds, the space is there but it just requires moving one of the
two time_t's.
My leaning is to just do the endian-swap as needed (whether it's
needed varies by arch, so syscall_arch.h will need to define it) and
make some mechanism whereby mips can provide its own hideous thing to
do instead. For semid_ds, that's probably going to be:
otime = sem_otime & 0xffffffff | (sem_ctime & 0xfffffff)<<32;
ctime = sem_otime>>32 | sem_ctime & 0xffffffff00000000;
sem_otime = otime;
sem_ctime = ctime;
and for shmid_ds, it will probably just be adding 3 new time_t's to
the end.
Note that there's some tradeoff here between ugliness of the internal
code in libc to do the transformations, and ugliness of the public
interface (the structure definitions). I'd really like the public
interface to be what's clean and simple. If I do it this way, it can
be, everywhere but mips, and in fact almost all of the arch-specific
sem.h and shm.h variants for 32-bit archs collapse down to being
identical to the variant common to 64-bit archs.
> - new definitions of IPC_STAT, SHM_STAT, SHM_STAT_ANY, SEM_STAT,
> SEM_STAT_ANY, MSG_STAT, and MSG_STAT_ANY to expand the shmid_ds,
> semid_ds, and msqid_ds upper and lower time bits from their
> locations in the kernel struct to the new fields at the end.
I'm still undecided on whether this is better than just wrapping them.
If I go with the above approach for struct layouts, then the generic
compat shims just have to endian-swap the hi/lo 32-bit words of the
time_t fields back -- and copy through a temp object, then memcpy,
since the caller's object may not be aligned suitably for accessing
64-bit types in-place. Then mips and mipsn32 would have to provide a
custom arch-specific version of the wrappers that, for semctl, invert
the above transformation, and for shmctl, just memcpy a truncated
structure (leaving the undersized fields from the kernel in-place).
If I go with the new definitions of IPC_STAT, etc., no compat shims or
symbols redirection are needed for ipc *ctl functions (but note:
semtimedop already has a redirection needed, so sys/sem.h will be
aware of them anyway), and it's easy to do the conversions for 64-bit
time_t only if the new cmd numbers are used; it doesn't even need to
be aware of specific commands, just a special bit for "do conversion".
But it does consume a bit of the command number.
Not sure which is more/less ugly...
Rich
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.
