From owner-freebsd-fs@FreeBSD.ORG Sat Nov 22 18:44:11 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62B41A0 for ; Sat, 22 Nov 2014 18:44:11 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E471B390 for ; Sat, 22 Nov 2014 18:44:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAMIi5Mg009645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Nov 2014 20:44:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAMIi5Mg009645 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAMIi5lO009644; Sat, 22 Nov 2014 20:44:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Nov 2014 20:44:05 +0200 From: Konstantin Belousov To: Kirk McKusick Subject: Re: RFC: patch to make d_fileno 64bits Message-ID: <20141122184405.GC17068@kib.kiev.ua> References: <20141122175531.GZ17068@kib.kiev.ua> <201411221812.sAMICsv8016811@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201411221812.sAMICsv8016811@chez.mckusick.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 18:44:11 -0000 On Sat, Nov 22, 2014 at 10:12:54AM -0800, Kirk McKusick wrote: > > Date: Sat, 22 Nov 2014 19:55:31 +0200 > > From: Konstantin Belousov > > To: Kirk McKusick > > Cc: Rick Macklem , > > FreeBSD Filesystems > > 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? Answering the question is part of the project. Scientific method to look at this is to do two builds of the world with the debugging information enabled, one stock, and one with the ino_t changed to 64bit. Then, tools like abi-compliance-checker or some set of scripts we have somewhere in tree (I do not remember exactly), can compare the dwarf definitions of the structures. This will provide the definitive answer to the question. General feeling is that a lot should be affected, since struct stat includes inode number. Quick look at the sources picks up references to ino_t in libarchive, libprocstat, libufs external interfaces.