From: James Bottomley <James.Bottomley@HansenPartnership•com>
To: Linus Torvalds <torvalds@linux-foundation•org>
Cc: Ingo Molnar <mingo@elte•hu>, Alan Cox <alan@lxorguk•ukuu.org.uk>,
Thomas Gleixner <tglx@linutronix•de>,
"H. Peter Anvin" <hpa@zytor•com>,
Andrew Morton <akpm@linux-foundation•org>,
Stephen Rothwell <sfr@canb•auug.org.au>,
linux-next@vger•kernel.org
Subject: Re: Request for linux-next inclusion of the voyager tree
Date: Wed, 10 Jun 2009 15:28:23 +0000 [thread overview]
Message-ID: <1244647703.4109.45.camel@mulgrave.site> (raw)
In-Reply-To: <alpine.LFD.2.01.0906100817060.6847@localhost.localdomain>
On Wed, 2009-06-10 at 08:20 -0700, Linus Torvalds wrote:
>
> On Wed, 10 Jun 2009, James Bottomley wrote:
> >
> > If I go the merge point route, I get a tree with more non trivial merge
> > points than commits, so it becomes incredibly difficult for anyone to
> > follow what's going on. I also can no longer use git-email to send my
> > patch series anywhere.
>
> Why do you need to merge at all?
>
> Do you get constant conflicts? If so, _that_ is likely the problem.
Pretty much, yes. The problem isn't in the voyager code, it's in the
residual subarchitecture clean up. As the x86 tree evolves, that's what
keeps conflicting mainly because adjacent areas get altered. Once
that's upstream, the voyager piece should be a smooth ride.
The other piece that gets conflicts is the fact that voyager needs two
additions to the quirks and smp ops pointer indirections to cope with
some of it's unique features ... these have all been over linux-scsi
several times, with feedback from the affected users. However, while
they remain out of tree, there another source of conflict.
> The rule should be that you should _never_ need to merge from Ingo or me,
> and things should be smooth. And if there are too frequent conflicts for
> that to work, then the rule should be that things get cleaned up so that
> those conflicts don't happen!
>
> Constant rebasing, or constant merging, is a symptom of something simply
> not working. It's probably why Ingo is fed up with Voyager in the first
> place. Can you guys just start telling me what the actual maintenance
> problem is? Where do you actually step on each others toes? What are the
> conflicts? Why is Voyager so special?
Once the last piece of the subarchitecture is removed and the pieces
needed to support voyager are in, that should be it.
The two additional pieces are:
1. prefill_possible_map initialisation ... voyager boots with a non apic
config, so it needs to prefill the possible map from its VIC CPU
registers
2. indirection of hard_smp_processor_id() ... voyager doesn't have an
apic, so it has to read a special VIC register instead.
There's also an addition to the boot code to make voyager detection
dynamic instead of static based on subarchitecture.
James
next prev parent reply other threads:[~2009-06-10 15:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 16:10 Request for linux-next inclusion of the voyager tree James Bottomley
2009-06-08 23:28 ` Tony Breeds
2009-06-10 14:45 ` James Bottomley
2009-06-09 9:45 ` Stephen Rothwell
2009-06-09 13:49 ` James Bottomley
2009-06-09 20:21 ` Ingo Molnar
2009-06-09 20:33 ` James Bottomley
2009-06-09 21:18 ` Ingo Molnar
2009-06-09 23:41 ` Alan Cox
2009-06-09 23:56 ` Ingo Molnar
2009-06-10 0:04 ` Linus Torvalds
2009-06-10 0:30 ` Ingo Molnar
2009-06-10 1:00 ` Ingo Molnar
2009-06-10 14:38 ` James Bottomley
2009-06-10 15:20 ` Linus Torvalds
2009-06-10 15:28 ` James Bottomley [this message]
2009-06-10 15:33 ` Linus Torvalds
2009-06-10 16:19 ` Ingo Molnar
2009-06-10 16:42 ` Ingo Molnar
2009-06-10 14:23 ` James Bottomley
2009-06-10 15:13 ` Thomas Gleixner
2009-06-10 15:23 ` Linus Torvalds
2009-06-10 15:39 ` Ingo Molnar
2009-06-10 16:02 ` James Bottomley
2009-06-10 16:53 ` Ingo Molnar
2009-06-11 1:35 ` Stephen Rothwell
2009-06-11 1:39 ` James Bottomley
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=1244647703.4109.45.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=alan@lxorguk$(echo .)ukuu.org.uk \
--cc=hpa@zytor$(echo .)com \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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