From owner-svn-src-all@FreeBSD.ORG Sun Nov 1 15:33:40 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1556106566C; Sun, 1 Nov 2009 15:33:40 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 824808FC0A; Sun, 1 Nov 2009 15:33:40 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 515981CF70; Sun, 1 Nov 2009 16:33:39 +0100 (CET) Date: Sun, 1 Nov 2009 16:33:39 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20091101153339.GH1293@hoeg.nl> References: <200910311035.n9VAZfIb082932@svn.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bina0ufSB9dLMnVr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r198706 - head/sys/sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 15:33:41 -0000 --Bina0ufSB9dLMnVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Robert, * Robert Watson wrote: > The underlying change seems fine, especially in -CURRENT, but I'm > confused by the paragraph here on alignment and safety. What do you > mean by safe, and does it matter? With safe I mean that all useful members still begin at the same offset within the structure. I'm not sure whether it matters at all, because I can imagine d_devs could be moved around without having any effect, but I'm not going to make any predictions on that. > From a casual glance (perhaps mistaken), it looks like this changes > the KBI, so all modules declaring struct cdevsw will need to be > rebuilt. It shouldn't, right? - uid_t d_uid; - gid_t d_gid; - mode_t d_mode; - const char *d_kind; + + int32_t d_spare0[3]; + void *d_spare1[3]; /* These fields should not be messed with by drivers */ - LIST_ENTRY(cdevsw) d_list; d_uid, d_gid and d_mode is equal to: int32_t d_uid; int32_t d_gid; int16_t d_mode; Because d_kind is a pointer, there will be a hole in the structure of at least 2 bytes (maybe even 6), which means we can safely extend d_mode to 32 bits as well. I could have decided to leave it at uint16_t, but that would only obfuscate it even more when we would try to reclaim some space there. d_list is just two pointers, so I merged it with d_kind into an array of three pointers. --=20 Ed Schouten WWW: http://80386.nl/ --Bina0ufSB9dLMnVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrtqlMACgkQ52SDGA2eCwUPBgCfXSx7mkhM4zu3hSCN+jcucGxC M38An0vDiD4tkSSbYUHnG4MEDC4FOyOT =K5yx -----END PGP SIGNATURE----- --Bina0ufSB9dLMnVr--