[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac41b3c803364f0cbc6c931449c2a51d@AcuMS.aculab.com>
Date: Fri, 30 Apr 2021 08:30:08 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Thomas Schoebel-Theuer' <tst@...oebel-theuer.de>,
Kajetan Puchalski <mrkajetanp@...il.com>,
"mceier+kernel@...il.com" <mceier+kernel@...il.com>
CC: "ojeda@...nel.org" <ojeda@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"rust-for-linux@...r.kernel.org" <rust-for-linux@...r.kernel.org>,
"linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/13] [RFC] Rust support
From: Thomas Schoebel-Theuer
> Sent: 30 April 2021 07:40
...
> Industry (where I am working) often requires a "second source" to avoid
> the so-called "vendor lock-in", which is the key point of this part of
> the discussion.
There is also the related problem that you need to be able to come
back in 5 years time and re-build the original image.
You can then make minor changes, rebuild, and have a reasonable
confidence that there are no side effects.
This means that web-based and auto-updated tools cannot be used.
Even a VM image might suddenly fall foul of changes to hypervisors.
So you need to keep (at least) 2 system than contain all the build
tools just in case you need to do a maintenance build of an old release.
But even then we can no longer build drivers for some windows
systems because we can't sign them with the old keys.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists