Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1200533 > unrolled thread

Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct

Started byIngo Molnar <mingo@kernel.org>
First post2015-08-05 10:50 +0200
Last post2015-08-05 11:00 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct Ingo Molnar <mingo@kernel.org> - 2015-08-05 10:50 +0200
    Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-05 11:00 +0200

#1200533 — Re: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct

FromIngo Molnar <mingo@kernel.org>
Date2015-08-05 10:50 +0200
SubjectRe: [PATCH 4/7] x86/vm86: Move vm86 fields out of thread_struct
Message-ID<pU2yB-4zf-5@gated-at.bofh.it>
* Brian Gerst <brgerst@gmail.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1200542

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2015-08-05 11:00 +0200
Message-ID<pU2Ii-4Ky-17@gated-at.bofh.it>
In reply to#1200533
On Wed, Aug 5, 2015 at 10:48 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> 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.

I disagree. If it causes pain for user space, we just shouldn't do it.
Some people copy the headers (preferred), others include the kernel
header directory with a include path or a symlink, and it's damn
painful if we start changing things that user space depends on.

I'd say that it's like the ABI - if people don't really notice, you
can do it, but if it breaks the build of a user app, we should be very
very careful. The breakage is often hard to fix because of nasty
versioning issues..

Our goal in life really is "don't screw up user space".

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

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web