From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
Eric Biederman <ebiederm@xmission.com>,
linux-ima-devel@lists.sourceforge.net,
Andrew Morton <akpm@linux-foundation.org>,
linux-omap@vger.kernel.org, Dave Young <dyoung@redhat.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: Kexec regression in next-20160906
Date: Thu, 08 Sep 2016 12:23:13 -0300 [thread overview]
Message-ID: <8729269.3rIvqbaU1r@hactar> (raw)
In-Reply-To: <20160907080807.GD5783@n2100.arm.linux.org.uk>
Am Mittwoch, 07 September 2016, 09:08:07 schrieb Russell King - ARM Linux:
> Any change to a UAPI header needs to be carefully considered and
> questioned as it is always a potential userspace breakage - and in
> the kernel, we're supposed to be doing our up-most to avoid
> breaking userspace.
>
> It's not like it was in the old days when we didn't have the UAPI
> seperate - today, we can find these things by looking at the patch
> diffstat and seeing whether any file in "uapi" is touched. That
> should be the trigger for a really in-depth review of the change.
No UAPI header is touched by this patch series. That is because there are
two definitions of struct kexec_segment, one in include/linux/kexec.h and
the other one in include/uapi/linux/kexec.h. My patch changed the former.
I was unaware of the second definition in the latter.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>,
Andrew Morton <akpm@linux-foundation.org>,
Eric Biederman <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
Dave Young <dyoung@redhat.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
linux-ima-devel@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, kexec@lists.infradead.org
Subject: Re: Kexec regression in next-20160906
Date: Thu, 08 Sep 2016 12:23:13 -0300 [thread overview]
Message-ID: <8729269.3rIvqbaU1r@hactar> (raw)
In-Reply-To: <20160907080807.GD5783@n2100.arm.linux.org.uk>
Am Mittwoch, 07 September 2016, 09:08:07 schrieb Russell King - ARM Linux:
> Any change to a UAPI header needs to be carefully considered and
> questioned as it is always a potential userspace breakage - and in
> the kernel, we're supposed to be doing our up-most to avoid
> breaking userspace.
>
> It's not like it was in the old days when we didn't have the UAPI
> seperate - today, we can find these things by looking at the patch
> diffstat and seeing whether any file in "uapi" is touched. That
> should be the trigger for a really in-depth review of the change.
No UAPI header is touched by this patch series. That is because there are
two definitions of struct kexec_segment, one in include/linux/kexec.h and
the other one in include/uapi/linux/kexec.h. My patch changed the former.
I was unaware of the second definition in the latter.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: bauerman@linux.vnet.ibm.com (Thiago Jung Bauermann)
To: linux-arm-kernel@lists.infradead.org
Subject: Kexec regression in next-20160906
Date: Thu, 08 Sep 2016 12:23:13 -0300 [thread overview]
Message-ID: <8729269.3rIvqbaU1r@hactar> (raw)
In-Reply-To: <20160907080807.GD5783@n2100.arm.linux.org.uk>
Am Mittwoch, 07 September 2016, 09:08:07 schrieb Russell King - ARM Linux:
> Any change to a UAPI header needs to be carefully considered and
> questioned as it is always a potential userspace breakage - and in
> the kernel, we're supposed to be doing our up-most to avoid
> breaking userspace.
>
> It's not like it was in the old days when we didn't have the UAPI
> seperate - today, we can find these things by looking at the patch
> diffstat and seeing whether any file in "uapi" is touched. That
> should be the trigger for a really in-depth review of the change.
No UAPI header is touched by this patch series. That is because there are
two definitions of struct kexec_segment, one in include/linux/kexec.h and
the other one in include/uapi/linux/kexec.h. My patch changed the former.
I was unaware of the second definition in the latter.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
next prev parent reply other threads:[~2016-09-08 15:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 22:09 Kexec regression in next-20160906 Tony Lindgren
2016-09-06 22:09 ` Tony Lindgren
2016-09-06 23:33 ` Thiago Jung Bauermann
2016-09-06 23:33 ` Thiago Jung Bauermann
2016-09-07 8:08 ` Russell King - ARM Linux
2016-09-07 8:08 ` Russell King - ARM Linux
2016-09-08 15:23 ` Thiago Jung Bauermann [this message]
2016-09-08 15:23 ` Thiago Jung Bauermann
2016-09-08 15:23 ` Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8729269.3rIvqbaU1r@hactar \
--to=bauerman@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ima-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=tony@atomide.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.