All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: "Robert P. J. Day" <rpjday@mindspring.com>
Cc: Matt Porter <mporter@kernel.crashing.org>,
	Embedded Linux PPC list <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: curious about BK checkin protocol
Date: Wed, 26 May 2004 09:57:05 -0700	[thread overview]
Message-ID: <20040526165705.GT6763@smtp.west.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0405260714540.24178@localhost.localdomain>


On Wed, May 26, 2004 at 07:19:53AM -0400, Robert P. J. Day wrote:

> On Tue, 25 May 2004, Matt Porter wrote:
> > On Tue, May 25, 2004 at 09:12:10AM -0400, Robert P. J. Day wrote:
> > >   i just bk-cloned a fresh copy of the source tree from
> > > http://ppc.bkbits.net:8080/linuxppc-2.5, and once again, had to fix the
> > > file arch/ppc/kernel/ppc_ksyms.c to remove the now-obsolete snippet of
> > > code:
> > >
> > > #if defined(CONFIG_8xx)
> > > EXPORT_SYMBOL(request_8xxirq);
> > > #endif
> > >
> > >   i thought it had been well-established by now that this had to go.
> > > what's the protocol for someone putting these changes into the tree?
> > > just curious.
> >
> > Post a patch.  If it's something that is incorrect in linux-2.5
> > as well, then the patch is expected to be against linux-2.5.
>
> post to this list?  sure, if that's the right place.  the only reason i'm
> obsessed about that little fix as opposed to all the others that are going
> in is that, WRT the most recent BK pull from
> http://ppc.bkbits.net:8080/linuxppc-2.5, that's the *only* thing that
> keeps the kernel from compiling, and letting me build that a kernel that,
> while it loads and runs, admittedly still blows up upon starting init.
>
> while i realize that the current kernel still has user land problems, it
> seems a shame to not at least fix the single minor thing that prevents a
> simple build.

I still like to argue that it's best to loudly blow up than to compile
fine and then die in other ways at run-time (if someone hadn't gotten
the last problem fixed on 8xx I was getting tempted to move what we had
done now up with an #error tossed on top of head_8xx.S pointing people
to what's wrong, etc).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-05-26 16:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-25 13:12 curious about BK checkin protocol Robert P. J. Day
2004-05-25 17:23 ` Matt Porter
2004-05-26  3:44   ` 405ep ether port broken in performance test Davey
2004-05-26 11:19   ` curious about BK checkin protocol Robert P. J. Day
2004-05-26 16:57     ` Tom Rini [this message]
2004-05-26 17:20       ` Robert P. J. Day
2004-05-26 17:35     ` Matt Porter

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=20040526165705.GT6763@smtp.west.cox.net \
    --to=trini@kernel.crashing.org \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=mporter@kernel.crashing.org \
    --cc=rpjday@mindspring.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 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.