On Thu, Dec 17, 2020 at 10:45 PM Pavel Machek wrote:
>
> Well.. not everyone has 32 cores in their notebook.
It is true that complex Rust, like complex C++, does have high
compilation times. But it all depends on how much one relies on
certain language features. Straightforward Rust code is quick
On Tue 2020-07-28 23:34:17, Josh Triplett wrote:
> On Tue, Jul 28, 2020 at 10:40:38PM +0200, Pavel Machek wrote:
> > > We just need to make sure that any kernel CI infrastructure tests that
> > > right away, then, so that failures don't get introduced by a patch from
> > > someone without a Rust to
On Mon, 24 Aug 2020, Adrian Bunk wrote:
In librsvg, breakages with more recent Rust versions in the past year
required updates of two vendored crates:
Interesting!
https://gitlab.gnome.org/GNOME/librsvg/-/commit/de26c4d8b192ed0224e6d38f54e429838608b902
Looks like this was, for a while, a w
On Sun, Jul 12, 2020 at 12:39:44PM -0700, Josh Triplett wrote:
>...
> Rust has hard stability guarantees when upgrading from one stable
> version to the next. If code compiles with a given stable version of
> Rust, it'll compile with a newer stable version of Rust.
>...
In librsvg, breakages with
On Tue, Jul 28, 2020 at 10:40:38PM +0200, Pavel Machek wrote:
> > We just need to make sure that any kernel CI infrastructure tests that
> > right away, then, so that failures don't get introduced by a patch from
> > someone without a Rust toolchain and not noticed until someone with a
> > Rust too
Hi!
> > No, please make it a "is rust available" automatic config option. The
> > exact same way we already do the compiler versions and check for
> > various availability of compiler flags at config time.
>
> That sounds even better, and will definitely allow for more testing.
>
> We just need
From: Adrian Bunk
> Sent: 19 July 2020 19:19
...
> The correct range for a mandatory tool are the 6 to 12 years for gcc.
>
> Debian stable and Ubuntu LTS are providing (different) mechanisms
> for installing the kernel from the next stable/LTS release 2 years
> later[1] for supporting new hardware
On Thu, Jul 16, 2020 at 03:06:01PM +0200, Arnd Bergmann wrote:
>
> I would expect we'd want a fairly tight coupling between kernel
> releases and minimum rust releases at first. Whatever is the latest
> stable rust version during the kernel's merge window might be
> assumed to be the minimum versi
On Thu, Jul 16, 2020 at 03:06:01PM +0200, Arnd Bergmann wrote:
> On Sun, Jul 12, 2020 at 9:39 PM Josh Triplett wrote:
> > On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> > >
> > > As an example:
> > > Ubuntu LTS releases upgrade to a new Rust version every 1-2 months.
> > > Ubuntu 1
On Sun, Jul 12, 2020 at 9:39 PM Josh Triplett wrote:
> On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> >
> > As an example:
> > Ubuntu LTS releases upgrade to a new Rust version every 1-2 months.
> > Ubuntu 16.04 started with Rust 1.7.0 and is now at Rust 1.41.0.
> >
> > It would no
From: Adrian Bunk
> Sent: 12 July 2020 21:45
> Rust gets updated frequently.
> Sometimes this also changes the LLVM version used by Rust.
> Debian stable supports targets like ARMv5 and 32bit MIPS.
> Distribution kernel updates are often automatically installed
> on user hardware.
This remind
On Mon, Jul 13, 2020 at 01:11:13PM -0500, Eric W. Biederman wrote:
> Nick Desaulniers writes:
>
> > 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
> > so
Nick Desaulniers writes:
> 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
On Sun, Jul 12, 2020 at 12:39:44PM -0700, Josh Triplett wrote:
> On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> > On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> > >...
> > > but also a larger question of "should we do
> > > this?" or "how might we place limits o
On Sun, Jul 12, 2020 at 12:39 PM Josh Triplett wrote:
>
> Rust has hard stability guarantees when upgrading from one stable
> version to the next.
I think the worry is more about actual compiler bugs, not the set of
exposed features.
That's always been the biggest pain point. Compiler bugs are v
On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> >...
> > but also a larger question of "should we do
> > this?" or "how might we place limits on where this can be used?"
> >...
>
> I won't attend, but I do have a to
On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
>...
> but also a larger question of "should we do
> this?" or "how might we place limits on where this can be used?"
>...
I won't attend, but I do have a topic that should be covered:
Firefox always depends on recent Rust, which f
On Fri, Jul 10, 2020 at 04:54:11PM -0700, Linus Torvalds wrote:
> On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett wrote:
> > 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 t
On Thu, 9 Jul 2020, 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 R
On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett wrote:
>
> 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 allyescon
On Fri, Jul 10, 2020 at 12:28:30PM -0400, Alex Gaynor wrote:
> :wave:,
>
> Hey Kees, that's Geoffrey Thomas and I, we're both on this thread :-)
*face palm* Hello! I swear I can read. Though perhaps not well enough
before lunch. :)
--
Kees Cook
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
> > > upcom
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
> > > upcom
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/4
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 r
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 r
Hi Nick,
On Thu, Jul 9, 2020 at 8:42 PM 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
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 techni
28 matches
Mail list logo
