[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200710225934.GA16881@localhost>
Date: Fri, 10 Jul 2020 15:59:34 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>, alex.gaynor@...il.com,
Greg KH <gregkh@...uxfoundation.org>, geofft@...reload.com,
jbaublitz@...hat.com, Masahiro Yamada <masahiroy@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
keescook@...omium.org
Subject: Re: Linux kernel in-tree Rust support
On Fri, Jul 10, 2020 at 02:50:22PM +0200, Christian Brauner wrote:
> On Fri, Jul 10, 2020 at 08:28:03AM +0200, Greg KH wrote:
> > On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> > > Hello folks,
> > > I'm working on putting together an LLVM "Micro Conference" for the
> > > upcoming Linux Plumbers Conf
> > > (https://www.linuxplumbersconf.org/event/7/page/47-attend). It's not
> > > solidified yet, but I would really like to run a session on support
> > > for Rust "in tree." I suspect we could cover technical aspects of
> > > what that might look like (I have a prototype of that, was trivial to
> > > wire up KBuild support), but also a larger question of "should we do
> > > this?" or "how might we place limits on where this can be used?"
> > >
> > > Question to folks explicitly in To:, are you planning on attending plumbers?
> > >
> > > If so, would this be an interesting topic that you'd participate in?
> >
> > Yes, I'll be there.
>
> We actually had this dicussion a while back and there were some more
> people interested in this. I'd be interested to attend this and I've
> spoken with Kees and a few others about this topic at last Plumbers (I
> think Greg might have been around for this informal discussion as well.
> But I might be imagining things.).
I was around for one of the informal conversations with Greg and Kees
and others.
As I recall, Greg's biggest condition for initial introduction of this
was to do the same kind of "turn this Kconfig option on and turn an
option under it off" trick that LTO uses, so that neither "make
allnoconfig" nor "make allyesconfig" would require Rust until we've had
plenty of time to experiment with it. And that seems entirely
reasonable to me too.
- Josh
Powered by blists - more mailing lists