From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC PATCH] vfs: Use 12:20 bit major:minor in stat everywhere Date: Wed, 4 Mar 2015 00:53:47 +0000 Message-ID: <20150304005347.GU29656@ZenIV.linux.org.uk> References: <1425429420-13142-1-git-send-email-dehrenberg@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, gwendal@chromium.org, ezequiel@vanguardiasur.com.ar To: Dan Ehrenberg Return-path: Content-Disposition: inline In-Reply-To: <1425429420-13142-1-git-send-email-dehrenberg@chromium.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Mar 03, 2015 at 04:37:00PM -0800, Dan Ehrenberg wrote: > Previously, stat on 32-bit platforms used old-style encoding and > validation of major-minor pairs, with 8:8 bits. However, dev_t is > 32-bits on these platforms, and coreutils seems to be treating the > values as 12:20 new-style values. The only reason to use the old > version is in the implementation of a legacy filesystem format which > only has 16 bits of space. Communicating a 12:20 value to userspace > when sizeof dev_t == 4 can be done on either a 32-bit or 64-bit > platform. > > This patch removes the artificial restriction in major:minor size. > The only backwards incompatibility which results is sometimes stat > succeeds if -EOVERFLOW would be returned otherwise. The legacy > old-style stat call is retained as-is. Umm... You do realize that coreutils are _very_ far from being the only userland programs handling the data returned by stat(2), right? What's to guarantee that your ABI change won't break any of those?