rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>
Cc: FUJITA Tomonori <fujita.tomonori@gmail.com>,
	netdev@vger.kernel.org, rust-for-linux@vger.kernel.org,
	hkallweit1@gmail.com, tmgross@umich.edu, ojeda@kernel.org,
	alex.gaynor@gmail.com, gary@garyguo.net,
	bjorn3_gh@protonmail.com, benno.lossin@proton.me,
	a.hindborg@samsung.com, aliceryhl@google.com,
	Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [PATCH net-next v1 1/2] rust: add delay abstraction
Date: Wed, 02 Oct 2024 22:04:00 +0200	[thread overview]
Message-ID: <878qv6w9u7.ffs@tglx> (raw)
In-Reply-To: <CANiq72nCeGVFY_eZMhp44dqZGY1UXuEZFaJx-3OLCTk-eG=xng@mail.gmail.com>

On Wed, Oct 02 2024 at 15:21, Miguel Ojeda wrote:
> On Wed, Oct 2, 2024 at 2:51 PM Andrew Lunn <andrew@lunn.ch> wrote:
>> Maybe this is my background as a C programmer, with its sloppy type
>> system, but i prefer to have this very clear, maybe redundantly
>> stating it in words in addition to the signature.
>
> The second part of my message was about the signature point you made,
> i.e. not about the units. So I am not sure if you are asking here to
> re-state the types of parameters in every function's docs -- what do
> you gain from that in common cases?
>
> We also don't repeat every parameter in a bullet list inside the
> documentation to explain each parameter, unless a parameter needs it
> for a particular reason. In general, the stronger/stricter your
> types/signatures are, and the better documented your types are, the
> less "extra notes" in every function you need.
>
> For instance, if you see `int` in a signature, then you very likely
> need documentation to understand how the argument works because `int`
> is way too general (e.g. it is likely it admits cases you are not
> supposed to use). However, if you see `Duration`, then you already
> know the answer to the units question.
>
> Thus, in a way, we are factoring out documentation to a single place,
> thus making them simpler/easier/lighter -- so you can see it as a way
> to scale writing docs! :)
>
> That is also why carrying as much information in the signature also
> helps with docs, and not just with having the compiler catch mistakes
> for us.

I completely agree.

'delay(Duration d)' does not need explanation for @d unless there is a
restriction for the valid range of @d. @d is explained in the
documentation of Duration.

That's not any different in C, when the function argument is a pointer
to a complex struct. Nobody would even think about explaining the struct
members in the documentation of the function which has that struct
pointer argument. No, you need to go to the struct declaration to figure
it out.

Redundant documentation is actually bad, because any changes to the type
will inevitably lead to stale documentation at the usage site. The
kernel is full of this.

I havent's seen the actual patches as they were sent to netdev for
whatever reason. There is a larger rework of delay.h going on:

  https://lore.kernel.org/all/20240911-devel-anna-maria-b4-timers-flseep-v2-0-b0d3f33ccfe0@linutronix.de/

V3 will be coming early next week. So please look at V2 if you have any
constraints vs. the rust implementation.

Thanks,

        tglx



  reply	other threads:[~2024-10-02 20:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-01 11:25 [PATCH net-next v1 0/2] add delay abstraction (sleep functions) FUJITA Tomonori
2024-10-01 11:25 ` [PATCH net-next v1 1/2] rust: add delay abstraction FUJITA Tomonori
2024-10-01 11:33   ` Alice Ryhl
2024-10-01 12:31   ` Andrew Lunn
2024-10-01 15:08     ` Miguel Ojeda
2024-10-02 11:34     ` FUJITA Tomonori
2024-10-02 12:18       ` Andrew Lunn
2024-10-02 12:35         ` Miguel Ojeda
2024-10-02 12:51           ` Andrew Lunn
2024-10-02 13:21             ` Miguel Ojeda
2024-10-02 20:04               ` Thomas Gleixner [this message]
2024-10-02 12:37         ` Alice Ryhl
2024-10-02 13:58           ` FUJITA Tomonori
2024-10-02 14:27             ` Alice Ryhl
2024-10-02 14:40               ` FUJITA Tomonori
2024-10-02 14:52                 ` Miguel Ojeda
2024-10-02 19:40                   ` Thomas Gleixner
2024-10-03  1:24                     ` FUJITA Tomonori
2024-10-03 10:50                       ` Miguel Ojeda
2024-10-03 12:33                         ` Andrew Lunn
2024-10-04 12:08     ` FUJITA Tomonori
2024-10-04 14:08       ` Andrew Lunn
2024-10-01 11:25 ` [PATCH net-next v1 2/2] net: phy: qt2025: wait until PHY becomes ready FUJITA Tomonori
2024-10-01 11:36   ` Alice Ryhl
2024-10-01 12:48     ` Andrew Lunn
2024-10-02  4:39       ` iopoll abstraction (was: Re: [PATCH net-next v1 2/2] net: phy: qt2025: wait until PHY becomes ready) Dirk Behme
2024-10-02  9:56         ` iopoll abstraction FUJITA Tomonori
2024-10-03 11:52           ` Boqun Feng
2024-10-03 13:45             ` FUJITA Tomonori
2024-10-03 14:25               ` Boqun Feng
2024-10-03 16:00                 ` Andrew Lunn
2024-10-04 11:54                   ` FUJITA Tomonori
2024-10-03 16:09                 ` Andrew Lunn
2024-10-04 11:48                   ` FUJITA Tomonori
2024-10-04 13:37                     ` Andrew Lunn
2024-10-02 10:13       ` [PATCH net-next v1 2/2] net: phy: qt2025: wait until PHY becomes ready FUJITA Tomonori
2024-10-02 12:31         ` Andrew Lunn
2024-10-03  5:07           ` FUJITA Tomonori
2024-10-02 11:17     ` FUJITA Tomonori
2024-10-01 11:39 ` [PATCH net-next v1 0/2] add delay abstraction (sleep functions) Alice Ryhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878qv6w9u7.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=a.hindborg@samsung.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=andrew@lunn.ch \
    --cc=anna-maria@linutronix.de \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=fujita.tomonori@gmail.com \
    --cc=gary@garyguo.net \
    --cc=hkallweit1@gmail.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).