From: Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
To: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: [PATCH] Fix up headers so we can munge them for use by userspace.
Date: Wed, 14 Oct 2009 18:15:50 -0400 [thread overview]
Message-ID: <4AD64D96.90405@librato.com> (raw)
In-Reply-To: <20091008010614.GF18101-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
Applied.
(but removed comment about sys/types.h as per Serge's comment).
Oren.
Matt Helsley wrote:
> On Mon, Oct 05, 2009 at 09:20:27PM -0500, Serge E. Hallyn wrote:
>> I'm sorry, I'm really pretty ignorant when it comes to userspace includes.
>
> Me too. The shallow similarities in kernel/userspace header organization have,
> in the past, inspired plenty of bad assumptions on my part.
>
>> Can you give a little more explanation as to:
>> 1. why we don't need sys/user.h, and why it was included originally?
>
> sys/user.h includes definitions for register structs/array lengths.
>
> The comment above the include says:
> /* i387 structure seen from kernel/userspace */
>
> but the checkpoint headers do not re-use existing register structs/array
> lengths from sys/user.h since those same definitions are not used
> in the kernel.
>
> Similarly, s390 does not re-use existing register structs/array lengths
> from sys/user.h.
>
> Honestly, I don't know why they were included originally when none of
> these structs/array lengths were used.
>
>> 2. why we need sys/types.h first? I don't see that mentioned in
>> the linux/types.h.
>
> Maybe I was wrong -- I can't seem to reproduce any build errors by
> re-ordering those two.
>
>> 3. how much of this will be distro-dependent?
>
> Not much. I think since we're talking about headers it's more about glibc
> and kernel versions than distros -- I don't think SLES organizes its
> glibc headers differently than RHEL or debian. Are you aware of any
> distro differences that aren't just due to different upstream versions?
>
> I've been building x86-32 on Fedora 10 and Ubuntu Jaunty. From time to
> time I've also been testing and/or looking at headers from RHEL for s390 and
> ppc. If anything I'm seeing "older" headers which I would expect to have
> fewer of the required definitions and hence more of the problems related to
> glibc headers.
>
>> Don't read this as questioning their correctness, just as my curiosity.
>
> Sure. They are good questions, and even questions about correctness
> are welcome.
>
> Cheers,
> -Matt Helsley
>
>> thanks,
>> -serge
>>
>> Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org):
>>> Signed-off-by: Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> arch/s390/include/asm/checkpoint_hdr.h | 7 +++++--
>>> arch/x86/include/asm/checkpoint_hdr.h | 2 --
>>> include/linux/checkpoint_hdr.h | 4 ++++
>>> 3 files changed, 9 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/s390/include/asm/checkpoint_hdr.h b/arch/s390/include/asm/checkpoint_hdr.h
>>> index b6ea8ce..bc9f624 100644
>>> --- a/arch/s390/include/asm/checkpoint_hdr.h
>>> +++ b/arch/s390/include/asm/checkpoint_hdr.h
>>> @@ -19,8 +19,6 @@
>>>
>>> #ifdef __KERNEL__
>>> #include <asm/processor.h>
>>> -#else
>>> -#include <sys/user.h>
>>> #endif
>>>
>>> #ifdef CONFIG_64BIT
>>> @@ -34,7 +32,12 @@
>>> * NUM_FPRS defined in <asm/ptrace.h> to be 16
>>> * NUM_APRS defined in <asm/ptrace.h> to be 16
>>> * NUM_CR_WORDS defined in <asm/ptrace.h> to be 3
>>> + * but is not yet in glibc headers.
>>> */
>>> +#ifndef NUM_CR_WORDS
>>> +#define NUM_CR_WORDS 3
>>> +#endif
>>> +
>>> struct ckpt_hdr_cpu {
>>> struct ckpt_hdr h;
>>> __u64 args[1];
>>> diff --git a/arch/x86/include/asm/checkpoint_hdr.h b/arch/x86/include/asm/checkpoint_hdr.h
>>> index 7a24de5..282bd31 100644
>>> --- a/arch/x86/include/asm/checkpoint_hdr.h
>>> +++ b/arch/x86/include/asm/checkpoint_hdr.h
>>> @@ -34,8 +34,6 @@
>>> /* i387 structure seen from kernel/userspace */
>>> #ifdef __KERNEL__
>>> #include <asm/processor.h>
>>> -#else
>>> -#include <sys/user.h>
>>> #endif
>>>
>>> #ifdef CONFIG_X86_32
>>> diff --git a/include/linux/checkpoint_hdr.h b/include/linux/checkpoint_hdr.h
>>> index f8bd4e1..b318cee 100644
>>> --- a/include/linux/checkpoint_hdr.h
>>> +++ b/include/linux/checkpoint_hdr.h
>>> @@ -10,6 +10,10 @@
>>> * distribution for more details.
>>> */
>>>
>>> +#ifndef __KERNEL__
>>> +/* In userspace sys/types.h must be included before linux/types.h */
>>> +#include <sys/types.h>
>>> +#endif
>>> #include <linux/types.h>
>>>
>>> #ifdef __KERNEL__
>>> --
>>> 1.5.6.3
>>>
>>> _______________________________________________
>>> Containers mailing list
>>> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
>>> https://lists.linux-foundation.org/mailman/listinfo/containers
prev parent reply other threads:[~2009-10-14 22:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-03 7:10 [PATCH] Fix up headers so we can munge them for use by userspace Matt Helsley
[not found] ` <1254553859-481-1-git-send-email-matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-06 2:20 ` Serge E. Hallyn
[not found] ` <20091006022027.GA31628-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-10-08 1:06 ` Matt Helsley
[not found] ` <20091008010614.GF18101-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2009-10-14 22:15 ` Oren Laadan [this message]
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=4AD64D96.90405@librato.com \
--to=orenl-rdfvbdnroixbdgjk7y7tuq@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
/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.