linux-kernel - Re: [tip:x86/urgent] x86, cpufeature: Rename X86_FEATURE_DTS to X86_FEATURE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jun 2012 11:13:06 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	mingo@...nel.org, linux-kernel@...r.kernel.org, JBeulich@...e.com,
	tglx@...utronix.de, hpa@...ux.intel.com,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, cpufeature:   Rename X86_FEATURE_DTS to 
 X86_FEATURE_DTHERM

On Sun, 24 Jun 2012 13:37:00 -0700, H. Peter Anvin wrote:
> On 06/24/2012 12:49 PM, Jean Delvare wrote:
> >>
> >> Therefore, rename this to "dtherm".
> >
> > I see the rationale for changing the string in /proc/cpuinfo, and
> > "dtherm" is reasonably good. I fail to see the rationale for changing
> > the X86_FEATURE_ name though, this is an API change we don't need. Plus
> > X86_FEATURE_DTS has the merit of naming the feature the way it is
> > commonly done in technical documentation, so readers know exactly what
> > it refers too, which isn't the case of DTHERM. So can we please stick
> > to X86_FEATURE_DTS?
> 
> Except that *really* seems like begging for similar problems in the future.

With your other patch to catch such collisions, I think we should be
just safe from now on?

> >> This conflict went into mainline via the hwmon tree without any x86
> >> maintainer ack, and without any kind of hint in the subject.
> >>
> >>      a4659053 x86/hwmon: fix initialization of coretemp
> >
> > All 3 x86 maintainers were Cc'd, none commented. And you know fairly
> > well why the patch went through the hwmon tree. So please stop the
> > finger-pointing. It's unfortunate that it happened, but it did, and we
> > try to fix it now, period.
> >
> >> Reported-by: Jean Delvare <khali@...ux-fr.org>
> >> Link: http://lkml.kernel.org/r/4FE34BCB.5050305@linux.intel.com
> >> Cc: Jan Beulich <JBeulich@...e.com>
> >> Cc: <stable@...r.kernel.org> v2.6.36..v3.4
> >
> > No Signed-off-by?
> >
> > Not sure why you want this to go to stable trees?
> >
> 
> I think we want to minimize the ABI divergence here.

The ABI divergence already exists and will have to be dealt with
anyway. All you're doing by pushing the changes to stable trees is
making its shape more complex, and increasing the risk of conflict.
Such a conflict already happened, BTW...

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/