Re: Re: [PATCH] scripts: Make check-symfile.py work on alpha
On Sun, Jan 21, 2024 at 07:50:02PM +0000, Daniel P. Berrangé wrote:
On Sat, Jan 20, 2024 at 11:30:10PM +0100, Andrea Bolognani wrote:
> The script expects each of the symbols that it looks for to
> be in one of three sections, which in nm(1) are described as
> follows:
>
> T - The symbol is in the text (code) section.
> B - The symbol is in the BSS data section. This section
> typically contains zero-initialized or uninitialized
> data, although the exact behavior is system dependent.
> D - The symbol is in the initialized data section.
>
> When building on alpha, however, some of the symbols show up
> in one of two additional sections, specifically:
Again alpha is irrelevant as an architecture, so this
patch is not needed.
Debian builds packages on alpha and, even though it's no longer
considered a release architecture, it works just fine and keeps up
with updated software components:
$ uname -a
Linux debian-alpha 6.6.8-alpha-generic #1 Debian 6.6.8-1
(2023-12-22) alpha GNU/Linux
That's from a Debian installation running under qemu-system-alpha
that I've created over the weekend. Bit slow, as one would expect
when TCG is involved, but other than that perfectly functional.
In fact, this tiny patch is all that's needed to get the Debian
package for libvirt to build successfully. And it works too, at least
when it comes to the client part:
$ ip a show dev enp0s2
2: enp0s2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000
link/ether 52:54:00:fd:42:9b brd ff:ff:ff:ff:ff:ff
inet 192.168.124.126/24 brd 192.168.124.255 scope global dynamic enp0s2
valid_lft 3379sec preferred_lft 3379sec
inet6 fe80::5054:ff:fefd:429b/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
$ virsh -c qemu+ssh://192.168.124.1/system list
Id Name State
------------------------------
1 debian-alpha running
$ virsh -c qemu+ssh://192.168.124.1/system dumpxml debian-alpha
--xpath /domain/devices/interface/mac
<mac address="52:54:00:fd:42:9b"/>
Here I'm connecting to the host's libvirtd from within the guest,
just for convenience. I could just as easily connect to a remote
hypervisor.
I could of course keep this patch as a downstream-only change in the
Debian package, but I see no point in not accepting it upstream,
especially since the maintenance burden it causes is literally zero.
Please reconsider :)
--
Andrea Bolognani / Red Hat / Virtualization