From: Ingo Molnar <mingo@elte.hu>
To: "H. Peter Anvin" <h.peter.anvin@intel.com>
Cc: "Huang, Ying" <ying.huang@intel.com>,
Brian Maly <bmaly@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dannf@hp.com" <dannf@hp.com>
Subject: Re: [PATCH] rtc: add x86 support for rtc-efi
Date: Thu, 28 May 2009 01:21:49 +0200 [thread overview]
Message-ID: <20090527232149.GA3830@elte.hu> (raw)
In-Reply-To: <4A1AC741.3060600@intel.com>
* H. Peter Anvin <h.peter.anvin@intel.com> wrote:
> Huang, Ying wrote:
>> On Tue, 2009-04-21 at 02:21 +0800, Anvin, H Peter wrote:
>>> Ingo Molnar wrote:
>>>> * Brian Maly <bmaly@redhat.com> wrote:
>>>>
>>>>>> Hm, it would be nice to first unify the relevant bits of
>>>>>> arch/x86/kernel/time_{32|64}.c into arch/x86/kernel/time.c, and
>>>>>> then we can apply such patches without duplicative effects.
>>>>> Ingo,
>>>>>
>>>>> Are you OK with consolidating this into arch/x86/kernel/rtc.c as
>>>>> Huang Ying had suggested? This seems like the most logical place
>>>>> for the rtc-efi init to happen, but your suggestion to
>>>>> consolidate this into arch/x86/kernel.time.c may have advantages
>>>>> that I am not aware of. Anyway, I would appreciate any
>>>>> insight/opinions on this if you have any. Thanks.
>>>> Yes, that indeed sounds like an even better place for it.
>>>>
>>> Furthermore, the EFI RTC code probably should be in its own file.
>>>
>>> In fact, arch/x86/kernel really could use more subdirectories; at
>>> least the EFI and UV-specific code should be be moved out.
>>
>> Or, do you think it is appropriate to re-organize EFI related code into
>> a sub-architecture?
>>
>
> No, we're been trying to get rid of subarchitectures in the x86
> kernel. The reason is that the notion of subarchitectures matches
> reality in x86-land poorly. Most variants of x86 share
> considerable code: UV has EFI, PC has EFI or BIOS, Voyager has
> BIOS and a standard RTC, and so on.
Yeah - we essentially got rid of the ex subarchitecture code in
2.6.30. We still have config options that turn on various sorts of
behavior - but most of them are runtime. We definitely dont want to
reintroduce anything subarchitecture-ish.
Ingo
next prev parent reply other threads:[~2009-05-27 23:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 17:49 Brian Maly
2009-04-06 19:31 ` dann frazier
2009-04-06 22:26 ` H. Peter Anvin
2009-04-06 22:55 ` Brian Maly
2009-04-08 16:23 ` dann frazier
2009-04-09 23:18 ` Andrew Morton
2009-04-10 13:51 ` Ingo Molnar
2009-04-20 17:15 ` Brian Maly
2009-04-20 17:20 ` Ingo Molnar
2009-04-20 18:21 ` H. Peter Anvin
2009-05-19 20:10 ` Brian Maly
2009-05-25 5:49 ` Huang Ying
2009-05-25 16:28 ` H. Peter Anvin
2009-05-27 23:21 ` Ingo Molnar [this message]
2009-04-10 1:08 ` Huang Ying
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=20090527232149.GA3830@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=bmaly@redhat.com \
--cc=dannf@hp.com \
--cc=h.peter.anvin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome