lkml.org 
[lkml]   [2009]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: x86/Voyager
    From
    On Sun, Jan 18, 2009 at 11:41 AM, James Bottomley
    <James.Bottomley@hansenpartnership.com> wrote:
    > On Sun, 2009-01-18 at 08:14 +0100, Ingo Molnar wrote:
    >> * Brian Gerst <brgerst@gmail.com> wrote:
    >>
    >> > On Sun, Jan 18, 2009 at 12:59 AM, Tejun Heo <tj@kernel.org> wrote:
    >> > > Brian Gerst wrote:
    >> > >> On Sun, Jan 18, 2009 at 12:05 AM, Tejun Heo <tj@kernel.org> wrote:
    >> > >>> Hello,
    >> > >>>
    >> > >>>> --- a/arch/x86/kernel/setup_percpu.c
    >> > >>>> +++ b/arch/x86/kernel/setup_percpu.c
    >> > >>>> @@ -147,6 +147,9 @@ unsigned long __per_cpu_offset[NR_CPUS] __read_mostly;
    >> > >>>> #endif
    >> > >>>> EXPORT_SYMBOL(__per_cpu_offset);
    >> > >>>>
    >> > >>>> +DEFINE_PER_CPU(int, cpu_number);
    >> > >>>> +EXPORT_PER_CPU_SYMBOL(cpu_number);
    >> > >>> This is inside CONFIG_HAVE_SETUP_PER_CPU_AREA. I think voyage would
    >> > >>> be unhappy with this change.
    >> > >>
    >> > >> Is there any specific reason Voyager doesn't use the x86
    >> > >> setup_per_cpu_areas() function? I don't see anything on a quick
    >> > >> glance that would not work. The x86 code is pretty much a superset of
    >> > >> the default code in init/main.c.
    >> > >
    >> > > I have no idea at all. Given that not many people can test it, I
    >> > > figured just leaving it alone would be the best course but if it can
    >> > > be merged, all the better.
    >> >
    >> > Unfortunately Voyager doesn't compile currently for unrelated reasons.
    >> > I'll take a look at incorporating it into these patches, but I can't
    >> > even do a compile test right now.
    >
    > What are "unrelated reasons"?, 2.6.28 compiles and boots for me, except
    > some of the compile fixes (which are regressions, by the way) aren't
    > included in spite of being sent several times.
    >
    > I've put them up here:
    >
    > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/voyager-2.6.git
    >
    > I haven't included the cpumask fixes (so it won't compile on 2.6.29-rc2
    > yet) because I'll have to try to polish them to fit in with whatever's
    > going on. Plus there's some type of initramfs boot failure that I need
    > to investigate. However, usually I wait until the x86 churn is
    > finished, which is a lot later into the -rc cycle than this before
    > fixing up all the breakage.
    >
    >> Peter/James, what's the current status of x86/Voyager cleanups?
    >
    > The only outstanding problem I can see in 2.6.29 is a cpumask screw up
    > caused by Mike Travis ... it looks easily fixable, he just forgot to
    > convert voyager.
    >
    > I have to say that putting the SMP CPU definitions in cpu/common.c
    > hedged around with ifdefs for type looks really to be the wrong thing to
    > do. We already have compile selected files with these types, the
    > definition should be in there.
    >
    >> A couple of months ago i made a few suggestions about how to convert
    >> Voyager to the cleaner x86_quirks 'quirks HAL' (from the current fragile
    >> and hard and expensive to maintain 'compile time HAL'), but it didnt seem
    >> to go anywhere. See the discussion of this timeframe:
    >>
    >> http://lkml.org/lkml/2008/11/3/53
    >>
    >> The VisWS subarch (which was a similarly excentric design that was only a
    >> PC in terms of having Intel CPUs) has been converted to CONFIG_X86_VISWS
    >> already, with arch/x86/kernel/visws_quirks.c holding the optional quirk
    >> handlers.
    >>
    >> The desired end result would be to have a CONFIG_X86_VOYAGER=y build mode
    >> that adds the quirk handlers to an otherwise generic kernel, with most of
    >> the quirks concentrated into a single arch/x86/kernel/voyager_quirks.c
    >> file - instead of having a full subarch for x86/Voyager. Both
    >> arch/x86/mach-voyager/ and arch/x86/include/asm/mach-voyager/ would go
    >> away in the end - because all functionality is merged into the generic
    >> code and the quirks would be in voyager_quirks.c.
    >
    > You appear to have forgotten that we already had this discussion here:
    >
    > http://marc.info/?t=122539020300002
    >
    > But to precis, the bottom line is that I'm concerned about the damage to
    > mainline x86 this would cause because voyager is a vastly different
    > beast. We'd be doubling at least the number of function pointer
    > indirections, plus the current quirk stuff is inadequate: voyager needs
    > boot time separation to handle the unique SUS maps and other things, so
    > there'd be a big intrusion into the boot system as well.
    >
    >> I'd be glad to lend a helping hand both with the patches and with testing
    >> on non-Voyager - especially the SMP bits probably need extensions on the
    >> x86_quirks side. (And i'm sure the other x86 maintainers would we glad to
    >> help out with this process too.)
    >>
    >> x86/Voyager is the last holdout in this area, and with an active kernel
    >> developer like James behind it it ought to be fixable - should James have
    >> the time/interest.
    >
    > But no-one's yet made any argument for why it's a worthwhile thing to be
    > doing.
    >
    >> If there's no time/interest in that then we can temporarily mark Voyager
    >> CONFIG_BROKEN until cleanup/fix patches arrive.
    >
    > It's not broken and I've already sent you the cleanup/fix patches ... I
    > can send them directly to Linus as voyager maintainer if you prefer.

    The build breakage was due to the cpumask changes I believe, inherited
    from -tip.

    There is alot of duplicated code in voyager_smp.c that is making it
    difficult for me to work on the per-cpu changes. Do you see any
    reason that Voyager can't use the normal x86 setup_per_cpu_areas()
    code?

    --
    Brian Gerst


    \
     
     \ /
      Last update: 2009-01-18 18:45    [W:0.032 / U:1.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site