linux-kernel - Re: [PATCH] rust: macros: add authors

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: <20241206211905.444952-1-trintaeoitogc@gmail.com>
Date: Fri,  6 Dec 2024 18:19:05 -0300
From: guilherme giacomo simoes <trintaeoitogc@...il.com>
To: miguel.ojeda.sandonis@...il.com
Cc: a.hindborg@...nel.org,
	alex.gaynor@...il.com,
	aliceryhl@...gle.com,
	benno.lossin@...ton.me,
	bjorn3_gh@...tonmail.com,
	boqun.feng@...il.com,
	fujita.tomonori@...il.com,
	gary@...yguo.net,
	linux-kernel@...r.kernel.org,
	ojeda@...nel.org,
	rust-for-linux@...r.kernel.org,
	tahbertschinger@...il.com,
	tmgross@...ch.edu,
	trintaeoitogc@...il.com,
	walmeida@...rosoft.com,
	wcampbell1995@...il.com
Subject: Re: [PATCH] rust: macros: add authors

Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrotes: 
> There are several ways we could do this:
> 
>   - A single field, that only accepts a list.
> 
>   - A single field that accepts both a string or a list.
> 
>   - Two fields like this (that cannot coexist).
> 
>   - Accepting several "author" fields and append them all into a list.

I maked this change like this way because in my thoughts I just thought about:
- A single field, that only accepts a list.
- Two fields (author and authors).

And how in the first option I would need found all modules that have the author
tags and I would need change the code (from `author: "author"` to `author:
["author"])`, I was think that is the best don't change in a thing that is
already work well. And this is why I choose the second option "Two field". And
if the new developers need include two or more authors, he can make this since
now.

But now, that you put the option "A single field that accepts both a string or
a list" for me this make sense too. I think that the A single field that
accepts both a string  or a list, and two fields (author and authors) is the
two best options. 
I don't like the options:
- A single field, that only accepts a list. 
Because we need found all module
that use the author and change his implementation.

- Accepting several "author" fields and append them all into a list. 
because in the modules the developers would need a several author field if the 
module is development for several author. And the module! macro would grow a lot. 
Like:
  author: guilherme, 
  author: miguel, 
  author: another_poor_developer, 
  .... 


> > -        for alias in aliases {
> > -            modinfo.emit("alias", &alias);
> > -        }
> > +        modinfo.emit_arr_str("alias", &aliases);
> 
> Spurious change? Or am I missing something?
I make this change because, the for() would need repeat for the alias and for
the authors and for avoid unnecessary code repetition I create the
emit_arr_str() function.

> In addition, there was a PR [1] by Wayne (Cc'd) that implemented the first
> approach, but it was never sent to the list. I pinged in the GitHub issue
> too.
.. 
> Also, this patch should update the documentation of the macro.
About this, I will sent a v2 PATCH with this informations