From owner-freebsd-arch@FreeBSD.ORG Tue May 13 07:01:19 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD48D37B401 for ; Tue, 13 May 2003 07:01:18 -0700 (PDT) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51AC343F93 for ; Tue, 13 May 2003 07:01:18 -0700 (PDT) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id EC39C530E; Tue, 13 May 2003 16:01:16 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org From: Dag-Erling Smorgrav Date: Tue, 13 May 2003 16:01:15 +0200 Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: fsid_t X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 14:01:19 -0000 fsid_t is currently defined as a struct containing an array of two 32-bit ints: typedef struct fsid { int32_t val[2]; } fsid_t; /* filesystem id type */ which is ridiculous as the only place where this is actually useful is when it is initialized (val[0] is set to the udev_t and val[1] to the vfs type number) and this can easily be handled by a macro. The other significant use of fsid is to compare the fsids of two files to determine whether they are on the same fs; that would be far easier to do if fsid_t was defined as uint64_t. Are there any objections to making fsid_t a uint64_t? DES -- Dag-Erling Smorgrav - des@ofug.org