Date: Sat, 22 Nov 2014 10:12:54 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: RFC: patch to make d_fileno 64bits Message-ID: <201411221812.sAMICsv8016811@chez.mckusick.com> In-Reply-To: <20141122175531.GZ17068@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 22 Nov 2014 19:55:31 +0200 > From: Konstantin Belousov <kostikbel@gmail.com> > To: Kirk McKusick <mckusick@mckusick.com> > Cc: Rick Macklem <rmacklem@uoguelph.ca>, > FreeBSD Filesystems <freebsd-fs@freebsd.org> > Subject: Re: RFC: patch to make d_fileno 64bits > >> Do we have a way of versioning libc so that we can have the old version >> that provides the 32-bit version of the syscalls (156 and 196) along >> with 32-bit higher-level functions like fts and friends and then a new >> libc version that has the 64-bit version of the syscalls and other >> higher-level functions? > > We do not need several versions of libc. We support symbol versioning, > i.e. we can have old getdirents symbol which resolves to syscall stub > for 196, and new getdirents for new syscall. > > It is somewhat convoluted feature, you could look at example in > sys/kern/sysv_*.c, for instance, freebsd7_shmctl and shmctl. Also > look at libc/include/compat.h. For pure usermode compat shims, > lib/libc/gen/fts-compat.c was already handled one time. > > I promise to write neccessary magic for libc versioning when needed. > As I explained before, unfortunately the libc is not the final point > for the userspace compat. What more beyond libc do we need to handle? Things like fts is in libc. Are there other libraries besides libc that embed the size of an ino_t? Kirk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201411221812.sAMICsv8016811>