linuxppc_2_5 source tree (and others)

linuxppc_2_5 source tree (and others)

[Murray Jensen]

Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
has been replaced with a linuxppc_2_4_devel tree. Could someone in the
know please post a quick update what this means, and perhaps what the
future holds wrt 2.4/2.5 linuxppc (embedded)?

I guess I should actually ask about what I want :-) The linuxppc_2_5 tree
had a "drivers/i2c/i2c-algo-8xx.c" file which has disappeared from 2_4_devel.
I need an i2c driver for linuxppc for the 8260 and figured this would be a
good place to start. So the question really is what has happened to the 8xx
i2c driver in the fsmlabs linuxppc_2_5, and has anyone ported this to (or done
one independently for) the 8260?

And while I am at it, I have searched the archives for info about IDMA
and it appears that it is a do it yourself job (and that it may not be
so good on the 8xx anyway - but from what we can tell, it is much better
on the 8260 - if anyone knows differently, please let me know). If you
have a driver/support code/etc for IDMA on the 8260 (or 8xx) I would
appreciate it very much if you let me know.

Thanks for your time. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: linuxppc_2_5 source tree (and others)

[Tom Rini]

On Thu, May 10, 2001 at 06:38:02PM +1000, Murray Jensen wrote:

> Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
> has been replaced with a linuxppc_2_4_devel tree. Could someone in the
> know please post a quick update what this means, and perhaps what the
> future holds wrt 2.4/2.5 linuxppc (embedded)?

I was hoping Cort would mention this here, but 2_5 has been 'dead' for a
while and is finally gone too.  There's still mirrors of it however.
It will exist again, but when 2.5.0 appears and will be based off the
linux_2_4 tree or so.  Right now 2_4_devel isn't up to date wrt 8xx/4xx, and
some new boards 2_5 had.  I'm working on it. :)

> I guess I should actually ask about what I want :-) The linuxppc_2_5 tree
> had a "drivers/i2c/i2c-algo-8xx.c" file which has disappeared from 2_4_devel.
> I need an i2c driver for linuxppc for the 8260 and figured this would be a
> good place to start. So the question really is what has happened to the 8xx
> i2c driver in the fsmlabs linuxppc_2_5, and has anyone ported this to (or done
> one independently for) the 8260?

These are in 2_4_devel as of last night.  I'm also trying to get ahold of the
i2c maintainers so that it can be in linus' tree eventually.

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

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

Re: linuxppc_2_5 source tree (and others)

[Dan Malek]

Murray Jensen wrote:

> ......Could someone in the
> know please post a quick update what this means, and perhaps what the
> future holds wrt 2.4/2.5 linuxppc (embedded)?

Tom Rini has done lots of this work, so I'll rely on him to respond.
He is trying to finish up some finals at school, so it may take a day
or so.

> I guess I should actually ask about what I want :-) The linuxppc_2_5 tree
> had a "drivers/i2c/i2c-algo-8xx.c" file which has disappeared from 2_4_devel.

Right.  Tom is working with the real authors of the I2C software so
we get approval to just check this in all of the way to the main
kernel tree.  I was able to drop it into the _2_5 tree because I
didn't have to ask.  If you still have the _2_5 tree around, just
make a patch to 2.4_devel and keep on going.  It should show up for
real pretty soon.  I have also modified this for the 8260, and I
am going to have to look for it and get that checked in, too :-).
I still think bit-banging software for I2C is faster and more
efficient than using the CPM......at least for single master mode.

> And while I am at it, I have searched the archives for info about IDMA
> and it appears that it is a do it yourself job

Well, yes...Implicitly, all CPM devices use IDMA, so just copy one
of those and gut it for your own use.  All an IDMA driver would do is
set up buffer descriptors.  All of the device control and buffer
management is unique to the device, so I still can't grok a "generic"
IDMA driver.


	-- Dan

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

Re: linuxppc_2_5 source tree (and others)

[Cort Dougan]

As of last night linuxppc_2_4_devel should have the i2c changes you need.
Take a look at the web page www.fsmlabs.com/linuxppcbk.html for info on how
to get a copy.

} Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
} has been replaced with a linuxppc_2_4_devel tree. Could someone in the
} know please post a quick update what this means, and perhaps what the
} future holds wrt 2.4/2.5 linuxppc (embedded)?

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

Re: linuxppc_2_5 source tree (and others)

[Albert D. Cahalan]

Tom Rini writes:
> On Thu, May 10, 2001 at 06:38:02PM +1000, Murray Jensen wrote:

>> Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
>> has been replaced with a linuxppc_2_4_devel tree. Could someone in the
>> know please post a quick update what this means, and perhaps what the
>> future holds wrt 2.4/2.5 linuxppc (embedded)?
>
> I was hoping Cort would mention this here, but 2_5 has been 'dead' for a
> while and is finally gone too.  There's still mirrors of it however.
> It will exist again, but when 2.5.0 appears and will be based off the
> linux_2_4 tree or so.  Right now 2_4_devel isn't up to date wrt 8xx/4xx, and
> some new boards 2_5 had.  I'm working on it. :)

Oh, lovely.

I'm very glad to have ignored this BitKeeper nonsense for
the most part then. I knew there was a good reason to rely
on the one true source tree from Linus. I'm not screwed like
all the people working from linuxppc_2_5 are.

On the other hand, I had to do my own PowerCore 6750 VME port
for the 2.4 kernel. That sucked. It would be nice if everyone
had the decency to submit stuff to Linus in a way that he finds
acceptable, rather than hoarding source code in obscure places
that are only accessible via non-standard non-free software.

So, how did _you_ know that 2_5 has been 'dead' for a while?

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

Re: linuxppc_2_5 source tree (and others)

[Tom Rini]

On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:
>
> Tom Rini writes:
> > On Thu, May 10, 2001 at 06:38:02PM +1000, Murray Jensen wrote:
>
> >> Hi, I see that the linuxppc_2_5 bk tree has disappeared from fsmlabs, and
> >> has been replaced with a linuxppc_2_4_devel tree. Could someone in the
> >> know please post a quick update what this means, and perhaps what the
> >> future holds wrt 2.4/2.5 linuxppc (embedded)?
> >
> > I was hoping Cort would mention this here, but 2_5 has been 'dead' for a
> > while and is finally gone too.  There's still mirrors of it however.
> > It will exist again, but when 2.5.0 appears and will be based off the
> > linux_2_4 tree or so.  Right now 2_4_devel isn't up to date wrt 8xx/4xx, and
> > some new boards 2_5 had.  I'm working on it. :)
>
> Oh, lovely.
>
> I'm very glad to have ignored this BitKeeper nonsense for
> the most part then. I knew there was a good reason to rely
> on the one true source tree from Linus. I'm not screwed like
> all the people working from linuxppc_2_5 are.
>

Right.  But the "one true source tree from Linus" doesn't always work for
other arches.  Why?  Keeping stuff in 100% never works.  There almost always
has been a slightly more up-to-date tree than Linus' for ages (when did the
first -ac patch come out, anyone know?).  And, who exactly is screwed that's
working from the old 2_5 tree?  There hasn't been any new activity in it for
ages.  Shortly (mainly once I'm done w/ finals) it'll be little more than
exporting your local changes from '2_5' and applying them in 2_4_devel.  Yes,
history bits will be lost, but such is life. :)

> On the other hand, I had to do my own PowerCore 6750 VME port
> for the 2.4 kernel. That sucked. It would be nice if everyone
> had the decency to submit stuff to Linus in a way that he finds
> acceptable, rather than hoarding source code in obscure places
> that are only accessible via non-standard non-free software.

So use rsync and import into your own CVS tree.  I think it sucks too
that bk isn't gpl'ed, but hey.  I don't really care that much.  I'd wager
your port would have sucked much less if you were working off the 2_5 tree
too (mvme5100 support is currently 4 mvme-specific files, and some new
common ones other boards use too.  Some pcore boards are about as simple
too).

> So, how did _you_ know that 2_5 has been 'dead' for a while?

Well, it was on the linuxppc-commit list, which Cort has mentioned a few time
(hence it's majordomo now and not a sendmail alias like it used to be).
It's even mentioned on the page that talks about the bk trees:
http://www.fsmlabs.com/linuxppcbk.html

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

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

Re: linuxppc_2_5 source tree (and others)

[Albert D. Cahalan]

Tom Rini writes:
> On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:

>> I'm very glad to have ignored this BitKeeper nonsense for
>> the most part then. I knew there was a good reason to rely
>> on the one true source tree from Linus. I'm not screwed like
>> all the people working from linuxppc_2_5 are.
>
> Right.  But the "one true source tree from Linus" doesn't always
> work for other arches.  Why?  Keeping stuff in 100% never works.
> There almost always has been a slightly more up-to-date tree than
> Linus' for ages (when did the first -ac patch come out, anyone

The 2.2.14 kernel is over 15 months old. I'm expected to run
Montevista's obsolete and severely hacked up 2.2.14 kernel if
I want to use a PowerCore 6750. So "slightly more up-to-date"
could mean over 15 months I guess.

> know?).  And, who exactly is screwed that's working from the old 2_5
> tree?  There hasn't been any new activity in it for ages.

I nearly fell into the trap. Just recently, 2_5 was listed as
being where the latest development happens. It certainly looked
that way too, with support for more boards than 2_4 had.
Until just this morning, I was thinking I ought to use 2_5!

>   Shortly
> (mainly once I'm done w/ finals) it'll be little more than exporting
> your local changes from '2_5' and applying them in 2_4_devel.  Yes,
> history bits will be lost, but such is life. :)

That defeats the purpose of revision control. You might as
well use "diff" and "patch" if you will be throwing away your
version history.

>> On the other hand, I had to do my own PowerCore 6750 VME port for
>> the 2.4 kernel. That sucked. It would be nice if everyone had the
>> decency to submit stuff to Linus in a way that he finds acceptable,
>> rather than hoarding source code in obscure places that are only
>> accessible via non-standard non-free software.
>
> So use rsync and import into your own CVS tree.  I think it sucks
> too that bk isn't gpl'ed, but hey.  I don't really care that much.

The 2_2 and 2_4 trees were available via rsync, while 2_5 was not.

> I'd wager your port would have sucked much less if you were working
> off the 2_5 tree too (mvme5100 support is currently 4 mvme-specific
> files, and some new common ones other boards use too.  Some pcore
> boards are about as simple too).

So now you are saying I should have used the 2_5 tree?????
Wasn't I supposed to know (by psychic methods) that the 2_5
tree is 'dead' now?

>> So, how did _you_ know that 2_5 has been 'dead' for a while?
>
> Well, it was on the linuxppc-commit list, which Cort has mentioned a
> few time (hence it's majordomo now and not a sendmail alias like it
> used to be).  It's even mentioned on the page that talks about the
> bk trees: http://www.fsmlabs.com/linuxppcbk.html

I figured that would be a list for automated check-in reports
generated by the BitKeeper software.

So anyway, we now have a 2_4_devel tree to wonder about.
Might somebody suddenly decide to delete this tree too?
Will changes get back to Linus, or is this a dead-end too?

Having separate trees also defeats the purpose of revision control.
One is supposed to use branches (or whatever BitKeeper calls them)
for stable, release, development, etc.

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

Re: linuxppc_2_5 source tree (and others)

[Cort Dougan]

You should lose the chip from your shoulder if you want assistance.  _2_5
was never listed that way, it was an internal tree only.

} I nearly fell into the trap. Just recently, 2_5 was listed as
} being where the latest development happens. It certainly looked
} that way too, with support for more boards than 2_4 had.
} Until just this morning, I was thinking I ought to use 2_5!

No-one should have used it and the people telling you that you should have
used it shouldn't have done that.

Go to www.fsmlabs.com/linuxppcbk.html and you'll find info on how to ftp,
rsync and bk the latest Linux/PPC kernels.  You'll also find pointers to
ftp.kernel.org for the latest patches against the Linus tree.

} So now you are saying I should have used the 2_5 tree?????
} Wasn't I supposed to know (by psychic methods) that the 2_5
} tree is 'dead' now?

The list has announcements about changes in the tree status, discussions
about moving the trees, merging them, developing new code and merging with
Linus.  It's a list for those who want to use those trees in any way - lots
of useful information.

} I figured that would be a list for automated check-in reports
} generated by the BitKeeper software.

Get on the list and you won't be caught unaware.  The _2_5 tree was never a
"for outside use" tree.  Others were misinforming people, I know.  That was
unfortuante but the _2_4_devel tree and the _2_4 trees are both public and
will not be "dead ends".  All changes that Linus will accept (not a simple
job) do find their way to Linus eventually.

} So anyway, we now have a 2_4_devel tree to wonder about.
} Might somebody suddenly decide to delete this tree too?
} Will changes get back to Linus, or is this a dead-end too?

Thanks for letting us know how the world works.  Much appreciated.

} Having separate trees also defeats the purpose of revision control.
} One is supposed to use branches (or whatever BitKeeper calls them)
} for stable, release, development, etc.

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

Re: linuxppc_2_5 source tree (and others)

[Albert D. Cahalan]

Cort Dougan writes:

> You should lose the chip from your shoulder if you want assistance.
> _2_5 was never listed that way, it was an internal tree only.

I'm sorry I was rude. Please try to imagine what PowerPC Linux
development must look like to someone who does not happen to
work for FSM Labs, Montevista, or BitKeeper.

>} I nearly fell into the trap. Just recently, 2_5 was listed as
>} being where the latest development happens. It certainly looked
>} that way too, with support for more boards than 2_4 had.
>} Until just this morning, I was thinking I ought to use 2_5!
>
> No-one should have used it and the people telling you that you
> should have used it shouldn't have done that.

It had 6750 support, and 2_4 didn't. I don't see why this
situation would ever be created, but anyway, clearly 2_5
was the better tree until it disappeared.

If you need to do experimental work without disturbing the rest
of the 2_4 code, you should be able to create a branch.

> Get on the list and you won't be caught unaware.  The _2_5 tree was
> never a "for outside use" tree.  Others were misinforming people, I
> know.  That was unfortuante but the _2_4_devel tree and the _2_4
> trees are both public and will not be "dead ends".  All changes that
> Linus will accept (not a simple job) do find their way to Linus
> eventually.

1. why was there a public tree that was not "for outside use"

2. how can you have two trees, neither of which is a dead end?

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

Re: linuxppc_2_5 source tree (and others)

[Cort Dougan]

Believe me, I know what it looks like.  I'm trying to clean things up but
it's a large problem.  I do appreciate your criticisms though, they are
useful in finding the worst parts.

Just to be clear, though, FSMLabs has nothing to do with Linux/PPC.  I just
happen to work here and use the web/ftp bandwidth.

} I'm sorry I was rude. Please try to imagine what PowerPC Linux
} development must look like to someone who does not happen to
} work for FSM Labs, Montevista, or BitKeeper.

Perhaps I can clear things up a bit.  I wanted _2_4 stable so that it
didn't get brand-new (untested and buggy) code.  I created _2_5 as a
work-area for us so people could push changes there, test them internally
and work out any problems.  We could then move them over to _2_4 quickly
when the changes were stable.  Unfortunately, people started giving out the
_2_5 tree and telling people to use it.

So, to solve that problem I created _2_4_devel so that we could get outside
testing and let users chose which kernel they wanted (brand-new features or
very stable and tested).

Unfortunately we need multiple trees since branches won't do the job for
us.  Lines of development will, though.  The people at BitMover and working
on that feature of BitKeeper for us already.

} It had 6750 support, and 2_4 didn't. I don't see why this
} situation would ever be created, but anyway, clearly 2_5
} was the better tree until it disappeared.
}
} If you need to do experimental work without disturbing the rest
} of the 2_4 code, you should be able to create a branch.

It wasn't a public tree, it should have stayed internal.  I did allow
outside access since all the developers except me are outside FSMLabs.
No-one was supposed to tell people to use it.  Often, it doesn't even
compile.  It's very experimental.  We're in the process of moving over the
code from that tree to the linuxppc_2_4_devel tree so no changes will be
lost.

} 1. why was there a public tree that was not "for outside use"

linuxppc_2_4 is a testing area before sending patches to Linus.  I never
want to have to revert a patch I've sent to Linus because it wasn't tested
and stable (Linus rarely takes patches as it is, I don't want to waste his
bandwidth).  linuxppc_2_4_devel is a working space before changes go to
linuxppc_2_4.

All changes that are stable and useful go to Linus in the end.  Not before
being tested and getting a good "beating around" first, though.

} 2. how can you have two trees, neither of which is a dead end?

When the real 2.5.0 comes out (when Linus creates it) I'll create another
tree, linuxppc_2_5.  I made a mistake in naming our experimental tree
linuxppc_2_5, this tree will be the real linuxppc_2_5.  We'll probably have
a linuxppc_2_5 and linuxppc_2_5_devel but that's still to be decided (it
will probably be decided by need).

So, I think that your short-term goal is to get the 6750 working, right?
linuxppc_2_4_devel should have what you need but if it doesn't it'll be
coming shortly.  You may also want to push MonteVista if you have a support
agreement with them on this board.

If the linuxppc_2_4_devel tree doesn't work for you let me know what
trouble you're having and I'll try to help.

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

Re: linuxppc_2_5 source tree (and others)

[Murray Jensen]

On Thu, 10 May 2001 17:11:14 -0600, Cort Dougan <cort@fsmlabs.com> writes:
>Believe me, I know what it looks like.  I'm trying to clean things up but
>it's a large problem.  I do appreciate your criticisms though, they are
>useful in finding the worst parts.

And we appreciate your efforts - thank you.

>Perhaps I can clear things up a bit.  I wanted _2_4 stable so that it
>didn't get brand-new (untested and buggy) code.  I created _2_5 as a
>work-area for us so people could push changes there, test them internally
>and work out any problems.  We could then move them over to _2_4 quickly
>when the changes were stable.  Unfortunately, people started giving out the
>_2_5 tree and telling people to use it.
>
>So, to solve that problem I created _2_4_devel so that we could get outside
>testing and let users chose which kernel they wanted (brand-new features or
>very stable and tested).

This is fair enough. I just didn't know what was going on. I have joined the
linuxppc-commit mailing list so I should be better informed in future.

Just as an aside, might this mean that it would be easier to get bk write
access to the _2_4_devel tree? (slight smiley :-).

>Unfortunately we need multiple trees since branches won't do the job for
>us.  Lines of development will, though.  The people at BitMover and working
>on that feature of BitKeeper for us already.

Except it looks like you only get LODs if you pay. The free version won't
have LODs - and a number of other nifty features (as far as I can tell).

>When the real 2.5.0 comes out (when Linus creates it) I'll create another
>tree, linuxppc_2_5.  I made a mistake in naming our experimental tree
>linuxppc_2_5, this tree will be the real linuxppc_2_5.  We'll probably have
>a linuxppc_2_5 and linuxppc_2_5_devel but that's still to be decided (it
>will probably be decided by need).

I actually guessed this was what had happened when I checked on kernel.org
and saw that there wasn't an official linux 2.5 yet (just some pre release
patches).

>If the linuxppc_2_4_devel tree doesn't work for you let me know what
>trouble you're having and I'll try to help.

Thanks for your response - you have cleared the matter up as far as I am
concerned. I feel much better about it all now - I will probably switch to
the _2_4_devel tree. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: linuxppc_2_5 source tree (and others)

[Cort Dougan]

I'm not sure what the current plan is at BitMover but I believe that's a
feature of BitKeeper/Pro but not BitKeeper/Open.  Linux developers
(possibly all open-source people) are able to get BitKeeper/Pro.

} Except it looks like you only get LODs if you pay. The free version won't
} have LODs - and a number of other nifty features (as far as I can tell).


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

Re: linuxppc_2_5 source tree (and others)

[Murray Jensen]

On Thu, 10 May 2001 21:14:08 -0600, Cort Dougan <cort@fsmlabs.com> writes:
>I'm not sure what the current plan is at BitMover but I believe that's a
>feature of BitKeeper/Pro but not BitKeeper/Open.

I don't know the exact situation either - all I can go on is their website,
which describes two versions of BitKeeper - BK/Pro and BK/Basic. The BK/Basic
page says it provides everything that BK/Pro does, except for:

        - Hierarchical repositories
        - Ability to resolve rename conflicts in anything other than
	  the master repository
        - Rollback
        - Global multi-site
        - Event triggers
        - LOD (line of development) support

There is also a description of BK/Web, which appears to be a third part.

Based on this, I am assuming that BK/Basic is (or will be) the free version,
and BK/Pro is (or will be) the commercial version that you must pay for.
It seems to me that it would be pointless to use BK/Basic only for the Linux
kernel - all this stuff, and LODs in particular, are too useful.

I have no problem with them selling software, and I quite like BitKeeper -
it feels right, like it has the correct approach to software version control
(at least in the case where there is a large number of distributed developers
and one single entity being developed consisting of a huge number of files -
exactly the case with the Linux source).

However, I would question the use of closed-source, non-free software to
develop open-source, free software - in effect, it makes the software being
developed (in this case Linux) closed and non-free - imagine, for example,
if you had the Linux source, but had to pay for a compiler to build it -
and not just any C compiler - you had to buy company X's compiler. Now I
know there are other methods available of getting the source besides BK
(rsync, ftp of tarballs, etc), but you don't get the version control info,
which I reckon is getting almost as essential as the compiler these days.

>Linux developers
>(possibly all open-source people) are able to get BitKeeper/Pro.

(I assume you mean for free - but obviously binary only; no source code)

This would be welcome - but how does one qualify as a "linux developer" or
an "open-source person"? If I can register for free with an independent
organisation and BitMover recognised this then great - but if it is left up
to BitMover to decide whether I qualify, this seems somewhat less than
satisfactory.

Sorry for rambling - this is really just an academic argument - the real
world rolls on... (we may even pay for BitKeeper :-) Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: linuxppc_2_5 source tree (and others)

[Tom Rini]

On Thu, May 10, 2001 at 03:46:54PM -0400, Albert D. Cahalan wrote:
> Tom Rini writes:
> > On Thu, May 10, 2001 at 02:40:05PM -0400, Albert D. Cahalan wrote:
>
> >> I'm very glad to have ignored this BitKeeper nonsense for
> >> the most part then. I knew there was a good reason to rely
> >> on the one true source tree from Linus. I'm not screwed like
> >> all the people working from linuxppc_2_5 are.
> >
> > Right.  But the "one true source tree from Linus" doesn't always
> > work for other arches.  Why?  Keeping stuff in 100% never works.
> > There almost always has been a slightly more up-to-date tree than
> > Linus' for ages (when did the first -ac patch come out, anyone
>
> The 2.2.14 kernel is over 15 months old. I'm expected to run
> Montevista's obsolete and severely hacked up 2.2.14 kernel if
> I want to use a PowerCore 6750. So "slightly more up-to-date"
> could mean over 15 months I guess.

No, but '2_5' is rather up to date, and should work fine.  MontaVista's
tree is what gets released with the official release.  There have been other
intermediate trees which haven't had the same quality testing the release
tree has.  But this really isn't about MVs trees, is it?  If so, this is a
rather odd way of going about it.  That said, I for for MV...

> > know?).  And, who exactly is screwed that's working from the old 2_5
> > tree?  There hasn't been any new activity in it for ages.
>
> I nearly fell into the trap. Just recently, 2_5 was listed as
> being where the latest development happens. It certainly looked
> that way too, with support for more boards than 2_4 had.
> Until just this morning, I was thinking I ought to use 2_5!

Well, you quite probably should for the moment since it should require little
work to get things working again in 2_4_devel.  In fact, if the board you're
working on doesn't have a 10x bridge on it, all the common files should be
there that you need.

> >   Shortly
> > (mainly once I'm done w/ finals) it'll be little more than exporting
> > your local changes from '2_5' and applying them in 2_4_devel.  Yes,
> > history bits will be lost, but such is life. :)
>
> That defeats the purpose of revision control. You might as
> well use "diff" and "patch" if you will be throwing away your
> version history.

Well, this wasn't my decision to make.

> >> On the other hand, I had to do my own PowerCore 6750 VME port for
> >> the 2.4 kernel. That sucked. It would be nice if everyone had the
> >> decency to submit stuff to Linus in a way that he finds acceptable,
> >> rather than hoarding source code in obscure places that are only
> >> accessible via non-standard non-free software.
> >
> > So use rsync and import into your own CVS tree.  I think it sucks
> > too that bk isn't gpl'ed, but hey.  I don't really care that much.
>
> The 2_2 and 2_4 trees were available via rsync, while 2_5 was not.

Oh, right.  I thought somneone else was going to put it up, but
oh well.

> > I'd wager your port would have sucked much less if you were working
> > off the 2_5 tree too (mvme5100 support is currently 4 mvme-specific
> > files, and some new common ones other boards use too.  Some pcore
> > boards are about as simple too).
>
> So now you are saying I should have used the 2_5 tree?????
> Wasn't I supposed to know (by psychic methods) that the 2_5
> tree is 'dead' now?

Not at all.  In fact, unless you did the port w/in the last month or so
2_5 was rather much alive.  And I could have sworn people have mentioned
the 2_5 tree on this list numerous times...  Also, hust because
the tree is dead doesn't mean that the inforemation in it
is dead too.  It'd just be a matter of exporting your changes and then
re-importing them.

> >> So, how did _you_ know that 2_5 has been 'dead' for a while?
> >
> > Well, it was on the linuxppc-commit list, which Cort has mentioned a
> > few time (hence it's majordomo now and not a sendmail alias like it
> > used to be).  It's even mentioned on the page that talks about the
> > bk trees: http://www.fsmlabs.com/linuxppcbk.html
>
> I figured that would be a list for automated check-in reports
> generated by the BitKeeper software.

It is.  It also functions as an as-hoc list to distribute BK info over.

> So anyway, we now have a 2_4_devel tree to wonder about.
> Might somebody suddenly decide to delete this tree too?
> Will changes get back to Linus, or is this a dead-end too?
>

Hopefully not, hopefully so.  Out of my area anyways.

> Having separate trees also defeats the purpose of revision control.
> One is supposed to use branches (or whatever BitKeeper calls them)
> for stable, release, development, etc.

BK does this by letting you use seperate trees.  You can import from the
parent into the child (ie pull main into dev).

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

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

Re: linuxppc_2_5 source tree (and others)

[Ira Weiny]

bk trees: http://www.fsmlabs.com/linuxppcbk.html

Are these trees designed to work "out of the box" on boards such as the
Walnut?

When configuring I don't see any options for the specific 405GP ethernet
for instance.

Also, do I need a password or something to get the devel tree?  Am I
allowed to get to the devel tree?

As per the instructions on the page (adding -azv):

$ rsync -azv bitkeeper.fsmlabs.com::linuxppc_2_4_devel
linuxppc_2_4_devel
@ERROR: Unknown module 'linuxppc_2_4_devel'
$ rsync bitkeeper.fsmlabs.com::
linuxppc_2_2
linuxppc_2_4
$

Thanks,
Ira Weiny

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

Re: linuxppc_2_5 source tree (and others)

[Cort Dougan]

Nope.  The _devel tree does mean it's a development tree with experimental
changes in it.  It will sometimes work, sometimes not.

The _2_4 tree will contain the changes we're more confident in and have
tested somewhat.

Only the _2_4_devel tree has the Walnut changes right now.

} Are these trees designed to work "out of the box" on boards such as the
} Walnut?
}
} When configuring I don't see any options for the specific 405GP ethernet
} for instance.

For read-only access, no password is necessary.  I fixed the rsync problem,
it's working now.

} Also, do I need a password or something to get the devel tree?  Am I
} allowed to get to the devel tree?
}
} As per the instructions on the page (adding -azv):
}
} $ rsync -azv bitkeeper.fsmlabs.com::linuxppc_2_4_devel
} linuxppc_2_4_devel
} @ERROR: Unknown module 'linuxppc_2_4_devel'
} $ rsync bitkeeper.fsmlabs.com::
} linuxppc_2_2
} linuxppc_2_4
} $

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