linux-kernel - Re: [PATCH V3 1/6] stm class: Add ioctl get

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: <CANLsYkzQTjROVX3K3NEE=GNg6QVKXLA9QDLVDe+W9eeDVwbgGQ@mail.gmail.com>
Date:	Fri, 12 Feb 2016 11:33:17 -0700
From:	Mathieu Poirier <mathieu.poirier@...aro.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Chunyan Zhang <zhang.chunyan@...aro.org>,
	Mike Leach <mike.leach@....com>,
	Michael Williams <Michael.Williams@....com>,
	Al Grant <al.grant@....com>, "Jeremiassen, Tor" <tor@...com>,
	Nicolas GUION <nicolas.guion@...com>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Pratik Patel <pratikp@...eaurora.org>,
	Jon Corbet <corbet@....net>,
	Mark Rutland <mark.rutland@....com>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, linux-api@...r.kernel.org,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH V3 1/6] stm class: Add ioctl get_options interface

On 12 February 2016 at 08:18, Alexander Shishkin
<alexander.shishkin@...ux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan@...aro.org> writes:
>
>> There is already an interface of set_options, but no get_options yet.
>> Before setting any options, one would may want to see the current
>> status of that option by means of get_options interface. This
>> interface has been used in CoreSight STM driver.
>
> I'm not sure I understand the reasoning behind this. If a userspace
> program opens a communication channel and wants to configure certain
> features on it, why does its choice depend on what has been configured
> for this channel previously? It can be anything at all. Most likely,
> it's either unconfigured or configured to its default values, but why
> does this matter for a new writer?

A client may wish to change the settings (invariant/guaranteed) it has
on a specific channel - it may even want to so do multiple times.  The
idea behind introducing a get_options() was to probe the specific
settings of a channel before going a head with a new configuration.
In hindsight it may not be needed as a client should simply go ahead
and push down the configuration it wants.

>
> Regards,
> --
> Alex