From: a.ryabinin@samsung.com (Andrey Ryabinin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: get rid of hardcoded assumptions about kernel stack size
Date: Fri, 04 Jul 2014 17:38:31 +0400 [thread overview]
Message-ID: <53B6AE57.70307@samsung.com> (raw)
In-Reply-To: <4429781.iuSvvPCxYj@wuerfel>
On 07/04/14 14:27, Arnd Bergmann wrote:
> On Friday 04 July 2014 11:13:31 Andrey Ryabinin wrote:
>>>
>>> but I wonder if there is a way to avoid the extra include here, as it might also
>>> cause a general slowdown because of asm/memory.h getting pulled into more .c
>>> files. Would it be reasonable to hardcode PAGE_SIZE here?
>>>
>>
>> IMO it's a bug of iop13xx platform, that it includes "higlevel" linux/reboot.h
>> from a very "lowlevel" header mach/iop13xx.h. I think it should be fixed with a patch above.
>> Slowing down of kernel build for a few more seconds is not good enough reason for me to
>> hardcode PAGE_SIZE here.
>
> I don't think we can pinpoint a specific header that is "wrong" here, the
That's just my opinion. Anyway, if this header needed only for declaring single enum
it worth to replace include with enum declaration.
> fundamental problem is that our header files are a bit messy when it comes
> to recursive inclusion and we'd be better off if we generally were a little
> more careful about including headers from other headers.
>
That's why we need to remove reboot.h from iop13xx.h.
Are you going to send a proper formatted patch for that?
Speaking of asm/page.h, a lot of other architectures
also have it included in thread_info.h, so I would leave it there.
> It's also very hard to retroactively clean this up on a large scale.
>
> Arnd
>
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
Russell King <linux@arm.linux.org.uk>,
Nicolas Pitre <nico@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm: get rid of hardcoded assumptions about kernel stack size
Date: Fri, 04 Jul 2014 17:38:31 +0400 [thread overview]
Message-ID: <53B6AE57.70307@samsung.com> (raw)
In-Reply-To: <4429781.iuSvvPCxYj@wuerfel>
On 07/04/14 14:27, Arnd Bergmann wrote:
> On Friday 04 July 2014 11:13:31 Andrey Ryabinin wrote:
>>>
>>> but I wonder if there is a way to avoid the extra include here, as it might also
>>> cause a general slowdown because of asm/memory.h getting pulled into more .c
>>> files. Would it be reasonable to hardcode PAGE_SIZE here?
>>>
>>
>> IMO it's a bug of iop13xx platform, that it includes "higlevel" linux/reboot.h
>> from a very "lowlevel" header mach/iop13xx.h. I think it should be fixed with a patch above.
>> Slowing down of kernel build for a few more seconds is not good enough reason for me to
>> hardcode PAGE_SIZE here.
>
> I don't think we can pinpoint a specific header that is "wrong" here, the
That's just my opinion. Anyway, if this header needed only for declaring single enum
it worth to replace include with enum declaration.
> fundamental problem is that our header files are a bit messy when it comes
> to recursive inclusion and we'd be better off if we generally were a little
> more careful about including headers from other headers.
>
That's why we need to remove reboot.h from iop13xx.h.
Are you going to send a proper formatted patch for that?
Speaking of asm/page.h, a lot of other architectures
also have it included in thread_info.h, so I would leave it there.
> It's also very hard to retroactively clean this up on a large scale.
>
> Arnd
>
next prev parent reply other threads:[~2014-07-04 13:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-18 13:50 [PATCH] arm: get rid of hardcoded assumptions about kernel stack size Andrey Ryabinin
2014-06-18 13:50 ` Andrey Ryabinin
2014-06-18 14:31 ` Will Deacon
2014-06-18 14:31 ` Will Deacon
2014-06-18 14:49 ` Andrey Ryabinin
2014-06-18 14:49 ` Andrey Ryabinin
2014-06-18 14:40 ` Nicolas Pitre
2014-06-18 14:40 ` Nicolas Pitre
2014-06-18 15:27 ` Andrey Ryabinin
2014-06-18 15:27 ` Andrey Ryabinin
2014-07-03 20:24 ` Arnd Bergmann
2014-07-03 20:24 ` Arnd Bergmann
2014-07-04 7:13 ` Andrey Ryabinin
2014-07-04 7:13 ` Andrey Ryabinin
2014-07-04 10:27 ` Arnd Bergmann
2014-07-04 10:27 ` Arnd Bergmann
2014-07-04 13:38 ` Andrey Ryabinin [this message]
2014-07-04 13:38 ` Andrey Ryabinin
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=53B6AE57.70307@samsung.com \
--to=a.ryabinin@samsung.com \
--cc=linux-arm-kernel@lists.infradead.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.