rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wedson Almeida Filho <wedsonaf@google.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: rust-for-linux@vger.kernel.org
Subject: Re: File operations
Date: Sun, 13 Dec 2020 00:01:16 +0000	[thread overview]
Message-ID: <CAMKQLN++0y2fVHNJhthemZ4BhQCAqXyFygj-jACZQnqfFBmkbg@mail.gmail.com> (raw)
In-Reply-To: <CANiq72maQNCGT=ff9BrsqY81mXjzeYpKxDy9rZL36cmgfCZt-w@mail.gmail.com>

On Wed, 9 Dec 2020 at 23:18, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> Not sure... On one hand the first snippet looks very cumbersome; on
> the other hand, introducing a macro for just a line may not be over
> the threshold of "is this sugar worth enough?".

It will be several lines considering that we will have several of
these functions, but as you yourself mention in the next paragraph, I
don't think this is the main point of the macro, it's a reduction in
the boilerplate and making functions exactly the same as any other.

> The macro makes the fileops functions look more normal, so I think it
> would be fine, but don't spend too much time on that if you feel it
> gets too convoluted: we will likely know how much macro magic people
> enjoy if we end up being successful in introducing Rust in the kernel
> :-)

The macro would get the names of all functions implemented in a given
`impl` block and add another `impl` block with the same names as
booleans set the true. Not too complicated, but it would be better f
we could find a simpler solution.

> Nevertheless, however you do it, having actual non-trivial drivers
> implemented is a *very* nice thing!

Yes, that's what I am working towards. If the non-trivial driver is
filled with function declarations like those though, wrapped in
`Option`s and closures, I think it may be tougher sell.

Cheers,
-Wedson

  reply	other threads:[~2020-12-13  0:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 21:47 File operations Wedson Almeida Filho
2020-12-09 23:18 ` Miguel Ojeda
2020-12-13  0:01   ` Wedson Almeida Filho [this message]
2020-12-13  0:50     ` Miguel Ojeda
2020-12-13  2:12       ` Wedson Almeida Filho
2020-12-13  3:33         ` Miguel Ojeda
2020-12-14  2:02           ` Wedson Almeida Filho
2020-12-18  3:58             ` Miguel Ojeda

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=CAMKQLN++0y2fVHNJhthemZ4BhQCAqXyFygj-jACZQnqfFBmkbg@mail.gmail.com \
    --to=wedsonaf@google.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=rust-for-linux@vger.kernel.org \
    /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).