https://github.com/rpm-software-management/rpm/pull/2315
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1035#issuecomment-1412820654
You are receiving this because you are subscribed to this thread.
Message ID:
I meant not function multiversioning
(https://docs.01.org/clearlinux/latest/tutorials/fmv.html), but building a
separate binary is built with optimizations -
https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture
Where needed, building if optimized libs
Did anyone measure the real performance gain from having a separate znver1
architecture? It is a lot of maintenance and QA burden, but what is the result?
As time goes futher, probably new hardware instructions will apear in modern
x86 CPUs, so new arches like znver1 will have to be added.
Also
For Rust packaging, we would appreciate being able to use rich dependencies
together with architectures. Now we have to simply remove those specific bits
or require everything everywhere.
Same goes to OS handling. you can't use %ifarch in deps =(
--
You are receiving this because you are
> This is a dangerous argument, as by this logic we're required to accept
> anything at all that distros come up with.
I am very much aware of this. But considering this is how we were told to
implement this when we started this, I'm a little frustrated now that the
approach isn't good enough
> But this one is important enough that I really want this in mainline rpm,
> since without it, it means regular rpm can't handle an entire distro set of
> packages...
This is a dangerous argument, as by this logic we're required to accept
anything at all that distros come up with.
> I think
Come to think of it, it may be best to rework architecture handling to sit on
top of Provides: (where there's implied Provides: for anything supported by the
CPU).
That way emulators like qemu-static-arm could add Provides: arch(armv7hnl) etc.
so you wouldn't need to force installation of
At least in this case, all Ryzen generation 1 and newer CPUs will match on
znver1, so I don't think that'd be a problem with this patch. But I take your
point about the general approach of adding more architectures.
I think it's probably something to explore on improving how we do this
That arch patches are systematically so problematic is to me mostly just
further testimony that we (as in rpm) are doing something seriously wrong in
that department, not to be taken personally.
These are all about instruction set extensions, and those that actually matter
should be exposed
> I'm just really, really weary and dubious about these architecture tweaks
> because they're so bleeping arbitrary.
I know, I don't particularly love it either, but RPM doesn't support defining
arbitrary architectures and architecture filter mechanisms. Each architecture
that people want to
Just FWIW, I've grown particularly averse to architecture patches because in
the last few years, every single one of them has been nothing but a source of
controversy and grief.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I'm just really, really weary and dubious about these architecture tweaks
because they're so bleeping arbitrary. Looking at gcc manual around znver:
znver1
AMD Family 17h core based CPUs with x86-64 instruction set
support. (This supersets BMI, BMI2,
ffesti commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
OK , there's a #if defined(__linux__) && defined(__i386__) branch just
below with its own
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
Wait nope, there's a `cpuid()` implementation for i386 right below...
--
You are receiving this
ffesti commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
Hmm, shouldn't the #if match up with the one around is_ryzen or be more general?
--
You are receiving
Conan-Kudo commented on this pull request.
> @@ -736,6 +736,16 @@ static rpmRC rpmPlatform(rpmrcCtx ctx, const char *
> platform)
}
+# if defined(__linux__) && defined(__x86_64__)
You're right, this was accidentally broken when I rebased it again...
--
You are receiving this
@ffesti Mainly because nothing else seemed to follow that convention? They all
seemed to use the GCC machine architecture name, and so we went with that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think one of the questions is: Why doesn't the name start with x86_64 or at
least something closer to that?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@pmatilai The addition of this new architecture name is because we need a way
to declare incompatibility at the RPM level for CPUs that don't support it.
This is pretty much the only way we can do it. When this was first being worked
on, nobody seemed to think there was any better way to do
Ignoring the actual micro architecture, as a general principle we do not add
new assembler foo into rpm.
That there is pre-existing asm code doesn't mean it's a good idea, on the
contrary the existing stuff needs to go too but that's obviously not in the
scope here.
--
You are receiving this
Erm. So we have this nice sane architecture family known as x86_64, so lets go
call it znver to make it ... more exciting? Sorry but I just don't think so.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@mikhailnov I'm not going to add architectures nobody has...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Why znver1 only, why only this architecture? It looks a bit strange
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This change adds the ability for RPM to detect systems running on AMD Ryzen
systems and allow the installation of packages that are built specifically for
this subarchitecture.
As part of this change, a new `%x86_64` macro has been introduced to alias all
64-bit x86 architecture variants in
24 matches
Mail list logo
