From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14467 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Final (?) time64 proposal Date: Mon, 29 Jul 2019 17:11:54 -0400 Message-ID: <20190729211154.GV1506@brightrain.aerifal.cx> References: <20190724053142.GB1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="178392"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14483-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 29 23:12:12 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.89) (envelope-from ) id 1hsCwE-000kH8-6W for gllmg-musl@m.gmane.org; Mon, 29 Jul 2019 23:12:10 +0200 Original-Received: (qmail 8011 invoked by uid 550); 29 Jul 2019 21:12: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 7992 invoked from network); 29 Jul 2019 21:12:06 -0000 Content-Disposition: inline In-Reply-To: <20190724053142.GB1506@brightrain.aerifal.cx> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14467 Archived-At: 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