Comment # 7
on bug 1189965
from Michal Kube������ek
(In reply to Michael H. Kelley from comment #5)
> There is a subfield in the guest OS ID to allow a distro to be specifically
> identified. That's what this patch does -- it codes the subfield to
> indicate "SUSE". This kind of change obviously won't go upstream, and we
> never did come up with a better scheme for setting the subfield on a
> per-distro basis.
>
> There is internal Microsoft telemetry based on the guest OS ID. In the
> kernel panic path, the guest OS ID value is recorded and logged by Hyper-V,
> and it is useful to be able to know the distro that was running, independent
> of the kernel version number.
>
> If SUSE is willing to continue to carry this one-off patch for the purposes
> described here, we think it would be useful to continue to do so.
I don't think that's the point. Some time ago, a similar patch was submitted
to upstream, only with the id values defined as config options rather than
hardwired (so that we would only set those CONFIG_* to correct values in our
kernel configs).
The patch was not accepted and what I remember from reading the discussion,
the objection was that there were absolutely no guidelines telling people
what to set the OS id values to for a specific distribution. So e.g. we
somehow know that 0x10 is supposed to mean "SUSE" but kernel package
maintainers in other distributions have no idea what values to use. It seemed
that vendors just claim random values and hope they won't collide.
In other words, there was/is no central registry saying that SUSE has 0x10,
Red Hat some other value, Canonical another etc. and no process of applying
for a registered value. Maybe there is such registry but if that is the case,
the submitter (not sure if it was Olaf or someone from Microsoft) was not
able to point to it at that time. So I believe if such registry exists or if
Microsoft (as Hyper-V vendor) is willing to create and run such registry,
there is a good chance the Kconfig based verion of this patch could be
upstreamed.