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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150805084826.GA23169@gmail.com>
Date:	Wed, 5 Aug 2015 10:48:26 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Brian Gerst <brgerst@...il.com>
Cc:	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct


* Brian Gerst <brgerst@...il.com> wrote:

> > Btw., the variable names here are crazy. I had to look twice to realize that 
> > we have 'v86' and 'vm86' which are two different things.
> >
> > Also, vm86plus_struct variables and fields are named wildly inconsistently: 
> > sometimes it's 'vm86.vm86_info', sometimes it's 'v86', sometimes 'user'. Ugh.
> >
> > Other fields have naming inconsistencies as well: for example we have 
> > thread.vm86->vm86plus.vm86dbg_active. 'vm86' is repeated _three_ times in that 
> > name, for no good reason.
> >
> > So please clean up the naming to make this all easier to read. Only the 
> > highest level field should have 'vm86' in it - all subsequent fields will 
> > inherit that name one way or another.
> 
> Some of these field names are visible to userspace and can't change.

That's a misconception: bits in the uapi headers can be renamed just fine.

The kernel ABI is that _semantics_ that user-space code relies on must not change.

Cleaning up field names is absolutely legit to do, and we've done it numerous 
times in the past. Especially where they are so confusing and inconsistent as in 
the vm86 code.

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ