[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de725f08-2f98-56fc-8305-baf93f867af3@acm.org>
Date: Thu, 9 Dec 2021 16:02:07 -0800
From: Bart Van Assche <bvanassche@....org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-api@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-mmc@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH v3 3/3] blk-crypto: show crypto capabilities in sysfs
On 12/9/21 3:40 PM, Eric Biggers wrote:
> On Thu, Dec 09, 2021 at 02:51:59PM -0800, Bart Van Assche wrote:
>> Has it been considered to report each value separately, e.g. 512\n4096\n
>> instead of 0x1200\n? I think the former approach is more friendly for shell
>> scripts.
>
> I don't think that would be acceptable to the sysfs folks, as they only allow
> one value per file. I suppose a bitmask could be viewed as unacceptable too,
> but it seemed to make sense here, given that the data unit sizes are always
> powers of 2, and the hardware reports them as bitmasks.
In case Greg wouldn't have the time to reply, I think the following quote from
Documentation/filesystems/sysfs.txt is relevant in this context: "Attributes
should be ASCII text files, preferably with only one value per file. It is
noted that it may not be efficient to contain only one value per file, so it is
socially acceptable to express an array of values of the same type."
Thanks,
Bart.
Powered by blists - more mailing lists