https://bugzilla.suse.com/show_bug.cgi?id=1189965 https://bugzilla.suse.com/show_bug.cgi?id=1189965#c7 Michal Kube��ek <mkubecek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkubecek@suse.com --- Comment #7 from Michal Kube��ek <mkubecek@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.