lkml.org 
[lkml]   [2009]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] rtc: add x86 support for rtc-efi

* 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


\
 
 \ /
  Last update: 2009-05-28 01:25    [W:0.424 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site