Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 21 Sep 2022 14:23:42 +0300
From:   Konstantin Shelekhin <k.shelekhin@yadro.com>
To:     Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
CC:     <ojeda@kernel.org>, <alex.gaynor@gmail.com>, <ark.email@gmail.com>,
        <bjorn3_gh@protonmail.com>, <bobo1239@web.de>,
        <bonifaido@gmail.com>, <boqun.feng@gmail.com>,
        <davidgow@google.com>, <dev@niklasmohrin.de>,
        <dsosnowski@dsosnowski.pl>, <foxhlchen@gmail.com>,
        <gary@garyguo.net>, <geofft@ldpreload.com>,
        <gregkh@linuxfoundation.org>, <jarkko@kernel.org>,
        <john.m.baublitz@gmail.com>, <leseulartichaut@gmail.com>,
        <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <m.falkowski@samsung.com>, <me@kloenk.de>, <milan@mdaverde.com>,
        <mjmouse9999@gmail.com>, <patches@lists.linux.dev>,
        <rust-for-linux@vger.kernel.org>, <thesven73@gmail.com>,
        <torvalds@linux-foundation.org>, <viktor@v-gar.de>,
        <wedsonaf@google.com>, Andreas Hindborg <andreas.hindborg@wdc.com>
Subject: Re: [PATCH v9 12/27] rust: add `kernel` crate
Message-ID: <Yyr0PmHaxvJ0r4hm@yadro.com>
References: <20220805154231.31257-13-ojeda@kernel.org>
 <Yu5Bex9zU6KJpcEm@yadro.com>
 <CANiq72=3j2NM2kS8iw14G6MnGirb0=O6XQyCsY9vVgsZ1DfLaQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANiq72=3j2NM2kS8iw14G6MnGirb0=O6XQyCsY9vVgsZ1DfLaQ@mail.gmail.com>
Precedence: bulk

On Sat, Aug 06, 2022 at 01:22:52PM +0200, Miguel Ojeda wrote:
> On Sat, Aug 6, 2022 at 12:25 PM Konstantin Shelekhin
> <k.shelekhin@yadro.com> wrote:
> >
> > I sense possible problems here. It's common for a kernel code to pass
> > flags during memory allocations.
> 
> Yes, of course. We will support this, but how exactly it will look
> like, to what extent upstream Rust's `alloc` could support our use
> cases, etc. has been on discussion for a long time.
> 
> For instance, see https://github.com/Rust-for-Linux/linux/pull/815 for
> a potential extension trait approach with no allocator carried on the
> type that Andreas wrote after a discussion in the last informal call:
> 
>     let a = Box::try_new_atomic(101)?;

In my opinion, the rest of the thread clearly shows that the
conservative approach is currently the only solid option. I suggest the
following explicit API:

  let a = Box::try_new(size, flags)?;
  Vec::try_push(item, flags)?;

etc. Whadda you think?