Messages in this thread | | | Subject | Re: [EDAC ABI v13 04/25] events/hw_event: Create a Hardware Events Report Mecanism (HERM) | From | Steven Rostedt <> | Date | Thu, 10 May 2012 11:20:10 -0400 |
| |
On Thu, 2012-05-10 at 17:12 +0200, Borislav Petkov wrote: > On Thu, May 10, 2012 at 12:08:32PM -0300, Mauro Carvalho Chehab wrote: > > There's also another technical reason to give an acronym to the EDAC > > version that actually works: changeset numbers are not consistent > > within distributions (or other trees, like -stable - although this 60+ > > patch series probably won't fit on -stable merging criteria). > > > > Also, this EDAC changeset 60+ patch series can't be represented by a > > single changeset, and requires userspace changes in order to get a > > proper representation model for memories.
Is this a redesign of EDAC or just a fix of it? Does this require userspace to use a new ABI?
> > > > Tagging the EDAC core version with a name helps a lot when dealing > > with all the unsolved bugzillas that will be closed by backporting > > this patch series in order to fix the serious EDAC core bug that > > were providing fake information to the end user for all Intel memory > > controllers manufactured after 2005. > > edac_module.c:18:#define EDAC_VERSION "Ver: 2.1.0" > > Increment that in the last patch.
If this is redesigning a subsystem and changing the ABI for userspace than a new name is appropriate. Much like ipchains turning into iptables.
But if this is just fixing the subsystem where userspace sees no difference, than the same name fits.
-- Steve
| |