From owner-freebsd-fs@FreeBSD.ORG Sat Nov 22 17:23:51 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 A0FC26F5 for ; Sat, 22 Nov 2014 17:23:51 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (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 81C65B96 for ; Sat, 22 Nov 2014 17:23:51 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id sAMHNfs6005778; Sat, 22 Nov 2014 09:23:41 -0800 (PST) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201411221723.sAMHNfs6005778@chez.mckusick.com> To: Konstantin Belousov Subject: Re: RFC: patch to make d_fileno 64bits In-reply-to: <20141122153427.GW17068@kib.kiev.ua> Date: Sat, 22 Nov 2014 09:23:41 -0800 From: Kirk McKusick 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 17:23:51 -0000 > Date: Sat, 22 Nov 2014 17:34:27 +0200 > From: Konstantin Belousov > To: Rick Macklem > Subject: Re: RFC: patch to make d_fileno 64bits > Cc: FreeBSD Filesystems > > On Fri, Nov 21, 2014 at 06:45:52PM -0500, Rick Macklem wrote: >> Kostik wrote: >> What about old binaries that do getdirentries(2) and expect the old >> structure with 32bit d_fileno or the linux compatibility stuff? >> I suspect that there are some old staticly linked binaries out there >> that does/expects the old getdirentries. > > No, let me restate my position. There are two places for backward > compatibility, one is in-kernel binary interface, and another is > applications ,i.e. KBI and ABI. > > My opinion is that we must provide strict backward ABI compatibility > to have even right to be called useful OS. In particular, the syscalls > like current getdirentries (156 and 196) providing 32-bit inonums, must > be kept with their current binary contract. The userspace issues do > not end there, but this is not the currently discussed item. > > On the other hand, providing KBI compat for filesystems which work > right now with 32bit inode numbers, should not be done. I.e., no > VOP_READDIR_32INO(), all filesystems must be converted once. > > For syscalls 156 and 196 (and some more), the converter must be written > in the vfs_syscalls.c which translates the new dirents into old dirents, > at the level of best efforts. I believe that we are all in agreement with you on the kernel approach at this point. 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? Kirk