[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <775BBA28-BEDF-4F53-A845-D11F4337026B@dilger.ca>
Date: Tue, 3 Feb 2015 02:48:34 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: mtk.manpages@...il.com
Cc: Heinrich Schuchardt <xypron.glpk@....de>,
Ogawa Hirofumi <hirofumi@...l.parknet.co.jp>,
Linux Filesystem Development List
<linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-man <linux-man@...r.kernel.org>
Subject: Re: [PATCH v3 1/1] ioctl-fat.2: new manpage for the ioctl fat API
On Feb 3, 2015, at 2:21 AM, Michael Kerrisk (man-pages) <mtk.manpages@...il.com> wrote:
> On 3 February 2015 at 09:49, Andreas Dilger <adilger@...ger.ca> wrote:
>> On Jan 23, 2015, at 12:54 PM, Heinrich Schuchardt <xypron.glpk@....de> wrote:
>>> +The bits of the bit mask are
>>> +.TP
>>> +.B ATTR_RO
>>> +This bit specifies that the file or directory is read-only.
>>
>> It's too bad that these constants have such generic names. It would
>> be better to use MSDOS_ATTR_* or FAT_ATTR_*, since these are also
>> exposed to userspace, but are only used by FAT.
>
> Agreed. Too late now, I guess, though.
It wouldn't be unreasonable to #define FAT_ATTR_* versions of these
constants for use with new kernels, and eventually deprecate the
ATTR_* usage as older kernels become obsoleted. Once the FAT_ATTR_*
versions had been around for a year or three (enough for a major vendor
release cycle to get them into some large fraction of users hands) they
could start being documented in the man pages and the old versions
documented only for backward compatibility (as with old APIs like
strcpy(3) or mktemp(3)).
Given that FAT ioctls are not widely used by applications, the
actual ABI (numeric constants) isn't changing, and the workaround
is simple, I'd expect that the time before deprecating the old
constants could be fairly short.
Cheers, Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists