[HN Gopher] Rust in QEMU Roadmap
___________________________________________________________________
Rust in QEMU Roadmap
Author : todsacerdoti
Score : 208 points
Date : 2024-11-27 07:29 UTC (6 days ago)
(HTM) web link (lore.kernel.org)
(TXT) w3m dump (lore.kernel.org)
| bonzini wrote:
| Thanks for posting this to HN! Author here, happy to answer any
| questions.
|
| (By the way, I did not originally start the project, though I've
| worked quite a bit on the safe abstractions that are mentioned in
| the roadmap).
| ndesaulniers wrote:
| Bullish or bearish on rust in the kernel?
| bonzini wrote:
| Hello! Small world. :)
|
| For drivers, it's already happening, especially for graphics
| but not limited to that. 6.13 has some very important
| changes. A lot of Linux is drivers so that's already a reason
| to be bullish.
|
| Answering for QEMU instead: it depends on the community being
| willing to share the burden of writing the FFI code. Despite
| Rust being low level, there is still a substantial amount of
| work to do. Replies to the roadmap pointed out tracepoints as
| an area where I know nothing and therefore I would like
| someone else to do the work (I am working mostly on the
| object and threading models, which is also where a lot of the
| impedance mismatch between Rust and C lies).
| aapoalas wrote:
| Hello. I assume tracepoints mean kprobes/uprobes or
| something along those lines? I've just this weekend worked
| on implementing/adapting a crate for DTrace USDTs aka
| DTrace probes to also work on Linux and generate SystemTap
| SDTs (aka USDTs aka dtrace probes).
|
| This is probably a little different from tracepoints in the
| kernel space but I'm somewhat interested in going deeper
| and into the kernel side of things. Let me know if you have
| any pointers as to where I might be of concrete assistance
| to you!
| bonzini wrote:
| QEMU has several tracepoint providers, the main ones are
| (a slightly fancy version of) printf and USDT. There is a
| Python program that generates the C code for the chosen
| backend(s), so the thing to do would be to adjust the
| script to produce either an FFI bridge or the equivalent
| Rust code.
| aapoalas wrote:
| Can you link the script? This sounds vaguely like
| something that would be no skin off my back, so I'd be
| quite happy to help with this.
| bonzini wrote:
| Yes it's https://github.com/qemu/qemu/tree/master/scripts
| /tracetool.
|
| I also found https://github.com/cuviper/probe-
| rs/tree/master/src/platform which seems interesting.
| JoshTriplett wrote:
| What does your wishlist for Rust look like? (Besides "simpler
| C/Rust interoperability", of course.) Has QEMU run into things
| that Rust-for-Linux hasn't, that feel missing from the Rust
| language?
| bonzini wrote:
| Right now the only language-level thing I would like is const
| operator overloading. Even supporting MSRV as old as 1.63 was
| not a big deal, the worst thing was dependencies using
| let...else which we will vendor and patch.
|
| Pin is what it is, but it is mostly okay since I haven't
| needed projection so far. Initialization using Linux's "impl
| PinInit<Self>" approach seems to be working very well in my
| early experiments, I contributed changes to use the crate
| without unstable features.
|
| In the FFI area: Bindgen support for toml configuration
| (https://github.com/rust-lang/rust-bindgen/pull/2917 but it
| could also be response files on the command line), and easier
| passing of closures from Rust to C (though I found a very
| nice way to do it for ZSTs that implement Fn, which is by far
| the common case).
|
| The "data structure interoperability" part of the roadmap is
| something I should present to someone in the Rust community
| for impressions. Some kind of standardization of core FFI
| traits would be nice.
|
| Outside the Rust core proper, Meson support needs to mature a
| bit for ease of use, but it is getting there. Linux obviously
| doesn't need that.
|
| BTW, saw your comment in the dead thread, you're too nice. I
| have been curious about Rust for some time and with Linux
| maturing, and Linaro doing the first contribution of build
| system integration + sample device code, it was time to give
| it a try.
| JoshTriplett wrote:
| > Right now the only language-level thing I would like is
| const operator overloading.
|
| As far as I know, const traits are still on track.
|
| > easier passing of closures from Rust to C
|
| As in, turning a Rust closure into a C function-pointer-
| plus-context-parameter?
|
| > The "data structure interoperability" part of the roadmap
| is something I should present to someone in the Rust
| community for impressions. Some kind of standardization of
| core FFI traits would be nice.
|
| Would be happy to work with you to get something on the
| calendar.
| bonzini wrote:
| > As far as I know, const traits are still on track.
|
| Yes they are. My use case is something like the bitflags
| crate, there are lots of bit flags in emulated devices of
| course. In the meanwhile I guess it would be possible to
| use macros to turn something like "bit_const!(Type:A|B)"
| to "Type(A.0|B.0)" or something like that.
|
| > As in, turning a Rust closure into a C function-
| pointer-plus-context-parameter?
|
| Yes, more in general everything related to callbacks is
| doable but very verbose. We might do (procedural?) macro
| magic later on to avoid the verbosity but for now I
| prefer to stick to pure Rust until there's an idea of
| which patterns recur.
|
| Let me know by email about any occasions to present what
| I have.
| 0x457 wrote:
| I made this handy function to pass callbacks to C: https:
| //github.com/andoriyu/uclicious/blob/master/src/traits...
| o11c wrote:
| > Related to this, the IsA trait allows typesafe compile-time
| checked casts. Unlike in C code, casting to a superclass can be
| written in such a way that the compiler will complain if the
| destination type is _not_ a superclass, and with zero runtime
| cost.
|
| This is unfair to C. With a little work when defining all
| classes (or non-leaf classes if you're willing for a hairier
| implementation), you can do this there too.
|
| There are probably other ways, but the way that seems most
| "obvious" to me is to define the base via union of all bases in
| the chain, rather than only the immediate base class. So:
| /* class Foo {int f;}; class Bar extends Foo {int
| b;}; class Qux extends Bar {int q;}; class Leaf
| extends Qux {int l;}; */ struct Foo { int f; };
| struct Bar { union { struct Foo base, base_Foo}; int b; };
| struct Qux { union { struct Bar base, base_Bar; struct Foo
| base_Foo; }; int q; }; struct Leaf { struct Qux base; int
| l; }
|
| Then your "compile-time-safe-cast to base class" macro just
| checks 3 things in order: 1. check if we're
| already the right class. 2. check if `base` is the right
| class. 3. unconditionally try to use the appropriately-
| named `base_Foo` member as calculated from the type.
|
| (runtime-safe-checked downcasts just have to check that the
| reverse is possible)
| bonzini wrote:
| "Your scientists were so preoccupied with whether or not they
| could, they didn't stop to think if they should." :D
|
| Though I admit that Rust also has to include the full list of
| base classes (https://github.com/rust-lang/rfcs/pull/1268
| would fix it).
| o11c wrote:
| The main reason the C version _must_ hard-code is because C
| macros can 't be recursive. What's Rust's excuse?
|
| (that said, the C approach is also nice for manually
| accessing fields of distant base classes)
| jefbyokyie wrote:
| > define the base via union of all bases in the chain [...]
| just checks 3 things in order
|
| Can you please show a concrete example? Thanks.
| Neywiny wrote:
| I've said this before on here and I'll say it again. The QEMU
| code base is a nightmare. The amount of fake C++ is mind numbing.
| Every time I come across a variable or strict declaration or
| method with the word "class" in it, I'm reminded of how much
| easier the whole thing would've been with C++. You can't even
| compile C++ into QEMU because of how the headers use keywords.
| That's not even touching their macro abuse template functions.
| You know what has templates and classes? C++. And constructors.
| There's just so much.
|
| All this to say: if Rust can make it in, that's great, because
| I'm tired of dealing with C's simplicity for more complicated
| tasks. I'm not a rust user but if it lets me use classes and
| templates, I'll switch over
| masklinn wrote:
| > I'm not a rust user but if it lets me use classes and
| templates, I'll switch over
|
| Yer not switching any time soon then. Rust does have methods
| but not classes (QOM's inheritance is specifically called as an
| issue in TFA) and it uses Haskell-style generics rather than
| C++-style templates.
| Neywiny wrote:
| :( the QOM inheritance is where I've had my wrist bugs.
| Recently I merged from master (upgrading me from version
| 8.something to 9.2.?) and they dramatically changed the
| resets. I tried the new way and had segfaults in bad places
| that went away when I reordered code that shouldn't have
| ordering requirements. That was too scary so I switched to
| their legacy reset function and it was all fine again. All
| this blind casting of opaques makes me nervous.
| bonzini wrote:
| The legacy reset way is fine, and yeah this is where being
| more strict and doing more stuff within the language should
| help.
| ThePhysicist wrote:
| I mean it has polymorphism via v-tables and composition via
| traits, that's enough object-orientation for me. Inheritance
| is a core principle of OOP but in practice most C++ class
| hierarchies are relatively flat (there are exceptions like
| Qt, which I think uses inheritance in a good way), in
| practice most of that can be mimicked with embedding and
| composition well enough to work. Not sure if you want to call
| that object-oriented but operating on polymorphous structures
| that encapsulate their data is pretty close to object
| orientation (the good parts of OOP, at least). And I'm not a
| big expert on Rust but I think you can do most of the things
| we do in C++ with templates using macros.
| galangalalgol wrote:
| The one lagging thing that isn't easy with rust's generics
| is expressions, and that looks to be getting kicked down
| the road indefinitely. You can't have Foo<N> * Foo<M> ->
| Foo<N+M> or similar. That is a useful thing for statically
| sized math libraries and for performance oriented
| metaprogramming. The latter can be clumsily handled with
| macros, but not the former. It is also blocking portable
| simd from stabilizing, apparently now indefinitely. I still
| wouldn't pick any other language a new production product,
| but I find the stalling out on const generic expressions
| frustrating, as simd and static math libraries are things I
| use daily.
| LoganDark wrote:
| I could go on and on about the limitations of
| min_const_generics, missing TAIT (type alias impl trait),
| unstable coroutines/generators, etc. but none of that
| stuff erases how much of a _miracle_ Rust is as a
| language. The industry _really_ needed this. It 's
| practically the poster child of memory safety and
| security-critical industries are picking it up and
| Ferrocene is pushing it in safety-critical environments
| as well and it's just. Good. Please. Finally a serious
| contender against the terrible reign of C and C++.
| duped wrote:
| > You can't have Foo<N> * Foo<M> -> Foo<N+M> or similar.
|
| You can though, unless I totally misunderstand your
| syntax use std::{marker::PhantomData,
| ops::{Add, Mul}}; pub struct Foo<T> {
| _p: PhantomData<T>, } impl<N, M>
| Mul<Foo<M>> for Foo<N> where N:
| Add<M> { type Output = Foo<<N as
| Add<M>>::Output>; fn mul(self, rhs: Foo<M>)
| -> Self::Output { todo!() }
| }
| ynik wrote:
| You misunderstood. N, M are supposed to be integers
| (const generics); in your example code you've made them
| types. Also, your `type Output = Foo<<N as
| Add<M>>::Output>;` just means "multiplication has the
| same return type as addition". But desired is that
| multiplying a Foo<4> with a Foo<3> results in a Foo<7>.
|
| Rust decided that it's important to not have
| instantiation-time compiler errors, but this makes
| computation with const generics complicated: you're not
| allowed to write Foo<{N+M}> because N+M might overflow,
| even if it never actually overflows for the generic
| arguments used in the program.
| quotemstr wrote:
| Instantiation time errors unlock so much metaprogramming
| potential that Rust is going to be forced to allow them
| sooner or later.
| Ar-Curunir wrote:
| I believe this kind of stuff is being worked on.
| duped wrote:
| aiui this isn't inherently limited by instantiation-time
| error messages and is available on nightly today with the
| generic_const_exprs feature. It's in the pipeline.
| IshKebab wrote:
| I don't think he literally means templates and classes. Rust
| has equivalents that do the things you want templates and
| classes for (generics and structs/traits respectively).
|
| I completely agree with his point about reimplementing C++
| badly in C. GNOME does this too in their libraries. He will
| be much happier with Rust.
| tejohnso wrote:
| What are the advantages of trying to use fake c++ instead of
| actual c++ for their use case? I'm sure there are / were smart
| people working on the project. Do they keep decision records?
| Have you had a conversation with the relevant people about it?
| qalmakka wrote:
| C++, especially before C++11, was a total mess. Even today,
| it's super easy to shoot yourself in the foot and you
| literally can't learn the entirety of the language due to how
| massive it is. This still doesn't justify doing the absurdity
| of macro magic and garbage I've seen people pumping out in C
| over the years though.
|
| IMHO if you deliberately use C it's because you want to keep
| things simple. Sometimes C++ will inevitably lead to
| overcomplicated designs nobody needs; there's a reason why
| 90's C++ feels massively outdated, while 90's C is still
| (mostly) accessible. C is a great way to keep the urge people
| have to shovel in OOP even when it doesn't really make sense.
| When I see some bullshit C++ code at work, I often think, "if
| people had to write this in C, they wouldn't have overthought
| this this much"...
|
| My 2 cents is that there was a Java craze back in the '90s
| that basically infected all code designed in that time
| period, and that's how we got some very weird nonsense that
| in hindsight was poorly thought out. Just look at stuff like
| GTK+ and GObject...
| galangalalgol wrote:
| I have been guilty of this if only in school. A class
| assignment could be completed in java or c and I knew c++
| and c and my teammates knew c. I really wanted to do oop
| because I was ignorant, but none of us knew java so we did
| OO in c. It was horrible. I like the simplicity of c. I
| wish there was a zig that was immutable by default, and had
| a borrowchecker, but I think that road inevitably leads to
| a GC jitted language or to something as complicated as
| rust. Well almost as complicated, at least macros would
| still be written in the same syntax as normal runtime code.
| bobajeff wrote:
| The GObject system for all it's faults serves a purpose.
| Similar to COM in Windows it allows mapping of higher level
| languages to libraries. Without it there wouldn't be all
| the bindings we have to Python, JavaScript, Vala and Rust
| today. I wouldn't say it was poorly thought out so much as
| mismatched with it's user's typical uses and expectations.
| flohofwoe wrote:
| > What are the advantages of trying to use fake c++ instead
| of actual c++ for their use case?
|
| There are exactly none, but there was a time during the mid-
| to late-90s when it was hip to implement OOP frameworks on
| top of C (C++ only really became a realistic option once
| C++98 was widely supported which took a couple of years,
| ...also there was such an extreme OOP hype in the 90s that it
| is hard to believe today - EVERYTHING had to be OOP, no
| matter if it made sense or not).
|
| QEMU seems to be from around the end of that era (first
| release apparently in 2003), and looking at the code it looks
| exactly as I imagined, with meta-class pointers, constructor-
| and destructor-functions etc... it would almost certainly be
| better to use a simple non-OOP C-style, but that was an
| 'outdated' point of view at that time (since everything had
| to use that new shiny OOP paradigm).
| bonzini wrote:
| The object model in QEMU is from 2007-2011. Internally
| there isn't a lot of inheritance (it's pretty shallow), but
| yeah I guess "is-a" is what was in vogue at the time.
|
| However there is a reason to have the object model, and it
| was added because some things were getting out of hand. You
| had to write three parsers for everything you added: one
| for command line, one for the text-based command interface
| and one for the JSON API. And you had to do it once for
| each kind of "object" (device, network backend, disk
| backend, character device backend etc.). The object model
| is designed to let you write code just once for all three
| and to reuse the interface across object types.
| dhosek wrote:
| That 90s OOP hype really mirrors the contemporary FP hype
| (and the 70s-80a structured programming hype). Programming
| is definitely subject to fads.
| crabbone wrote:
| I worked for a large infra project that was mostly written in
| C with the kind of trickery that is being here ascribed to
| QEMU code (I trust the parent, but I haven't seen the code
| myself).
|
| It's a common thing to do in projects like this in C. While
| C++ solves _some_ of the problems for larger projects, it
| brings so many more, it 's usually not worth it. Projects of
| this kind, essentially, invent their own language, with their
| own conventions. C is just a convenient tool (given the
| alternatives...) to do that, as it's treated as a kind of a
| transpilation target. Think about languages like Haskell
| which essentially work like that, but went even further.
|
| So, what typically happens is that memory allocation, I/O and
| concurrency need to be done differently from how the language
| runtime wants to do that. So, at this point, you basically
| throw away most of the existing language runtime. From my
| recent encounters with different bugs in QEMU, I imagine that
| they really, really need a lot of customization in how memory
| is allocated (my particular case was that QEMU was
| segfaulting when running ldconfig in aarch64 emulation, which
| turned out to be due to ldconfig having some weird custom-
| made memory allocation pattern which QEMU cannot account
| for.) It's easier to fight this battle with C than it is with
| C++.
| dboreham wrote:
| I was going to post the same thing. Others on this thread
| may not have had experience with very large C codebases and
| hence haven't seen this play out. To a large degree C++ is
| just capturing what was already widespread practices in C,
| and indeed assembly before that.
| quotemstr wrote:
| You can define your own "language", the way you describe
| it, in C++ more easily than you can in C. C++ gives you
| more powerful and expressive tools for doing so. A program
| is not improved by foregoing these tools. There's nothing
| in C++ forcing you to do anything that makes anything
| "harder".
| crabbone wrote:
| I wouldn't be so quick to put "easy" and "C++" in the
| same sentence... Also, C and C++ language tools suck,
| when it comes to making a language compared to anything
| in Lisp family, for example, or any language that has
| Lisp-like macros. C wasn't chosen for it's ability to
| make other languages. It was an easy target. The benefits
| are the simpler and more malleable runtime that can be
| made to do all sorts of weird things where C++ would be
| much harder to deal with.
|
| In other words, if you don't want the language runtime,
| if you don't want C++ templates, smart pointers, classes,
| lambdas, exceptions etc. But, you want to be able to
| manage memory for eg. realtime kind of system... simply
| removing all the unwanted stuff from C++ is harder than
| it is with C.
|
| And, if you did want some / all of those features of C++,
| there are saner languages to have that (and you'd pay for
| it by having to drag in their runtime and conventions).
| Before Rust was a thing, I've seen people choose D
| instead, for example, as a kind of middle ground between
| the asceticism of C and unnecessary excess of C++.
| quotemstr wrote:
| Lisp is a non sequitur. C++ can do the same "weird
| things" C can. There is literally no advantage whatsoever
| of choosing to wear the C hairshirt instead of using C++.
| Not a single one.
|
| Sure, Rust is better than C++ in some ways. You can have
| a legitimate debate about C++ versus Rust. There can be
| no debate about C versus C++: the latter is better in
| every single way.
|
| > unnecessary excess of C++.
|
| Is the unnecessary excess of C++ in the room with us
| right now?
|
| Again, you don't have to use any part of C++ you don't
| like. A few minor spelling differences aside, it remains
| a superset of C. Using C++ not C will not hurt you in any
| project whatsoever.
| IshKebab wrote:
| The only advantage I know of is that it means you stay within
| the C ABI. It can simplify linking a little in some cases, or
| FFI. I guess compilation is faster too.
|
| But yeah broadly speaking it's a terrible idea.
| winocm wrote:
| Yeah, even integrating any C++ into it and calling any QEMU
| functions via extern "C" declarations when including the
| headers cause many issues because many variables are named
| "new" or have type cast issues.
|
| It's a full time job on its own to fix all of the compilation
| errors. Could probably fix it with coccinelle scripts to make
| some parts easier, but still, validating the codebase with
| different compilers to make sure there's no resulting subtle
| breakage either still requires a lot of effort.
| jefbyokyie wrote:
| C++23 is a godawful mess; especially the functional paradigms
| (which look beautiful in e.g. OCaml) that got shoehorned
| kicking and screaming into the morass that C++ had already
| been.
|
| If you read function specs in the OCaml docs, they're
| understandable and the syntax is clean; the same concepts
| bolted onto C++ look like line noise, _both_ in actual syntax
| _and_ the (allegedy) English-language description on
| en.cppreference.com.
|
| Reading the C++ standard itself is an exercise in futility,
| very much _unlike_ the C standard. (Although, latest
| developments in C land are repulsive too, IMO.)
|
| The C++ committee's tantrums and scandals (physical violence at
| meetings!) put the worst that has been seen in open-source
| communities to shame. <https://izzys.casa/2024/11/on-safe-cxx/>
| has been posted to reddit and HN recently.
|
| C++ compilation still takes absolutely forever, and C++
| template error messages are as incomprehensible as ever.
|
| One important problem with C++ (repeated ad nauseam, so this is
| nothing new) is the unforeseen and unintended harmful
| interactions between such language features that were supposed
| to be orthogonal. The only remedy for that is to _stop adding_
| stuff to the language; but nooo, it just keeps growing.
|
| Another important problem is that, the more the compiler does
| for you implicitly, the less you _see_ (and the less you can
| debug) what happens _in the code_. This is not a problem in
| OCaml, which is a managed language with a safe runtime, but it
| 's a huge problem in C++, which remains a fundamentally unsafe
| language. (And yes, once you start extending OCaml with C,
| i.e., mixing implicit and explicit, OCaml too becomes unsafe,
| and a lot of head-scratching can occur.) A home-grown object
| system in C is at least explicit, so it's all there for the
| developer to read, instrument, step through, and so on.
|
| When your "core guidelines"
| <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>
| could fill a _book_ , there's a problem with your language.
|
| (I'm not here to defend QEMU's object model indiscriminately;
| I'm here to bash C++.)
| vlovich123 wrote:
| Any ideas why people are relying on distro packaged Rust for
| development instead of rustup? For Rust it feels weird making
| development choices around several year old versions of the
| language.
| tangent128 wrote:
| Rustup downloads toolchains from third-party (to the distro)
| repositories; distros do not want to be in a position where
| they can no longer build packages because of an external
| service going down.
|
| So, if you are developing something you want to see packaged in
| distros, it needs to be buildable with the tool versions in the
| distro's repositories.
|
| (Not just rustup- Debian requires repackaging Cargo
| dependencies so that the build can be conducted offline
| entirely from source packages.)
| vlovich123 wrote:
| You're answering a slightly different question but to me
| that's a Debian packaging problem to solve. It's weird to me
| that QEMU devs take this problem seriously enough to be
| putting in all sorts of workarounds to support old versions
| of the toolchain in the tip of tree just to privilege Debian
| support.
|
| This feels more like a CI thing for the QEMU project and I'm
| sure solvable by using rustup or a trusted deb repo that
| makes the latest tool chain available on older Debian
| platforms.
|
| As for Debian itself, for toolchains it really should do a
| better job back porting more recent versions of toolchains
| (not just Rust) or at least making them available to be
| installed. The current policy Debian is holding is really
| difficult to work with and causes downstream projects to do
| all sorts of workarounds to make Debian builds work (not just
| for Rust by the way - this applies to C++ as well). And it's
| not like this is something it's unfamiliar with - you can
| install multiple JVM versions in parallel and choose a
| different default.
| ronsor wrote:
| > As for Debian itself, for toolchains it really should do
| a better job back porting more recent versions of
| toolchains (not just Rust) or at least making them
| available to be installed.
|
| Most toolchains don't have as much churn as Rust.
| vlovich123 wrote:
| Disagree. No stable release of Debian today supports
| c++23 which is coming up on two years old at this point
| (this corresponds to a major Rust edition, not the minor
| stuff they publish on an ongoing basis every month).
|
| Java in Bookworm installs JDK 17 which is three years old
| at this point. Java itself is on 23 with 21 being an LTS
| release.
|
| This means that upstream users intentionally maintain an
| old toolchain just to support Debian packaging or
| maintain their own deb repo with newer tools.
|
| You're confusing cause and effect. People aren't
| migrating because Debian packaging lags so badly, not
| because there aren't improvements projects would love to
| otherwise use.
| 0x457 wrote:
| > Most toolchains don't have as much churn as Rust.
|
| What churn? A release every 6 months? Unlike many others,
| toolchains (i count nodejs and co here) rust only need
| one toolchain because latest rustc always able to compile
| older rust code.
|
| Now compare rust releases to this:
| https://gcc.gnu.org/releases.html
| pm215 wrote:
| It's not about our own CI -- we could easily use rustup as
| part of setting up the CI environment, and I think we might
| actually be doing exactly that at the moment.
|
| Lots of QEMU users use it through their downstream distros.
| We even recommend that if you're using QEMU in a way that
| you care about its security then you should use a distro
| QEMU, because the distros will provide you timely security
| fix updates. Sure, we _could_ throw all that cooperation
| away and say "tough, you need to use up-to-the-minute
| rust, if that's a problem for distro packagers we don't
| care". But we want to be a good citizen in the traditional
| distro packaging world, as we have been up til now. Not
| every open source project will want or need to cater to
| that, but I think for us it matters.
|
| That doesn't mean that we always do the thing that is
| simplest for distros (that would probably be "don't use
| Rust at all"); but it does mean that we take distro pain
| into account as a factor when we're weighing up tradeoffs
| about what we do.
| vlovich123 wrote:
| To be clear. I'm not criticizing the position the QEMU
| project is in. I recognize you have to work with Debian
| here. I'm more frustrated that Debian has such a
| stranglehold on packaging decisions and it effectively
| refuses to experiment or innovate on that in any way.
|
| Out of curiosity though, have you explored having your
| own deb repo instead? I would trust QEMU-delivered
| security fixes on mainline far more than the Debian
| maintainers to backport patches.
| pm215 wrote:
| I think that trust would be somewhat misplaced -- QEMU
| has historically not made particularly timely security
| fixes either on mainline or on branches. To the extent
| that our stable-branch situation is better today than it
| was some years ago, that is entirely because the person
| who does the downstream Debian packaging stepped up to do
| a lot more backporting work and stable-branch maintenance
| and releases. (I'm very grateful for that effort -- I
| think it's good for the project to have those stable
| branch releases but I certainly don't have time myself to
| do that work.)
|
| As an upstream project, we really don't want to be in the
| business of making, providing and supporting binary
| releases. We just don't have the volunteer effort
| available and willing to do that work. It's much easier
| for us to stick to making source releases, and delegate
| the job of providing binaries to our downstreams.
| vlovich123 wrote:
| These two statements to me seem contradictory:
|
| > QEMU has historically not made particularly timely
| security fixes either on mainline or on branches
|
| > It's much easier for us to stick to making source
| releases, and delegate the job of providing binaries to
| our downstreams
|
| Am I correct that this is essentially saying "we're going
| to do a snapshot of the software periodically but end
| users are responsible for applying patches that are
| maintained by other users as part of building"? Where do
| these security patches come from and how do non-Debian
| distros pick them up? Are Arch maintainers in constant
| contact with Debian maintainers for security issues to
| know to apply those patches & rebuild?
| pm215 wrote:
| Security patches are usually developed by upstream devs
| and get applied to mainline fairly promptly[1], but you
| don't want to run head-of-git in production. If you run a
| distro QEMU then the distro maintainers backport security
| fixes to whatever QEMU they're currently shipping and
| produce new packages. None of this is particularly QEMU
| specific. There's a whole infrastructure of security
| mailing lists and disclosure policies for people to tell
| distros about security bugs and patches, so if you're a
| distro you're going to be in contact with that and can
| get a headsup before public disclosure.
|
| [1] and also to stable branches, but not day-of-cve-
| announcement level of urgency.
| jefbyokyie wrote:
| > I'm more frustrated that Debian has such a stranglehold
| on packaging decisions and it effectively refuses to
| experiment or innovate on that in any way.
|
| What Debian has is not a "stranglehold" but an ideology,
| and Debian continues to matter to (some) upstream
| projects because lots of users identify with Debian's
| hyperconservative, noncommercial ideology.
|
| Your complaint is basically, "it's too bad that the
| userbase not sharing my values is large enough to
| matter".
| yjftsjthsd-h wrote:
| > I'm more frustrated that Debian has such a stranglehold
| on packaging decisions and it effectively refuses to
| experiment or innovate on that in any way.
|
| Does Debian have a stranglehold? AFAIK every other distro
| does the same thing, and all of them for good reasons.
| 0x457 wrote:
| Because QEMU wants their thing to be packaged in various
| distros. Those distros don't allow packages to bring their own
| tool chain (for good reasons).
| capitainenemo wrote:
| Well, at least a couple of years ago, one surprising thing I
| discovered with rustup was that unlike distros that have a
| clean install/uninstall, rustup was rm -rf * ing everything in
| the place it was installed. There was an open bug on it and
| multiple complaints. I, who needed it for various system
| builds, had innocently rustup'd to /usr/local. On uninstall, it
| wiped all of /usr/local. I had backups on that machine, but it
| was still an unpleasant experience and I did lose a few not-
| too-important scripts.
|
| I don't know if others have run into the same thing, but it's
| why I'd trust Gentoo's packaging more.
| jeroenhd wrote:
| The goal of non-rolling release distros is to have a predefined
| set of dependencies, which the distro maintains and fixes if
| necessary.
|
| If Rust decides that it no longer supports compiling on x86, or
| if it starts depending on a version of LLM that no longer runs
| on a supported architecture, Debian must fix that for their
| users. That leaves the curl2bash installers that are popular
| with fast moving tools and languages useless for long term
| stability. The same goes for crates, which can be pulled at any
| time for almost any reason and break compiles.
|
| Then there are other setups distros can choose to support, like
| having update servers/package repositories for updating servers
| that aren't allowed to connect to the internet or are even air
| gapped. You can't save rustup to a DVD, but you can take a copy
| of the Debian repository and update air gapped servers in a way
| that leaves a permanent trace (as long as you archive the
| disks).
|
| Not all distros have this problem. In theory the Rust people
| could set up an apt/repository Debian users can add to get the
| best features of a package manager and the latest version, and
| distros like Arch/Gentoo don't bother with the stability
| guarantees most distros have.
|
| Qemu can ignore these requirements and opt into not being
| packaged into distros like Debian or Ubuntu or Fedora or RHEL
| or Oracle Linux. That'd cost them a lot of contributions from
| those platforms, though, and may cause a risk of the project
| being forked (or even worse, end up in the ffmpeg/avconv
| situation).
___________________________________________________________________
(page generated 2024-12-03 23:01 UTC)