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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cbwamjer2rupkmyze6atgpkrszajcbhw2udb23ldl73ne3m6qr@jjs7q3codtx5>
Date: Fri, 21 Jun 2024 01:38:33 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Easwar Hariharan <eahariha@...ux.microsoft.com>, linux-i2c@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/6] docs: i2c: summary: document 'local' and 'remote'
 targets

Hi Wolfram,

On Wed, Jun 19, 2024 at 09:10:26AM GMT, Wolfram Sang wrote:
> > > "Synonyms" from patch 6 does say that controller/target is preferred but
> > > couched it in the caveat "If speaking about I2C in general" and
> > > adapter/client when "discuss[ing] implementation details." I was trying
> > > to give space for an unambiguous recommendation.
> > 
> > Exactly, this is what I referred to in my previous e-mails.
> > These two statements sound a bit ambiguous to me, as well.
> 
> Okay, here is my proposed update:
> 
> ===
> 
> diff --git a/Documentation/i2c/summary.rst b/Documentation/i2c/summary.rst
> index 90f46f1504fe..579a1c7df200 100644
> --- a/Documentation/i2c/summary.rst
> +++ b/Documentation/i2c/summary.rst
> @@ -67,9 +67,9 @@ Synonyms
>  
>  As mentioned above, the Linux I2C implementation historically uses the terms
>  "adapter" for controller and "client" for target. A number of data structures
> -have these synonyms in their name. So, to discuss implementation details, it
> -might be easier to use these terms. If speaking about I2C in general, the
> -official terminology is preferred.
> +have these synonyms in their name. So, when discussing implementation details,
> +you should be aware of these terms as well. The official wording is preferred,
> +though.

ACK!

> ===
> 
> I don't want to be stricter than "preferred". If someone still wants to
> use 'struct i2c_client *client' this is fine with me.

Sure, let's see how it goes.

> > Maybe we are wasting time at discussing minor details, but I
> > consider this part important in order to give way to the major
> > refactoring that Wolfram started at the beginning.
> 
> The refactoring only affects "master/slave" not "adapter/client". We are
> 
> aligned here, aren't we?

Yes, of course. And I'm not really asking for the totality of the
"client"'s to be replaced, rather than, when replacing slave, to
choose "target" over "client" whenever possible(*).

Thanks, Wolfram,

Andi

(*) E.g. if in a file "client" is used a lot, doesn't make sense
    to go against the trend and use "target".

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ