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, 5 Apr 2023 17:40:39 -0300
From:   Wedson Almeida Filho <wedsonaf@gmail.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>,
        =?iso-8859-1?Q?Bj=F6rn?= Roy Baron <bjorn3_gh@protonmail.com>,
        linux-kernel@vger.kernel.org,
        Wedson Almeida Filho <walmeida@microsoft.com>,
        Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
        Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v2 03/13] rust: lock: introduce `Mutex`
Message-ID: <ZC3cxzpnrnXf/osU@wedsonaf-dev>
References: <20230405175111.5974-1-wedsonaf@gmail.com>
 <20230405175111.5974-3-wedsonaf@gmail.com>
 <2023040554-promoter-chevron-10b2@gregkh>
 <2023040509-tamer-clinic-c14c@gregkh>
 <20230405191826.GA365912@hirez.programming.kicks-ass.net>
 <ZC3YWLmIick4jSSv@wedsonaf-dev>
 <20230405202932.GG365912@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230405202932.GG365912@hirez.programming.kicks-ass.net>
Precedence: bulk

On Wed, Apr 05, 2023 at 10:29:32PM +0200, Peter Zijlstra wrote:
> On Wed, Apr 05, 2023 at 05:21:44PM -0300, Wedson Almeida Filho wrote:
> > On Wed, Apr 05, 2023 at 09:18:26PM +0200, Peter Zijlstra wrote:
> > > On Wed, Apr 05, 2023 at 08:04:22PM +0200, Greg KH wrote:
> > > > On Wed, Apr 05, 2023 at 08:03:11PM +0200, Greg KH wrote:
> > > > > On Wed, Apr 05, 2023 at 02:51:01PM -0300, Wedson Almeida Filho wrote:
> > > > > > +void rust_helper_mutex_lock(struct mutex *lock)
> > > > > > +{
> > > > > > +	mutex_lock(lock);
> > > > > > +}
> > > > > > +EXPORT_SYMBOL_GPL(rust_helper_mutex_lock);
> > > > > > +
> > > > > 
> > > > > No need to ever unlock a mutex?
> > > > 
> > > > Oh nevermind, mutex_lock() is a macro, mutex_unlock() is not...
> > > 
> > > Yeah, so I despise all these stupid helpers... but I suppose it's the
> > > best they could come up with to interface the languages :/
> > > 
> > > The only hope is that the thing can do cross-language LTO or something
> > > to re-inline stuff.
> > 
> > One thing we could to do improve the situation is to convert some of the
> > existing macros into inline functions on the header files.
> > 
> > We can't do it for all cases (e.g., cases like mutex_init that declare a new
> > static variable when lockdep is enabled) but mutex_lock is just a function
> > when lockdep is disabled, and just calls mutex_lock_nested() when it is enabled.
> > 
> > How do you feel about this?
> > 
> > -#define mutex_lock(lock) mutex_lock_nested(lock, 0)
> > +static inline void mutex_lock(struct mutex *lock)
> > +{
> > +       mutex_lock_nested(lock, 0);
> > +}
> 
> Can rust actually parse C headers and inline C functions ? I thought the
> whole problem was that it can only call C ABI symbols (which inline
> functions are not).

Rust can't. We use a tool called bindgen to read C header files and generate
equivalent Rust (extern "C") declarations for functions. The tool has been
enhanced recently (https://github.com/rust-lang/rust-bindgen/pull/2335) to
handle static inline functions by automatically generating helpers like the one
above (in addition to the Rust decls).

So the situation is improved in that we don't need to manually write (and
commit) the helpers. It may improve further in the future if we get better
integration of the languages.