lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ