Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: > > I will attempt to build the tree between each merge (and a failed build > > will again cause the offending tree to be dropped). These builds will be > > necessarily restricted to probably one architecture/config. I will build > > the entire tree on as many architectures/configs as seem sensible and > > the results of that will be available on a web page (to be announced). > > This restriction means that the value for the ARM architecture is soo > limited it's probably not worth the hastle participating in this project. > > We already know that -mm picks up on very few ARM conflicts because > Andrew doesn't run through the entire set of configurations; unfortunately > ARM is one of those architectures which is very diverse [*], and because > of that, ideas like "allyconfig" are just completely irrelevant to it. > > As mentioned elsewhere, what we need for ARM is to extend the kautobuild > infrastructure (see armlinux.simtec.co.uk) so that we can have more trees > at least compile tested regularly - but that requires the folk there to > have additional compute power (which isn't going to happen unless folk > stamp up some machines _or_ funding). I now have an arm cross compiler (gcc-4.0.2-glibc-2.3.6 arm-unknown-linux-gnu). (See the results page at http://kisskb.ellerman.id.au/kisskb/branch/9/ - I must get a better name/place :-(.) Is this sufficient to help you out? What configs would be useful to build (as Andrew said, they don't take very long each). I really want as many subsystems as possible in the linux-next tree in an attempt to avoid some of the merge/conflict problems we have had in the past. What can we do to help? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp7FBm2sHObu.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: I will attempt to build the tree between each merge (and a failed build will again cause the offending tree to be dropped). These builds will be necessarily restricted to probably one architecture/config. I will build the entire tree on as many architectures/configs as seem sensible and the results of that will be available on a web page (to be announced). This restriction means that the value for the ARM architecture is soo limited it's probably not worth the hastle participating in this project. We already know that -mm picks up on very few ARM conflicts because Andrew doesn't run through the entire set of configurations; unfortunately ARM is one of those architectures which is very diverse [*], and because of that, ideas like allyconfig are just completely irrelevant to it. As mentioned elsewhere, what we need for ARM is to extend the kautobuild infrastructure (see armlinux.simtec.co.uk) so that we can have more trees at least compile tested regularly - but that requires the folk there to have additional compute power (which isn't going to happen unless folk stamp up some machines _or_ funding). I now have an arm cross compiler (gcc-4.0.2-glibc-2.3.6 arm-unknown-linux-gnu). (See the results page at http://kisskb.ellerman.id.au/kisskb/branch/9/ - I must get a better name/place :-(.) Is this sufficient to help you out? What configs would be useful to build (as Andrew said, they don't take very long each). I really want as many subsystems as possible in the linux-next tree in an attempt to avoid some of the merge/conflict problems we have had in the past. What can we do to help? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp7FBm2sHObu.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote: > > A third option would be if people add new functions (with no users) in > > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed > > patch with users that will use those new features in various kernel > > development trees. > >... > > I don't like suggestions based on unrealistic assumptions like > "a fully reviewed patch". > > E.g. userspace ABI's are much more stable and everyone is aware that > they must be gotten right with the first try since they are then cast in > stone - but we all remember the recent timerfd fiasco. I'm talking about kernel interfaces, not userspace API's. And we can change them if they are wrong, since they *are* kernel interfaces; but if they correct, they ease the cross-tree merge pain. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 07:13:16PM +0200, Adrian Bunk wrote: A third option would be if people add new functions (with no users) in -rc2 or -rc3 timeframes as long as it is part of a fully reviewed patch with users that will use those new features in various kernel development trees. ... I don't like suggestions based on unrealistic assumptions like a fully reviewed patch. E.g. userspace ABI's are much more stable and everyone is aware that they must be gotten right with the first try since they are then cast in stone - but we all remember the recent timerfd fiasco. I'm talking about kernel interfaces, not userspace API's. And we can change them if they are wrong, since they *are* kernel interfaces; but if they correct, they ease the cross-tree merge pain. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote: > On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: > > Two things may largely eliminate the need for parallel branches. > > > > 1. Do infrastructure changes and whole tree wide refactoring etc. in a > > compatible manner with a brief but nonzero transition period. > > > > 2. Insert a second merge window right after the usual merge window for > > changes which cannot be well done with a transition period. > > A third option would be if people add new functions (with no users) in > -rc2 or -rc3 timeframes as long as it is part of a fully reviewed > patch with users that will use those new features in various kernel > development trees. >... I don't like suggestions based on unrealistic assumptions like "a fully reviewed patch". E.g. userspace ABI's are much more stable and everyone is aware that they must be gotten right with the first try since they are then cast in stone - but we all remember the recent timerfd fiasco. > - Ted cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: > Two things may largely eliminate the need for parallel branches. > > 1. Do infrastructure changes and whole tree wide refactoring etc. in a > compatible manner with a brief but nonzero transition period. > > 2. Insert a second merge window right after the usual merge window for > changes which cannot be well done with a transition period. A third option would be if people add new functions (with no users) in -rc2 or -rc3 timeframes as long as it is part of a fully reviewed patch with users that will use those new features in various kernel development trees. Since there wouldn't be any users in Linus's tree, there's no risk in making those functions available in mainline ahead of time. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Stephen Rothwell wrote: > On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> > wrote: >> >> I absolutely have no problem with having a "this is the infrastrcture >> changes that will go into the next release". In fact, I can even >> *maintain* such a branch. >> >> I've not wanted to open up a second branch for "this is for next release", >> because quite frankly, one of the other problems we have is that people >> already spend way too much time on the next release compared to just >> looking at regressions in the current one. But especially if we're talking >> about _purely_ API changes etc infrastructure, I could certainly do a >> "next" branch. > > So, will you open such a branch? If so, what would be the mechanics of > having patches applied to it? I assume people would have to suggest such > changes explicitly and have them reviewed (hopefully more thoroughly than > usual) in that light. I guess one place these "infrastructure" changes > may be noticed would be when subsystem maintainers stray outside their > subsystem in what they submit to the linux-next tree (or break it). Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. (I probably missed a number of points why these two things are not always feasible, because I am just a downstream person.) -- Stefan Richter -=-==--- --=- =-=-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Linus, On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > I absolutely have no problem with having a "this is the infrastrcture > changes that will go into the next release". In fact, I can even > *maintain* such a branch. > > I've not wanted to open up a second branch for "this is for next release", > because quite frankly, one of the other problems we have is that people > already spend way too much time on the next release compared to just > looking at regressions in the current one. But especially if we're talking > about _purely_ API changes etc infrastructure, I could certainly do a > "next" branch. So, will you open such a branch? If so, what would be the mechanics of having patches applied to it? I assume people would have to suggest such changes explicitly and have them reviewed (hopefully more thoroughly than usual) in that light. I guess one place these "infrastructure" changes may be noticed would be when subsystem maintainers stray outside their subsystem in what they submit to the linux-next tree (or break it). Then I assume most people would start working on a merge of this "next" branch and your "master" branch, right? Consequently, each linux-next would also be based on that merge. I suppose I am stating the obvious (or asking the dumb questions), but I always find it easier to have explicit answers to these sorts of things. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpiLBYcwEqCv.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Linus, On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: I absolutely have no problem with having a this is the infrastrcture changes that will go into the next release. In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for this is for next release, because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a next branch. So, will you open such a branch? If so, what would be the mechanics of having patches applied to it? I assume people would have to suggest such changes explicitly and have them reviewed (hopefully more thoroughly than usual) in that light. I guess one place these infrastructure changes may be noticed would be when subsystem maintainers stray outside their subsystem in what they submit to the linux-next tree (or break it). Then I assume most people would start working on a merge of this next branch and your master branch, right? Consequently, each linux-next would also be based on that merge. I suppose I am stating the obvious (or asking the dumb questions), but I always find it easier to have explicit answers to these sorts of things. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpiLBYcwEqCv.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
Stephen Rothwell wrote: On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] wrote: I absolutely have no problem with having a this is the infrastrcture changes that will go into the next release. In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for this is for next release, because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a next branch. So, will you open such a branch? If so, what would be the mechanics of having patches applied to it? I assume people would have to suggest such changes explicitly and have them reviewed (hopefully more thoroughly than usual) in that light. I guess one place these infrastructure changes may be noticed would be when subsystem maintainers stray outside their subsystem in what they submit to the linux-next tree (or break it). Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. (I probably missed a number of points why these two things are not always feasible, because I am just a downstream person.) -- Stefan Richter -=-==--- --=- =-=-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. A third option would be if people add new functions (with no users) in -rc2 or -rc3 timeframes as long as it is part of a fully reviewed patch with users that will use those new features in various kernel development trees. Since there wouldn't be any users in Linus's tree, there's no risk in making those functions available in mainline ahead of time. - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 20, 2008 at 10:42:35AM -0500, Theodore Tso wrote: On Wed, Feb 20, 2008 at 04:38:52PM +0100, Stefan Richter wrote: Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. A third option would be if people add new functions (with no users) in -rc2 or -rc3 timeframes as long as it is part of a fully reviewed patch with users that will use those new features in various kernel development trees. ... I don't like suggestions based on unrealistic assumptions like a fully reviewed patch. E.g. userspace ABI's are much more stable and everyone is aware that they must be gotten right with the first try since they are then cast in stone - but we all remember the recent timerfd fiasco. - Ted cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Frank Seidel wrote: > Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they > also really hope - at least i very strongly do - you not only call on us when > things become a burden, but let us help and assist you right from the start. I just started a little naive webpage where i collected some of the main infos about linux-next on http://linux.f-seidel.de/linux-next/ while the wiki there is probably the best filled part. Does this make any sense to you to continue this? Or do you already have something else in mind or even already prepared? Thanks, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Frank Seidel wrote: Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they also really hope - at least i very strongly do - you not only call on us when things become a burden, but let us help and assist you right from the start. I just started a little naive webpage where i collected some of the main infos about linux-next on http://linux.f-seidel.de/linux-next/ while the wiki there is probably the best filled part. Does this make any sense to you to continue this? Or do you already have something else in mind or even already prepared? Thanks, Frank -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote: > Hi James, > > On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > > > Do you have the tree and build logs available anywhere? I'd like to > > turn off the merge tree builds when this is able to replace it. > > The tree is at > git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did > you mean the logs of creating the tree. Yes, the logs of creating the tree. > I currently ceate the tree > fairly manually (as I slowly script what can be) and so have no logs of > that process. Um, well, I've already pointed to tools that currently do this bit automatically. Do you have a list of input trees anywhere? > The build logs that I have some control over are at > http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on > the arch/config combinations over time (I have to convince my tame cross > compiler builder :-)). I also hope that others will build this tree for > themselves and publish the results. Oh, OK ... by build I mean combine the trees and quilts into the actual tree. Compiling is nice, but it's the tree construction logs I want to see to make sure there aren't any impending merge problems. Most people verify on a fairly constant basis that their own trees actually build. The only problems we have are edge configurations (like arm and sparc, which have SCSI drivers that don't build except on those architectures). James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote: > Hm ... I think net is a counter example to this. Rebases certainly work > for them. That's a matter of opinion. I'm working on cleaning up the libertas driver as and when I have time, and the constant rebasing of the git trees effectively means that I can't just use git as it was intended; I feel that I'm being forced back into the 1990s by having to deal with sequences of patches instead. It's such a pain that I'm seriously tempted to push my changes directly to Linus instead of through the subsystem maintainers. -- dwmw2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 12:24 -0600, James Bottomley wrote: Hm ... I think net is a counter example to this. Rebases certainly work for them. That's a matter of opinion. I'm working on cleaning up the libertas driver as and when I have time, and the constant rebasing of the git trees effectively means that I can't just use git as it was intended; I feel that I'm being forced back into the 1990s by having to deal with sequences of patches instead. It's such a pain that I'm seriously tempted to push my changes directly to Linus instead of through the subsystem maintainers. -- dwmw2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sun, 2008-02-17 at 16:25 +1100, Stephen Rothwell wrote: Hi James, On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley [EMAIL PROTECTED] wrote: Do you have the tree and build logs available anywhere? I'd like to turn off the merge tree builds when this is able to replace it. The tree is at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did you mean the logs of creating the tree. Yes, the logs of creating the tree. I currently ceate the tree fairly manually (as I slowly script what can be) and so have no logs of that process. Um, well, I've already pointed to tools that currently do this bit automatically. Do you have a list of input trees anywhere? The build logs that I have some control over are at http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on the arch/config combinations over time (I have to convince my tame cross compiler builder :-)). I also hope that others will build this tree for themselves and publish the results. Oh, OK ... by build I mean combine the trees and quilts into the actual tree. Compiling is nice, but it's the tree construction logs I want to see to make sure there aren't any impending merge problems. Most people verify on a fairly constant basis that their own trees actually build. The only problems we have are edge configurations (like arm and sparc, which have SCSI drivers that don't build except on those architectures). James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi James, On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > Do you have the tree and build logs available anywhere? I'd like to > turn off the merge tree builds when this is able to replace it. The tree is at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did you mean the logs of creating the tree. I currently ceate the tree fairly manually (as I slowly script what can be) and so have no logs of that process. The build logs that I have some control over are at http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on the arch/config combinations over time (I have to convince my tame cross compiler builder :-)). I also hope that others will build this tree for themselves and publish the results. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpCWLR46O0ph.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote: > Hi Roland, > > On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > > > For InfiniBand/RDMA, the tree is: > > > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git > > for-next > > > > or via git protocol: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > > for-next > > > > contact addresses (me plus a mailing list): > > > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > Added, thanks. Do you have the tree and build logs available anywhere? I'd like to turn off the merge tree builds when this is able to replace it. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote: > On Tue, 12 Feb 2008, Greg KH wrote: > > On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: > > > On Tue, 12 Feb 2008, Greg KH wrote: > > > > Perhaps you need to switch to using quilt. This is the main reason why > > > > I use it. > > > > > > Btw, on that note: if some quilt user can send an "annotated history > > > file" > > > of their quilt usage, it's something that git really can do, and I'll see > > > if I can merge (or rather, coax Junio to merge) the relevant part of > > > stgit > > > to make it possible to just basically get "quilt behaviour" for the parts > > > of a git tree that you haven't pushed out yet. > > > > Ted's description matches mine (keep quilt tree in git, edit changelog > > entries, rebase on newer kernel versions, etc.) I can go into details > > if needed. > > Ack. Same for PS3 and m68k (except I don't have the m68k patches in git > (yet)). > > Two issues with using quilt: > 1. Sometimes a patch still applies after it was integrated upstream, Add QUILT_PATCH_OPTS="--fuzz=0" to your ~/.quiltrc file. The default is fuzz=2 IIRC which tries to be too clever. I set fuzz to 0 after I got burned by an unnoticed "quilt patched it somewhere else" bug, which took me half a day to figure out. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote: > On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > > On Sat, 16 Feb 2008 00:09:43 + > > Russell King <[EMAIL PROTECTED]> wrote: > > > > > For reference, even _I_ don't build test the entire set of ARM defconfigs > > > - > > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > > just build those which are important to myself, hope that the others are > > > fine, and rely on kautobuild finding any breakage. > > > > > > > you need a better box ;) > > > > cerfcube_defconfig: 35 seconds > > carmeva_defconfig: 23 seconds > > spitz_defconfig (one of the biggest): 45 seconds > > > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > > coverage? > > I do this wildcard together with > > yes '' | make ARCH=arm ... oldconfig > make > > Sans toolchain issues, it's pretty good -- Russell larts you when some > defconfig becomes broken anyway. :^) Only when I check the kautobuild website - which I've not been doing regularly since about end of November, and it only covers Linus' kernels. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, Feb 16, 2008 at 03:42:49AM +0300, Alexey Dobriyan wrote: On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote: For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig: 23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? I do this wildcard together with yes '' | make ARCH=arm ... oldconfig make Sans toolchain issues, it's pretty good -- Russell larts you when some defconfig becomes broken anyway. :^) Only when I check the kautobuild website - which I've not been doing regularly since about end of November, and it only covers Linus' kernels. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, 13 Feb 2008, Geert Uytterhoeven wrote: On Tue, 12 Feb 2008, Greg KH wrote: On Tue, Feb 12, 2008 at 04:49:46PM -0800, Linus Torvalds wrote: On Tue, 12 Feb 2008, Greg KH wrote: Perhaps you need to switch to using quilt. This is the main reason why I use it. Btw, on that note: if some quilt user can send an annotated history file of their quilt usage, it's something that git really can do, and I'll see if I can merge (or rather, coax Junio to merge) the relevant part of stgit to make it possible to just basically get quilt behaviour for the parts of a git tree that you haven't pushed out yet. Ted's description matches mine (keep quilt tree in git, edit changelog entries, rebase on newer kernel versions, etc.) I can go into details if needed. Ack. Same for PS3 and m68k (except I don't have the m68k patches in git (yet)). Two issues with using quilt: 1. Sometimes a patch still applies after it was integrated upstream, Add QUILT_PATCH_OPTS=--fuzz=0 to your ~/.quiltrc file. The default is fuzz=2 IIRC which tries to be too clever. I set fuzz to 0 after I got burned by an unnoticed quilt patched it somewhere else bug, which took me half a day to figure out. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 2008-02-15 at 12:02 +1100, Stephen Rothwell wrote: Hi Roland, On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier [EMAIL PROTECTED] wrote: For InfiniBand/RDMA, the tree is: master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next or via git protocol: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-next contact addresses (me plus a mailing list): [EMAIL PROTECTED] [EMAIL PROTECTED] Added, thanks. Do you have the tree and build logs available anywhere? I'd like to turn off the merge tree builds when this is able to replace it. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi James, On Sat, 16 Feb 2008 09:14:32 -0600 James Bottomley [EMAIL PROTECTED] wrote: Do you have the tree and build logs available anywhere? I'd like to turn off the merge tree builds when this is able to replace it. The tree is at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git - or did you mean the logs of creating the tree. I currently ceate the tree fairly manually (as I slowly script what can be) and so have no logs of that process. The build logs that I have some control over are at http://kisskb.ellerman.id.au/kisskb/branch/9/. I am hoping to expand on the arch/config combinations over time (I have to convince my tame cross compiler builder :-)). I also hope that others will build this tree for themselves and publish the results. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] pgpCWLR46O0ph.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:31:36 + Russell King <[EMAIL PROTECTED]> wrote: > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > > coverage? > > It will certainly improve the situation significantly, and pick up > on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): OK, I'll toss something together. > the latter seems to be because the PCMCIA changes were lost > on the linux-pcmcia list and the trizeps folk have probably given up. I appear to be pcmcia maintainer lately so if someone wants to dust them off and send them over we can see what we can do? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) > > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? I do this wildcard together with yes '' | make ARCH=arm ... oldconfig make Sans toolchain issues, it's pretty good -- Russell larts you when some defconfig becomes broken anyway. :^) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: > On Sat, 16 Feb 2008 00:09:43 + > Russell King <[EMAIL PROTECTED]> wrote: > > > For reference, even _I_ don't build test the entire set of ARM defconfigs - > > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > > just build those which are important to myself, hope that the others are > > fine, and rely on kautobuild finding any breakage. > > > > you need a better box ;) Maybe - it's a lowly 2.6GHz P4 with 1GB RAM, ICH5, and SATA disk. > cerfcube_defconfig: 35 seconds > carmeva_defconfig:23 seconds > spitz_defconfig (one of the biggest): 45 seconds > > so would a stupid `for i in arch/arm/configs/*' script be sufficient > coverage? It will certainly improve the situation significantly, and pick up on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): drivers/built-in.o: In function `v4l2_i2c_attach': drivers/media/video/v4l2-common.c:1035: undefined reference to `i2c_attach_client' Currently, the defconfigs known to fail (long term) in Linus' tree are clps7500_defconfig and trizeps4_defconfig - the former I'm tempted to remove, the latter seems to be because the PCMCIA changes were lost on the linux-pcmcia list and the trizeps folk have probably given up. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. Does that mean that an artificial allarmconfig can't be made to build? We clearly don't care whether it can boot or work, but we would just as clearly like to be able to build more ARM stuff without N (N > 10) configs. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: > On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > > I wonder why I didn't see any of this - I build arm allmodconfig at least > > once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. > > So either the offending patches weren't in my pile or arm allmodconfig is > > worse than I thought :( > > > > It really is in arch maintainers' best interest to keep their allmodconfig > > in good shape, for this reason. arm's _isn't_ in good shape: the compile > > fails for several long-standing reasons (eg: no hope of building DRM) and I > > don't think the coverage is very broad either. > > I think that Russell has said that allmodconfig isn't very realistic > for ARM, with its 70+ config files. Nevertheless, having a usable > allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote: > For reference, even _I_ don't build test the entire set of ARM defconfigs - > at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I > just build those which are important to myself, hope that the others are > fine, and rely on kautobuild finding any breakage. > you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig: 23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:05:59 +0100 Roel Kluin <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > >> Evolution in nature and changes in code are different because in code junk > >> and bugs are constantly removed. In biology junk is allowed and may provide > >> a pool for future development. Linux development is intended and not > >> survival. > > > > I would be interested to see any evidence (rather than intuition) to > > support that, given that both appear to be the same kind of structure and > > that structure is nowadays fairly well understood. > > What do you mean with structure, the evolution? that both are a language? No that they show the same mathematical structure and behaviour - both are scale free networks. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:47:24 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > > > On Fri, 15 Feb 2008 23:23:08 + > > Russell King <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > > > I have tried, and successfully done this many times in the past. The > > > > kobject change was one example: add a new function, migrate all users of > > > > a direct pointer over to that function, after that work is all done and > > > > in, change the structure and do the needed work afterward. All is > > > > bisectable completly, with no big "flag day" needed. > > > > > > Incorrect - because this all happened far too quickly. This is one of > > > the reasons that I ended up having to redo various parts of the ARM tree > > > because stuff broke - set_kset_name() completely vanished introducing > > > compile errors, and iirc some merge issues as well. > > > > > > I had patches introducing new system objects which use that, and > > > modifications extremely close to other uses in the PXA code. > > > > > > The end result (through rebuilding the affected parts of my git tree, and > > > asking people for replacement patches) was something that is bisectable - > > > but had I tried to merge stuff as is, it would've been an utter mess, and > > > _was_ unbuildable. > > > > > > > I wonder why I didn't see any of this - I build arm allmodconfig at least > > once a week, usually more frequently. > > > > So either the offending patches weren't in my pile or arm allmodconfig is > > worse than I thought :( > > > > It really is in arch maintainers' best interest to keep their allmodconfig > > in good shape, for this reason. arm's _isn't_ in good shape: the compile > > fails for several long-standing reasons (eg: no hope of building DRM) and I > > don't think the coverage is very broad either. > > I think that Russell has said that allmodconfig isn't very realistic > for ARM, with its 70+ config files. You'd need to pick one board support and enable everything else you possibly can. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: > I will attempt to build the tree between each merge (and a failed build > will again cause the offending tree to be dropped). These builds will be > necessarily restricted to probably one architecture/config. I will build > the entire tree on as many architectures/configs as seem sensible and > the results of that will be available on a web page (to be announced). This restriction means that the value for the ARM architecture is soo limited it's probably not worth the hastle participating in this project. We already know that -mm picks up on very few ARM conflicts because Andrew doesn't run through the entire set of configurations; unfortunately ARM is one of those architectures which is very diverse [*], and because of that, ideas like "allyconfig" are just completely irrelevant to it. As mentioned elsewhere, what we need for ARM is to extend the kautobuild infrastructure (see armlinux.simtec.co.uk) so that we can have more trees at least compile tested regularly - but that requires the folk there to have additional compute power (which isn't going to happen unless folk stamp up some machines _or_ funding). More trees maintained by more people isn't going to help the situation - if anything, it's going to make it worse - more trees needing more testing by the already extremely limited resources we have available. For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. * - plus, its very difficult to get maintainers to see why having a kernel able to support multiple platforms is a good thing. For example, I would absolutely love to be able to combine more platforms into one build (such as Lubbock, Mainstone and probably other PXA stuff), but there's issues with drivers preventing it. (For those two I just mentioned, it's the SMC91x net driver whose build needs to be configured to the precise machine due to the multitude of different ways to connect the hardware to the processor.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: > On Fri, 15 Feb 2008 23:23:08 + > Russell King <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > > I have tried, and successfully done this many times in the past. The > > > kobject change was one example: add a new function, migrate all users of > > > a direct pointer over to that function, after that work is all done and > > > in, change the structure and do the needed work afterward. All is > > > bisectable completly, with no big "flag day" needed. > > > > Incorrect - because this all happened far too quickly. This is one of > > the reasons that I ended up having to redo various parts of the ARM tree > > because stuff broke - set_kset_name() completely vanished introducing > > compile errors, and iirc some merge issues as well. > > > > I had patches introducing new system objects which use that, and > > modifications extremely close to other uses in the PXA code. > > > > The end result (through rebuilding the affected parts of my git tree, and > > asking people for replacement patches) was something that is bisectable - > > but had I tried to merge stuff as is, it would've been an utter mess, and > > _was_ unbuildable. > > > > I wonder why I didn't see any of this - I build arm allmodconfig at least > once a week, usually more frequently. > > So either the offending patches weren't in my pile or arm allmodconfig is > worse than I thought :( > > It really is in arch maintainers' best interest to keep their allmodconfig > in good shape, for this reason. arm's _isn't_ in good shape: the compile > fails for several long-standing reasons (eg: no hope of building DRM) and I > don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. --- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 23:23:08 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > > I have tried, and successfully done this many times in the past. The > > kobject change was one example: add a new function, migrate all users of > > a direct pointer over to that function, after that work is all done and > > in, change the structure and do the needed work afterward. All is > > bisectable completly, with no big "flag day" needed. > > Incorrect - because this all happened far too quickly. This is one of > the reasons that I ended up having to redo various parts of the ARM tree > because stuff broke - set_kset_name() completely vanished introducing > compile errors, and iirc some merge issues as well. > > I had patches introducing new system objects which use that, and > modifications extremely close to other uses in the PXA code. > > The end result (through rebuilding the affected parts of my git tree, and > asking people for replacement patches) was something that is bisectable - > but had I tried to merge stuff as is, it would've been an utter mess, and > _was_ unbuildable. > I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > I have tried, and successfully done this many times in the past. The > kobject change was one example: add a new function, migrate all users of > a direct pointer over to that function, after that work is all done and > in, change the structure and do the needed work afterward. All is > bisectable completly, with no big "flag day" needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Alan Cox wrote: >> Evolution in nature and changes in code are different because in code junk >> and bugs are constantly removed. In biology junk is allowed and may provide >> a pool for future development. Linux development is intended and not >> survival. > > I would be interested to see any evidence (rather than intuition) to > support that, given that both appear to be the same kind of structure and > that structure is nowadays fairly well understood. What do you mean with structure, the evolution? that both are a language? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Linus Torvalds wrote: > > On Wed, 13 Feb 2008, Roel Kluin wrote: >> In nature there is a lot of duplication: several copies of genes can exist >> and different copies may have a distinct evolution. > > This is true of very complex animals, but much less so when looking at > things like bacteria (and arguably, any current sw project is closer to > bacteria in complexity than anything mammalian). > > In bacteria (and viruses), duplication of DNA/RNA is a big cost of living > in general, and as a result there is *much* less junk DNA. So in an > evolutionary sense, it's much closer to what the kernel should have (with > occasional duplication of code and interfaces to allow new functionality, > but rather aggressive pruning of the excess baggage). I like the comparison, and while I wrote my comment I have to admit I was also thinking of bacteria and virusses as an exception: There the speed of replication can be an important factor for survival. Less DNA means faster replication and therefore the pressure is on removal of junk DNA. It can be disputed however that removal of 'junk sourcecode' is a survival factor for the linux kernel but the benefit may be disputable as well. > In other words, all of these choices are a matter of "balance". In some > areas, excess code is not a sufficient downside, and we keep even broken > source code around with no actual function, "just because" (or rather, > because the cost of carrying it around is so small that nobody cares). > > That's true in the kernel as in biology: check out not just deprecated > code, but the drivers and other odds-and-ends that are explicitly marked > as non-coding DNA (we just happen to call them BROKEN in our Kconfig). > > Linus Maybe we can elaborate a bit on this comparison, just for fun: I think not the linux kernel alone, but rather the entire Linux OS could be compared with a cell. The kernel source encodes vital software parts including the interactions with hardware - the environment for the computer. Gcc can be compared with the (transcription and) translation machinery. DNA can be seen as a language that encodes proteins, with biological functions: Some are vital, including ones that allow interactions with the environment: The cellular environment is beyond the membrane. Interactions occur through membrane receptors, channels, etc. Interaction between proteins can be compared with functions selectively calling other functions. Activation of certain proteins can cause a cascade of protein interactions, comparable with function calls in a loop: the activated protein activates particular protein(s) several times. Some proteins influence intracellular messengers: cellular global variables. Transmembrane receptors responding to extracellular signals transmit this through conformational changes across the membrane to the intracellular region: These structural changes may allow interactions with new proteins. Maybe comparable with a combination of hardware interrupts, signals and the userspace? The response to extracellular signals often depends on several sequential interactions between proteins. This provides a protective layer that can be compared with the kernelspace layer. This is where the comparison probably becomes too biased to continue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote: > One idea that I thought about when debating rebase vs. merge (and it's > far far from being fully baked) is versioned commits. The gist of it > is that patches are assigned an hash identifier like today when they > are first committed into the tree, but, and this is the main change: > if they mutate, e.g. by a rebase, or even git commit --amend, their > version is bumped up rather than SHA changed. The SHA1 is uniquely determined by the contents of that commit--commit and author names and times, changelog message, snapshot of the tree at that point, and parents--hence, recursively, by the entire history leading up to that commit. Naming objects by their content in that way has a lot of advantages--for example, you can sign an entire history by signing just the SHA1 of the commit at its tip. So you can't break that link between the names of commits and their contents without ending up with a fundamentally different (and probably weaker, in some sense), system. I suspect there's an unavoidable tradeoff--if you want to be able to reliably and efficiently determine how two branches are related, then you can't just throw away their (possibly messy) history. The best you may be able to do, if you want the advantages of both rebasing and merging, is to maintain on your own the messier meta-history as a superset of the simpler history that you end up submitting. --b. > This way all versions of the commit would be accessible and addressable using > their respective SHA *and* version. I think that this can help keep > the tree's history in a more intuitive way (since the patches' base identifier > won't change, just its version number), and you get a bonus of seeing each > commit's history, who changed it, and what was the change. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said: > On Friday 15 February 2008, [EMAIL PROTECTED] wrote: > >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are > >> appearing to indicate its not a problem until some distro actually ships a > >> kernel with the changes that broke it. That could be months or even a > >> year plus. > > > >Actually following the NVidia forums indicates otherwise: > > > >http://www.nvnews.net/vbulletin/showthread.php?t=107144 > > > >I expect Zander will be posting a patch rather soonish, for some value of > >soonish. And if you're running a -rc or -mm kernel, patching the 169.09 > >drivers should be well within your abilities > > Not so for the binaries, existing patches do make it compile but it still > upchucks someplace in the binary, or was this time yesterday. Umm.. if you actually *read* the mentioned thread, you'll see that "existing patches" are known to be incomplete, complete with the "upchucks in the binary" (mentioned at entry number 9 of the thread), and that Zander already knows about it (entry #11), and has apparently one remaining issue left to resolve (entries #32 and #36). And entry #36 is what the NVidia engineer doing the work was thinking about 20 hours ago. Interpret it as you will... pgpL0bWoIfZJW.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Friday 15 February 2008, [EMAIL PROTECTED] wrote: >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are >> appearing to indicate its not a problem until some distro actually ships a >> kernel with the changes that broke it. That could be months or even a >> year plus. > >Actually following the NVidia forums indicates otherwise: > >http://www.nvnews.net/vbulletin/showthread.php?t=107144 > >I expect Zander will be posting a patch rather soonish, for some value of >soonish. And if you're running a -rc or -mm kernel, patching the 169.09 >drivers should be well within your abilities Not so for the binaries, existing patches do make it compile but it still upchucks someplace in the binary, or was this time yesterday. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) It is not well to be thought of as one who meekly submits to insolence and intimidation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Friday 15 February 2008, [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities Not so for the binaries, existing patches do make it compile but it still upchucks someplace in the binary, or was this time yesterday. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) It is not well to be thought of as one who meekly submits to insolence and intimidation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said: On Friday 15 February 2008, [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities Not so for the binaries, existing patches do make it compile but it still upchucks someplace in the binary, or was this time yesterday. Umm.. if you actually *read* the mentioned thread, you'll see that existing patches are known to be incomplete, complete with the upchucks in the binary (mentioned at entry number 9 of the thread), and that Zander already knows about it (entry #11), and has apparently one remaining issue left to resolve (entries #32 and #36). And entry #36 is what the NVidia engineer doing the work was thinking about 20 hours ago. Interpret it as you will... pgpL0bWoIfZJW.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 07:35:03PM +0200, Benny Halevy wrote: One idea that I thought about when debating rebase vs. merge (and it's far far from being fully baked) is versioned commits. The gist of it is that patches are assigned an hash identifier like today when they are first committed into the tree, but, and this is the main change: if they mutate, e.g. by a rebase, or even git commit --amend, their version is bumped up rather than SHA changed. The SHA1 is uniquely determined by the contents of that commit--commit and author names and times, changelog message, snapshot of the tree at that point, and parents--hence, recursively, by the entire history leading up to that commit. Naming objects by their content in that way has a lot of advantages--for example, you can sign an entire history by signing just the SHA1 of the commit at its tip. So you can't break that link between the names of commits and their contents without ending up with a fundamentally different (and probably weaker, in some sense), system. I suspect there's an unavoidable tradeoff--if you want to be able to reliably and efficiently determine how two branches are related, then you can't just throw away their (possibly messy) history. The best you may be able to do, if you want the advantages of both rebasing and merging, is to maintain on your own the messier meta-history as a superset of the simpler history that you end up submitting. --b. This way all versions of the commit would be accessible and addressable using their respective SHA *and* version. I think that this can help keep the tree's history in a more intuitive way (since the patches' base identifier won't change, just its version number), and you get a bonus of seeing each commit's history, who changed it, and what was the change. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Linus Torvalds wrote: On Wed, 13 Feb 2008, Roel Kluin wrote: In nature there is a lot of duplication: several copies of genes can exist and different copies may have a distinct evolution. This is true of very complex animals, but much less so when looking at things like bacteria (and arguably, any current sw project is closer to bacteria in complexity than anything mammalian). In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). I like the comparison, and while I wrote my comment I have to admit I was also thinking of bacteria and virusses as an exception: There the speed of replication can be an important factor for survival. Less DNA means faster replication and therefore the pressure is on removal of junk DNA. It can be disputed however that removal of 'junk sourcecode' is a survival factor for the linux kernel but the benefit may be disputable as well. In other words, all of these choices are a matter of balance. In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, just because (or rather, because the cost of carrying it around is so small that nobody cares). That's true in the kernel as in biology: check out not just deprecated code, but the drivers and other odds-and-ends that are explicitly marked as non-coding DNA (we just happen to call them BROKEN in our Kconfig). Linus Maybe we can elaborate a bit on this comparison, just for fun: I think not the linux kernel alone, but rather the entire Linux OS could be compared with a cell. The kernel source encodes vital software parts including the interactions with hardware - the environment for the computer. Gcc can be compared with the (transcription and) translation machinery. DNA can be seen as a language that encodes proteins, with biological functions: Some are vital, including ones that allow interactions with the environment: The cellular environment is beyond the membrane. Interactions occur through membrane receptors, channels, etc. Interaction between proteins can be compared with functions selectively calling other functions. Activation of certain proteins can cause a cascade of protein interactions, comparable with function calls in a loop: the activated protein activates particular protein(s) several times. Some proteins influence intracellular messengers: cellular global variables. Transmembrane receptors responding to extracellular signals transmit this through conformational changes across the membrane to the intracellular region: These structural changes may allow interactions with new proteins. Maybe comparable with a combination of hardware interrupts, signals and the userspace? The response to extracellular signals often depends on several sequential interactions between proteins. This provides a protective layer that can be compared with the kernelspace layer. This is where the comparison probably becomes too biased to continue. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Alan Cox wrote: Evolution in nature and changes in code are different because in code junk and bugs are constantly removed. In biology junk is allowed and may provide a pool for future development. Linux development is intended and not survival. I would be interested to see any evidence (rather than intuition) to support that, given that both appear to be the same kind of structure and that structure is nowadays fairly well understood. What do you mean with structure, the evolution? that both are a language? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: I have tried, and successfully done this many times in the past. The kobject change was one example: add a new function, migrate all users of a direct pointer over to that function, after that work is all done and in, change the structure and do the needed work afterward. All is bisectable completly, with no big flag day needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 23:23:08 + Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: I have tried, and successfully done this many times in the past. The kobject change was one example: add a new function, migrate all users of a direct pointer over to that function, after that work is all done and in, change the structure and do the needed work afterward. All is bisectable completly, with no big flag day needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote: I will attempt to build the tree between each merge (and a failed build will again cause the offending tree to be dropped). These builds will be necessarily restricted to probably one architecture/config. I will build the entire tree on as many architectures/configs as seem sensible and the results of that will be available on a web page (to be announced). This restriction means that the value for the ARM architecture is soo limited it's probably not worth the hastle participating in this project. We already know that -mm picks up on very few ARM conflicts because Andrew doesn't run through the entire set of configurations; unfortunately ARM is one of those architectures which is very diverse [*], and because of that, ideas like allyconfig are just completely irrelevant to it. As mentioned elsewhere, what we need for ARM is to extend the kautobuild infrastructure (see armlinux.simtec.co.uk) so that we can have more trees at least compile tested regularly - but that requires the folk there to have additional compute power (which isn't going to happen unless folk stamp up some machines _or_ funding). More trees maintained by more people isn't going to help the situation - if anything, it's going to make it worse - more trees needing more testing by the already extremely limited resources we have available. For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. * - plus, its very difficult to get maintainers to see why having a kernel able to support multiple platforms is a good thing. For example, I would absolutely love to be able to combine more platforms into one build (such as Lubbock, Mainstone and probably other PXA stuff), but there's issues with drivers preventing it. (For those two I just mentioned, it's the SMC91x net driver whose build needs to be configured to the precise machine due to the multitude of different ways to connect the hardware to the processor.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: On Fri, 15 Feb 2008 23:23:08 + Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: I have tried, and successfully done this many times in the past. The kobject change was one example: add a new function, migrate all users of a direct pointer over to that function, after that work is all done and in, change the structure and do the needed work afterward. All is bisectable completly, with no big flag day needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. --- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote: For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig: 23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: On Fri, Feb 15, 2008 at 03:47:24PM -0800, Randy Dunlap wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. Basically, you don't build any of the PXA platforms, which is what was affected. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. Nevertheless, having a usable allmodconfig would be very helpful. Which is quite impossible. I've said all along that all*config is bad news for ARM and folk haven't listened. allmodconfig can (and does) work on some platform configurations such as the one Andrew builds - which will be based on the Versatile platform. However, that doesn't get _any_ of the PXA SoC drivers scattered throughout the tree, the PXA SoC support in arch/arm/mach-pxa, none of the PXA platform support files. If you built an allmodconfig PXA configuration, you'd get those, but you wouldn't get the OMAP SoC drivers, nor the ARM Primecell drivers found on ARMs Integrator, Versatile and Realview platforms and the Cirrus EP93xx SoCs. Nor the Atmel AT91 drivers... and so the list goes on. Each family of platforms are, unfortunately, quite distinct from each other. Does that mean that an artificial allarmconfig can't be made to build? We clearly don't care whether it can boot or work, but we would just as clearly like to be able to build more ARM stuff without N (N 10) configs. -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote: For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. you need a better box ;) Maybe - it's a lowly 2.6GHz P4 with 1GB RAM, ICH5, and SATA disk. cerfcube_defconfig: 35 seconds carmeva_defconfig:23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? It will certainly improve the situation significantly, and pick up on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): drivers/built-in.o: In function `v4l2_i2c_attach': drivers/media/video/v4l2-common.c:1035: undefined reference to `i2c_attach_client' Currently, the defconfigs known to fail (long term) in Linus' tree are clps7500_defconfig and trizeps4_defconfig - the former I'm tempted to remove, the latter seems to be because the PCMCIA changes were lost on the linux-pcmcia list and the trizeps folk have probably given up. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:05:59 +0100 Roel Kluin [EMAIL PROTECTED] wrote: Alan Cox wrote: Evolution in nature and changes in code are different because in code junk and bugs are constantly removed. In biology junk is allowed and may provide a pool for future development. Linux development is intended and not survival. I would be interested to see any evidence (rather than intuition) to support that, given that both appear to be the same kind of structure and that structure is nowadays fairly well understood. What do you mean with structure, the evolution? that both are a language? No that they show the same mathematical structure and behaviour - both are scale free networks. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 15:47:24 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: On Fri, 15 Feb 2008 15:37:32 -0800 Andrew Morton wrote: On Fri, 15 Feb 2008 23:23:08 + Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: I have tried, and successfully done this many times in the past. The kobject change was one example: add a new function, migrate all users of a direct pointer over to that function, after that work is all done and in, change the structure and do the needed work afterward. All is bisectable completly, with no big flag day needed. Incorrect - because this all happened far too quickly. This is one of the reasons that I ended up having to redo various parts of the ARM tree because stuff broke - set_kset_name() completely vanished introducing compile errors, and iirc some merge issues as well. I had patches introducing new system objects which use that, and modifications extremely close to other uses in the PXA code. The end result (through rebuilding the affected parts of my git tree, and asking people for replacement patches) was something that is bisectable - but had I tried to merge stuff as is, it would've been an utter mess, and _was_ unbuildable. I wonder why I didn't see any of this - I build arm allmodconfig at least once a week, usually more frequently. So either the offending patches weren't in my pile or arm allmodconfig is worse than I thought :( It really is in arch maintainers' best interest to keep their allmodconfig in good shape, for this reason. arm's _isn't_ in good shape: the compile fails for several long-standing reasons (eg: no hope of building DRM) and I don't think the coverage is very broad either. I think that Russell has said that allmodconfig isn't very realistic for ARM, with its 70+ config files. You'd need to pick one board support and enable everything else you possibly can. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Sat, 16 Feb 2008 00:31:36 + Russell King [EMAIL PROTECTED] wrote: so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? It will certainly improve the situation significantly, and pick up on some non-ARM problems like (badge4_defconfig, since 2.6.24-git2): OK, I'll toss something together. the latter seems to be because the PCMCIA changes were lost on the linux-pcmcia list and the trizeps folk have probably given up. I appear to be pcmcia maintainer lately so if someone wants to dust them off and send them over we can see what we can do? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, Feb 15, 2008 at 04:21:21PM -0800, Andrew Morton wrote: On Sat, 16 Feb 2008 00:09:43 + Russell King [EMAIL PROTECTED] wrote: For reference, even _I_ don't build test the entire set of ARM defconfigs - at about 7 minutes a build, 75 defconfigs, that's about 9 hours... I just build those which are important to myself, hope that the others are fine, and rely on kautobuild finding any breakage. you need a better box ;) cerfcube_defconfig: 35 seconds carmeva_defconfig:23 seconds spitz_defconfig (one of the biggest): 45 seconds so would a stupid `for i in arch/arm/configs/*' script be sufficient coverage? I do this wildcard together with yes '' | make ARCH=arm ... oldconfig make Sans toolchain issues, it's pretty good -- Russell larts you when some defconfig becomes broken anyway. :^) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said: > How about "weeks". Both Fedora and openSUSE's next release is going to > be based on 2.6.25, and the first round of -rc1 kernels should be > showing up in their trees in a few days. So for this instance, I think > you will be fine :) a few days == *NOW* kernel-2.6.25-0.40.rc1.git2.fc9.x86_64 is in Fedora Rawhide already. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing > to > indicate its not a problem until some distro actually ships a kernel with the > changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Thu, 14 Feb 2008, Stephen Rothwell wrote: > > > > Originally, I assumed the stable branch would be for our "usual" API > > changes, but it appears we are not having any more of those. :-) > > It's not that we should _never_ have them, it's that they shouldn't be > "business as usual". > > I'm happy with them being a "a couple of times a year". I'm not happy > with them being "once or twice for every release cycle". That's the > big deal for me. very much agreed. I've yet to see a _single_ wide-scale API change that broke stuff left and right where that breakage was technically justified. I have not seen a single one. All those cases were just plain old botched attempts. Either someone can do a large-scale API change like the irq_regs() cleanups with near-zero breakages, or someone cannot. In the latter case, gradual introduction and trickling it through subsystem trees is a _must_. and if it's _hard_ to do a particular large-scale change, then i think the right answer is to _not do it_ in a large-scale way, but do it gradually. I claim that there's just not a single valid case of doing wide-scale changes atomically and departing from the current to-be-stabilized kernel tree materially. _Every_ large-scale API change can be done in a staged way, with each subsystem adopting to the change at their own pace, it just has to be planned well and tested well enough and has to be executed persistently. And the moment we trickle things through subsystem trees, there's no integration pain, as subsystem trees are largely disjunct anyway. i also fear that having an API-changes-only tree will dillute our testing effort of the current to-be-stabilized upstream tree, as it materially disrupts the flow of patches. Most maintainers should concentrate on stabilizing current -git with only one serial queue of fixes and enhancements ontop of that tree. I dont see how having a second queue would help - it clearly splits attention. widescale API changes should be discouraged, and forcing them through the harder, "gradual, per subsystem" route is _exactly_ such a strong force that discourages people from doing them. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Roland, On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier <[EMAIL PROTECTED]> wrote: > > For InfiniBand/RDMA, the tree is: > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next > > or via git protocol: > > git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > for-next > > contact addresses (me plus a mailing list): > > [EMAIL PROTECTED] > [EMAIL PROTECTED] Added, thanks. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQbcvvTYcj6.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
> The first things I need from the subsystem maintainers (you know who you > are) are a contact address (a list address is fine) and at least one git > branch or quilt series that contains all the things you want to see go > into 2.6.26. For InfiniBand/RDMA, the tree is: master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next or via git protocol: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-next contact addresses (me plus a mailing list): [EMAIL PROTECTED] [EMAIL PROTECTED] thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, Feb 14, 2008 at 01:56:13AM +0100, Roman Zippel wrote: > Hi, > > On Wednesday 13. February 2008, Sam Ravnborg wrote: > > > config foo > > tristate "do you want foo?" > > depends on USB && BAR > > module > > obj-$(CONFIG_FOO) += foo.o > > foo-y := file1.o file2.o > > help > > foo will allow you to explode your PC > > I'm more thinking about something like this: > > module foo [FOO] > tristate "do you want foo?" > depends on USB && BAR > source file1.c > source file2.c if BAZ > > Avoiding direct Makefile fragments would give us far more flexibility in the > final Makefile output. Much better and now I see it I recall you posted something along these lines before. Is this something that you plan to look into implementing? I can do the kbuild bits but I need you to do the kconfig stuff (which is by far the biggest effort too). It would be much appreciated to get this. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Greg KH wrote: >On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: >> On Thursday 14 February 2008, Linus Torvalds wrote: >> [...] >> >> >And this is where "process" really matters. Making sure people don't get >> >too frustrated about the constant grind. >> >> One of the problems caused by this 'grind' is being locked out of using >> 3rd party closed drivers until the vendor decides its stable enough to >> make the effort to update their binary blobs to match the newer functions. >> >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are >> appearing to indicate its not a problem until some distro actually ships a >> kernel with the changes that broke it. That could be months or even a >> year plus. > >How about "weeks". Both Fedora and openSUSE's next release is going to >be based on 2.6.25, and the first round of -rc1 kernels should be >showing up in their trees in a few days. So for this instance, I think >you will be fine :) > >thanks, That is good news, thanks Greg. > >greg k-h -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) There's small choice in rotten apples. -- William Shakespeare, "The Taming of the Shrew" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: > On Thursday 14 February 2008, Linus Torvalds wrote: > [...] > >And this is where "process" really matters. Making sure people don't get > >too frustrated about the constant grind. > > One of the problems caused by this 'grind' is being locked out of using 3rd > party closed drivers until the vendor decides its stable enough to make the > effort to update their binary blobs to match the newer functions. > > Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing > to > indicate its not a problem until some distro actually ships a kernel with the > changes that broke it. That could be months or even a year plus. How about "weeks". Both Fedora and openSUSE's next release is going to be based on 2.6.25, and the first round of -rc1 kernels should be showing up in their trees in a few days. So for this instance, I think you will be fine :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Linus Torvalds wrote: [...] >And this is where "process" really matters. Making sure people don't get >too frustrated about the constant grind. One of the problems caused by this 'grind' is being locked out of using 3rd party closed drivers until the vendor decides its stable enough to make the effort to update their binary blobs to match the newer functions. Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. So you've lost one 'canary in the coal mine' tester at least until that happens as I don't have a spare box I can setup to run the nv driver, which itself seems to be suffering from bit rot recently and cannot run this screen at its native 1680x1050 resolution, reverting to something that resembles what I used to get from a timex 1000 in 1978 but with a few colors. I just recently had to install the nvidia driver on my milling machines kubuntu 6.06 box cuz an xorg update put it back to 640x400 if the nv driver was used. This is the real world, where politics aside, it just has to work... :-( But I'll still be lurking and building to test anyway even if I don't boot it for more than 10 minutes. :) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I'm not a lawyer. I don't even play one on TV. - Linus Torvalds on the gcc mailing list -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008, Stephen Rothwell wrote: > > Originally, I assumed the stable branch would be for our "usual" API > changes, but it appears we are not having any more of those. :-) It's not that we should _never_ have them, it's that they shouldn't be "business as usual". I'm happy with them being a "a couple of times a year". I'm not happy with them being "once or twice for every release cycle". That's the big deal for me. If we have a big flag-day that affects a lot of drivers (or architectures) once or twice a year, I think everybody involved will be happy to stand up and say "ok, that fixes problem X, and the new thing really is better, so let's do it, it's worth it". But if it's something that happens essentially every single release, that is somethign else altogether. Then it's not a "ok, let's bite the bullet and make the kernel better" thing any more, but instead it devolves into "f*ck, the merge window is open again, now I have to fix up all the crap people pushed on me". See? That's a *huge* difference, even if it is "only" a mental one (and clearly it isn't - there's the actual real work of the "I have to fix things up" part too). So to recap: I have absolutely nothing against fixing up bad internal API's and breaking things. But 99% of the time that should be something we can do incrementally (ie introduce the new API, and simply accept the fact that removing the old API will take a few months). And the case when that _really_ doesn't work should be rare enough that it doesn't wear people down. Because if you listen to the tone of people in this discussion, much of it is about people being _tired_ of having to fix things up. It's not exactly been a "wow, the end result sure was nice!" kind of discussion, is it? And this is where "process" really matters. Making sure people don't get too frustrated about the constant grind. > However, > I see an argument for attempting to stabilise possible conflicting > changes get Linus' review/ack and add them to the stable branch. > > Linus suggested that such changes should go into an independent tree that > everyone could pull into their trees with the full confidence that that > tree would be merged into Linus' tree when the merge window opens. I am > suggesting that that tree be the stable branch of linux-next. I absolutely have no problem with having a "this is the infrastrcture changes that will go into the next release". In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for "this is for next release", because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a "next" branch. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Feb. 13, 2008, 19:52 +0200, "J. Bruce Fields" <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote: >> So just the fact that the right commit gets blamed when somebody does a >> "git bisect" is I think a big issue. It's just fundamentally more fair to >> everybody. And it means that the people who push their work to me can >> really choose to stand behind it, knowing that whatever happens, their >> work won't get diluted by bad luck or others' incompetence. >> >> And no, maybe most people don't feel things like that matters. But I do >> think it's important. > > The obvious advantage to rebasing in this case is that the blame > (misplaced though it may be), at least lands on a commit that made a > single small change, likely making the problem easier to diagnose. > > (As opposed to the case of a large merge, where all you may know is that > somewhere in the hundreds of commits done on one side of the merge there > was a conflict with the hundreds of commits on the other side.) > > I think a lot of people would see rebasing as an acceptable tradeof that > gives up a small amount of accuracy in assigning blame to individuals in > return for a large increase in ability to debug problems. > > I suppose one response to that would be that it's important that people > learn how to work in parallel, that failures to do so are particularly > important failures in the process, and that it's therefore worth it to > make sure that such failures are always identified specifically as merge > failures. > > It would be nice if merges, like patches, were broken up into somewhat > smaller units. There's an understandable desire to wait to the last > minute to actually commit to one's commits, but a willingness to do so a > little earlier might avoid some of the problems that seem to come from > having a lot of large merges happen all at once. > > --b. One idea that I thought about when debating rebase vs. merge (and it's far far from being fully baked) is versioned commits. The gist of it is that patches are assigned an hash identifier like today when they are first committed into the tree, but, and this is the main change: if they mutate, e.g. by a rebase, or even git commit --amend, their version is bumped up rather than SHA changed. This way all versions of the commit would be accessible and addressable using their respective SHA *and* version. I think that this can help keep the tree's history in a more intuitive way (since the patches' base identifier won't change, just its version number), and you get a bonus of seeing each commit's history, who changed it, and what was the change. Benny -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Thu, 14 Feb 2008 08:14:05 + Russell King <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: > > We need to ask Linus to promise that he will pull the stable branch from > > linux-next first in the merge window. For that to happen, I would expect > > that Linus would also review and sign off (or ack) these commits to the > > linux-next tree. > > Changing the commits in git in anyway changes their ID, which has the > same effects as a rebase. Correct. > With this idea, Linus only has two choices: > > 1. pull the entire set of linux-next changes whether he likes them or not, >because he's going to get them either from the linux-next tree or someone >elses tree which is based upon that. > > 2. don't pull the changes, nor anyone elses tree if he hates the changes >in linux-next. > > So really, Linus needs to ack the changes _before_ they go into linux-next. This is exactly what I suggested (or meant to) *except* that I want it to only apply to the stable branch. I intend that the stable branch of linux-next will never be rebased and so is suitable for others to base their trees off. The master branch will be continually rebased as the subsystem trees change over time. Originally, I assumed the stable branch would be for our "usual" API changes, but it appears we are not having any more of those. :-) However, I see an argument for attempting to stabilise possible conflicting changes get Linus' review/ack and add them to the stable branch. Linus suggested that such changes should go into an independent tree that everyone could pull into their trees with the full confidence that that tree would be merged into Linus' tree when the merge window opens. I am suggesting that that tree be the stable branch of linux-next. I know I haven't thought through all the consequences of this, so discussion is encouaged. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpwL5SPwbFr7.pgp Description: PGP signature
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, 14 Feb 2008, Roman Zippel wrote:
> On Wednesday 13. February 2008, Sam Ravnborg wrote:
> > config foo
> > tristate "do you want foo?"
> > depends on USB && BAR
> > module
> > obj-$(CONFIG_FOO) += foo.o
> > foo-y := file1.o file2.o
> > help
> > foo will allow you to explode your PC
>
> I'm more thinking about something like this:
>
> module foo [FOO]
> tristate "do you want foo?"
> depends on USB && BAR
> source file1.c
> source file2.c if BAZ
And we can finally distinguish between
config bar
bool "do you want bar?"
for boolean options and
module baz
bool "do you want baz?"
for modules that cannot be modular?
And we can make `depends on' do the right thing for dependencies on modules
that are modular (cfr. e.g. commit e11a6c236b3070ed05b079f91a9b3defa48b54d3,
[VIDEO]: XVR500 and XVR2500 require FB=y)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: > We need to ask Linus to promise that he will pull the stable branch from > linux-next first in the merge window. For that to happen, I would expect > that Linus would also review and sign off (or ack) these commits to the > linux-next tree. Changing the commits in git in anyway changes their ID, which has the same effects as a rebase. With this idea, Linus only has two choices: 1. pull the entire set of linux-next changes whether he likes them or not, because he's going to get them either from the linux-next tree or someone elses tree which is based upon that. 2. don't pull the changes, nor anyone elses tree if he hates the changes in linux-next. So really, Linus needs to ack the changes _before_ they go into linux-next. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: We need to ask Linus to promise that he will pull the stable branch from linux-next first in the merge window. For that to happen, I would expect that Linus would also review and sign off (or ack) these commits to the linux-next tree. Changing the commits in git in anyway changes their ID, which has the same effects as a rebase. With this idea, Linus only has two choices: 1. pull the entire set of linux-next changes whether he likes them or not, because he's going to get them either from the linux-next tree or someone elses tree which is based upon that. 2. don't pull the changes, nor anyone elses tree if he hates the changes in linux-next. So really, Linus needs to ack the changes _before_ they go into linux-next. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, 14 Feb 2008, Roman Zippel wrote:
On Wednesday 13. February 2008, Sam Ravnborg wrote:
config foo
tristate do you want foo?
depends on USB BAR
module
obj-$(CONFIG_FOO) += foo.o
foo-y := file1.o file2.o
help
foo will allow you to explode your PC
I'm more thinking about something like this:
module foo [FOO]
tristate do you want foo?
depends on USB BAR
source file1.c
source file2.c if BAZ
And we can finally distinguish between
config bar
bool do you want bar?
for boolean options and
module baz
bool do you want baz?
for modules that cannot be modular?
And we can make `depends on' do the right thing for dependencies on modules
that are modular (cfr. e.g. commit e11a6c236b3070ed05b079f91a9b3defa48b54d3,
[VIDEO]: XVR500 and XVR2500 require FB=y)?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Russell, On Thu, 14 Feb 2008 08:14:05 + Russell King [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote: We need to ask Linus to promise that he will pull the stable branch from linux-next first in the merge window. For that to happen, I would expect that Linus would also review and sign off (or ack) these commits to the linux-next tree. Changing the commits in git in anyway changes their ID, which has the same effects as a rebase. Correct. With this idea, Linus only has two choices: 1. pull the entire set of linux-next changes whether he likes them or not, because he's going to get them either from the linux-next tree or someone elses tree which is based upon that. 2. don't pull the changes, nor anyone elses tree if he hates the changes in linux-next. So really, Linus needs to ack the changes _before_ they go into linux-next. This is exactly what I suggested (or meant to) *except* that I want it to only apply to the stable branch. I intend that the stable branch of linux-next will never be rebased and so is suitable for others to base their trees off. The master branch will be continually rebased as the subsystem trees change over time. Originally, I assumed the stable branch would be for our usual API changes, but it appears we are not having any more of those. :-) However, I see an argument for attempting to stabilise possible conflicting changes get Linus' review/ack and add them to the stable branch. Linus suggested that such changes should go into an independent tree that everyone could pull into their trees with the full confidence that that tree would be merged into Linus' tree when the merge window opens. I am suggesting that that tree be the stable branch of linux-next. I know I haven't thought through all the consequences of this, so discussion is encouaged. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpwL5SPwbFr7.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Feb. 13, 2008, 19:52 +0200, J. Bruce Fields [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote: So just the fact that the right commit gets blamed when somebody does a git bisect is I think a big issue. It's just fundamentally more fair to everybody. And it means that the people who push their work to me can really choose to stand behind it, knowing that whatever happens, their work won't get diluted by bad luck or others' incompetence. And no, maybe most people don't feel things like that matters. But I do think it's important. The obvious advantage to rebasing in this case is that the blame (misplaced though it may be), at least lands on a commit that made a single small change, likely making the problem easier to diagnose. (As opposed to the case of a large merge, where all you may know is that somewhere in the hundreds of commits done on one side of the merge there was a conflict with the hundreds of commits on the other side.) I think a lot of people would see rebasing as an acceptable tradeof that gives up a small amount of accuracy in assigning blame to individuals in return for a large increase in ability to debug problems. I suppose one response to that would be that it's important that people learn how to work in parallel, that failures to do so are particularly important failures in the process, and that it's therefore worth it to make sure that such failures are always identified specifically as merge failures. It would be nice if merges, like patches, were broken up into somewhat smaller units. There's an understandable desire to wait to the last minute to actually commit to one's commits, but a willingness to do so a little earlier might avoid some of the problems that seem to come from having a lot of large merges happen all at once. --b. One idea that I thought about when debating rebase vs. merge (and it's far far from being fully baked) is versioned commits. The gist of it is that patches are assigned an hash identifier like today when they are first committed into the tree, but, and this is the main change: if they mutate, e.g. by a rebase, or even git commit --amend, their version is bumped up rather than SHA changed. This way all versions of the commit would be accessible and addressable using their respective SHA *and* version. I think that this can help keep the tree's history in a more intuitive way (since the patches' base identifier won't change, just its version number), and you get a bonus of seeing each commit's history, who changed it, and what was the change. Benny -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008, Stephen Rothwell wrote: Originally, I assumed the stable branch would be for our usual API changes, but it appears we are not having any more of those. :-) It's not that we should _never_ have them, it's that they shouldn't be business as usual. I'm happy with them being a a couple of times a year. I'm not happy with them being once or twice for every release cycle. That's the big deal for me. If we have a big flag-day that affects a lot of drivers (or architectures) once or twice a year, I think everybody involved will be happy to stand up and say ok, that fixes problem X, and the new thing really is better, so let's do it, it's worth it. But if it's something that happens essentially every single release, that is somethign else altogether. Then it's not a ok, let's bite the bullet and make the kernel better thing any more, but instead it devolves into f*ck, the merge window is open again, now I have to fix up all the crap people pushed on me. See? That's a *huge* difference, even if it is only a mental one (and clearly it isn't - there's the actual real work of the I have to fix things up part too). So to recap: I have absolutely nothing against fixing up bad internal API's and breaking things. But 99% of the time that should be something we can do incrementally (ie introduce the new API, and simply accept the fact that removing the old API will take a few months). And the case when that _really_ doesn't work should be rare enough that it doesn't wear people down. Because if you listen to the tone of people in this discussion, much of it is about people being _tired_ of having to fix things up. It's not exactly been a wow, the end result sure was nice! kind of discussion, is it? And this is where process really matters. Making sure people don't get too frustrated about the constant grind. However, I see an argument for attempting to stabilise possible conflicting changes get Linus' review/ack and add them to the stable branch. Linus suggested that such changes should go into an independent tree that everyone could pull into their trees with the full confidence that that tree would be merged into Linus' tree when the merge window opens. I am suggesting that that tree be the stable branch of linux-next. I absolutely have no problem with having a this is the infrastrcture changes that will go into the next release. In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for this is for next release, because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a next branch. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Linus Torvalds wrote: [...] And this is where process really matters. Making sure people don't get too frustrated about the constant grind. One of the problems caused by this 'grind' is being locked out of using 3rd party closed drivers until the vendor decides its stable enough to make the effort to update their binary blobs to match the newer functions. Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. So you've lost one 'canary in the coal mine' tester at least until that happens as I don't have a spare box I can setup to run the nv driver, which itself seems to be suffering from bit rot recently and cannot run this screen at its native 1680x1050 resolution, reverting to something that resembles what I used to get from a timex 1000 in 1978 but with a few colors. I just recently had to install the nvidia driver on my milling machines kubuntu 6.06 box cuz an xorg update put it back to 640x400 if the nv driver was used. This is the real world, where politics aside, it just has to work... :-( But I'll still be lurking and building to test anyway even if I don't boot it for more than 10 minutes. :) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I'm not a lawyer. I don't even play one on TV. - Linus Torvalds on the gcc mailing list -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: On Thursday 14 February 2008, Linus Torvalds wrote: [...] And this is where process really matters. Making sure people don't get too frustrated about the constant grind. One of the problems caused by this 'grind' is being locked out of using 3rd party closed drivers until the vendor decides its stable enough to make the effort to update their binary blobs to match the newer functions. Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. How about weeks. Both Fedora and openSUSE's next release is going to be based on 2.6.25, and the first round of -rc1 kernels should be showing up in their trees in a few days. So for this instance, I think you will be fine :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thursday 14 February 2008, Greg KH wrote: On Thu, Feb 14, 2008 at 01:32:02PM -0500, Gene Heskett wrote: On Thursday 14 February 2008, Linus Torvalds wrote: [...] And this is where process really matters. Making sure people don't get too frustrated about the constant grind. One of the problems caused by this 'grind' is being locked out of using 3rd party closed drivers until the vendor decides its stable enough to make the effort to update their binary blobs to match the newer functions. Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. How about weeks. Both Fedora and openSUSE's next release is going to be based on 2.6.25, and the first round of -rc1 kernels should be showing up in their trees in a few days. So for this instance, I think you will be fine :) thanks, That is good news, thanks Greg. greg k-h -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) There's small choice in rotten apples. -- William Shakespeare, The Taming of the Shrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
On Thu, Feb 14, 2008 at 01:56:13AM +0100, Roman Zippel wrote: Hi, On Wednesday 13. February 2008, Sam Ravnborg wrote: config foo tristate do you want foo? depends on USB BAR module obj-$(CONFIG_FOO) += foo.o foo-y := file1.o file2.o help foo will allow you to explode your PC I'm more thinking about something like this: module foo [FOO] tristate do you want foo? depends on USB BAR source file1.c source file2.c if BAZ Avoiding direct Makefile fragments would give us far more flexibility in the final Makefile output. Much better and now I see it I recall you posted something along these lines before. Is this something that you plan to look into implementing? I can do the kbuild bits but I need you to do the kconfig stuff (which is by far the biggest effort too). It would be much appreciated to get this. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
The first things I need from the subsystem maintainers (you know who you are) are a contact address (a list address is fine) and at least one git branch or quilt series that contains all the things you want to see go into 2.6.26. For InfiniBand/RDMA, the tree is: master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next or via git protocol: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-next contact addresses (me plus a mailing list): [EMAIL PROTECTED] [EMAIL PROTECTED] thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Hi Roland, On Thu, 14 Feb 2008 15:22:46 -0800 Roland Dreier [EMAIL PROTECTED] wrote: For InfiniBand/RDMA, the tree is: master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git for-next or via git protocol: git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git for-next contact addresses (me plus a mailing list): [EMAIL PROTECTED] [EMAIL PROTECTED] Added, thanks. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQbcvvTYcj6.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
* Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, Stephen Rothwell wrote: Originally, I assumed the stable branch would be for our usual API changes, but it appears we are not having any more of those. :-) It's not that we should _never_ have them, it's that they shouldn't be business as usual. I'm happy with them being a a couple of times a year. I'm not happy with them being once or twice for every release cycle. That's the big deal for me. very much agreed. I've yet to see a _single_ wide-scale API change that broke stuff left and right where that breakage was technically justified. I have not seen a single one. All those cases were just plain old botched attempts. Either someone can do a large-scale API change like the irq_regs() cleanups with near-zero breakages, or someone cannot. In the latter case, gradual introduction and trickling it through subsystem trees is a _must_. and if it's _hard_ to do a particular large-scale change, then i think the right answer is to _not do it_ in a large-scale way, but do it gradually. I claim that there's just not a single valid case of doing wide-scale changes atomically and departing from the current to-be-stabilized kernel tree materially. _Every_ large-scale API change can be done in a staged way, with each subsystem adopting to the change at their own pace, it just has to be planned well and tested well enough and has to be executed persistently. And the moment we trickle things through subsystem trees, there's no integration pain, as subsystem trees are largely disjunct anyway. i also fear that having an API-changes-only tree will dillute our testing effort of the current to-be-stabilized upstream tree, as it materially disrupts the flow of patches. Most maintainers should concentrate on stabilizing current -git with only one serial queue of fixes and enhancements ontop of that tree. I dont see how having a second queue would help - it clearly splits attention. widescale API changes should be discouraged, and forcing them through the harder, gradual, per subsystem route is _exactly_ such a strong force that discourages people from doing them. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing to indicate its not a problem until some distro actually ships a kernel with the changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said: How about weeks. Both Fedora and openSUSE's next release is going to be based on 2.6.25, and the first round of -rc1 kernels should be showing up in their trees in a few days. So for this instance, I think you will be fine :) a few days == *NOW* kernel-2.6.25-0.40.rc1.git2.fc9.x86_64 is in Fedora Rawhide already. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: distributed module configuration [Was: Announce: Linux-next (Or Andrew's dream :-))]
Hi, On Wednesday 13. February 2008, Sam Ravnborg wrote: > config foo > tristate "do you want foo?" > depends on USB && BAR > module > obj-$(CONFIG_FOO) += foo.o > foo-y := file1.o file2.o > help > foo will allow you to explode your PC I'm more thinking about something like this: module foo [FOO] tristate "do you want foo?" depends on USB && BAR source file1.c source file2.c if BAZ Avoiding direct Makefile fragments would give us far more flexibility in the final Makefile output. > And we could introduce support for > > source "drivers/net/Kconfig.*" > > But then we would have to make the kconfig step mandatory > for each build as we would otherwise not know if there > were added any Kconfig files. That's a real problem and it would be a step back of what we have right now, so I'm not exactly comfortable with it. bye, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 01:24:41PM -0700, Ann Davis wrote: > Frank Seidel wrote: >> >> Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they >> also really hope - at least i very strongly do - you not only call on us when >> things become a burden, but let us help and assist you right from the start. > > Agreed. I'm happy to do daily builds (I have x86 and ppc systems > available), >... Jan already does builds of all -git (and previously -bk) and -mm kernels for all architectures for some years, and it might be easier if he simply adds -next to his builds. > Thx, > > Ann cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Frank Seidel wrote: Lets get serious. I cannot speak for Ann and Harvey, but I'm quite sure they also really hope - at least i very strongly do - you not only call on us when things become a burden, but let us help and assist you right from the start. Agreed. I'm happy to do daily builds (I have x86 and ppc systems available), write scripts, etc. In the meantime I'll just lurk and learn. :-) Thx, Ann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
> Evolution in nature and changes in code are different because in code junk > and bugs are constantly removed. In biology junk is allowed and may provide > a pool for future development. Linux development is intended and not > survival. I would be interested to see any evidence (rather than intuition) to support that given that both appear to be the same kind of structure and that structure is nowdays fairly well understood. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, 13 Feb 2008, Roel Kluin wrote: > > In nature there is a lot of duplication: several copies of genes can exist > and different copies may have a distinct evolution. This is true of very complex animals, but much less so when looking at things like bacteria (and arguably, any current sw project is closer to bacteria in complexity than anything mammalian). In bacteria (and viruses), duplication of DNA/RNA is a big cost of living in general, and as a result there is *much* less junk DNA. So in an evolutionary sense, it's much closer to what the kernel should have (with occasional duplication of code and interfaces to allow new functionality, but rather aggressive pruning of the excess baggage). In other words, all of these choices are a matter of "balance". In some areas, excess code is not a sufficient downside, and we keep even broken source code around with no actual function, "just because" (or rather, because the cost of carrying it around is so small that nobody cares). That's true in the kernel as in biology: check out not just deprecated code, but the drivers and other odds-and-ends that are explicitly marked as non-coding DNA (we just happen to call them BROKEN in our Kconfig). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 05:36:41AM -0500, Theodore Tso wrote: > On Tue, Feb 12, 2008 at 10:16:53PM -0800, Greg KH wrote: > > I was amazed at how slow stgit was when I tried it out. I use > > git-quiltimport a lot and I don't think it's any slower than just using > > quilt on its own. So I think that the speed issue should be the same. > > I like using "guilt" because I can easily reapply the patchset using > "guilt push -a", which is just slightly fewer characters to type than > "git-quiltimport". This also means that I don't need to switch back > and forth between "git mode" and "quilt mode" when I'm editing the > patches (either directly by editing the patch files, in which case > afterwards I do a "guilt pop -a; guilt push -a", or by using "guilt > pop", "guilt push", and "guilt refresh"). I had problems getting guilt to preserve metadata properly last time I tried it, and it forced me to work with the same location and format that the original developers used, which wasn't as flexable as quilt could handle from what I recall. But I'll try it again, it might have gotten better... thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote: >... > The other is that once somebody says "ok, I *really* need to cause this > breakage, because there's a major bug or we need it for fundamental reason > XYZ", then that person should > > (a) create a base tree with _just_ that fundamental infrastructure change, > and make sure that base branch is so obviously good that there is no > question about merging it. > > (b) tell other people about the reason for the infrastructure change, and > simply allow others to merge it. You don't have to wait for *me* to > open the merge window, you need to make sure that the people that get > impacted most can continue development! > > This is where "rebases really are bad" comes in. When the above sequence > happens, the fundamental infrastructure change obviously does need to be > solid and not shifting under from other people who end up merging it. I do > not want to see five different copies of the fundamental change either > because the original source fixed it up and rebased it, or because the > people who merged it rebased _their_ trees and rebased the fundamental > change in the process. > > Can that (b) be my tree? Sure. That's been the common case, and I'll > happily continue it, of course, so I'm not arguing for that to go away. > Merging is my job, I'll do it. But when the merge window is a problem, my > merge window should *not* hold up people from using the distributed nature > of git for their advantage. > > But yes, obviously when doing cross-merges, you'd better be really > *really* sure that the base is solid and will get merged. But let's face > it, all the really core maintainers should damn well know that by now: > you've all worked with me for years, so you should be able to trivially be > able to tell whether you *might* need to worry about something, and when > it's a slam dunk. > > And it's the "it's a slam dunk" cases that I think are (a) the common ones > and (b) the ones where you can just do cross-merges to satisfy each others > needs. > > Hmm? Does that sound palatable to people? I'm sure I understand only less than half of what you said. My current understanding is that all the aspects of your proposal that are interesting for me can be summarized as follows: - your tree stops compiling at the beginning of the merge window when you merge the first subsystem tree - your tree might compile again at the end of the merge window when you merge the last subsystem tree - git-bisect -> /dev/null What do I miss? > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:43:10PM -0800, Linus Torvalds wrote: > So just the fact that the right commit gets blamed when somebody does a > "git bisect" is I think a big issue. It's just fundamentally more fair to > everybody. And it means that the people who push their work to me can > really choose to stand behind it, knowing that whatever happens, their > work won't get diluted by bad luck or others' incompetence. > > And no, maybe most people don't feel things like that matters. But I do > think it's important. The obvious advantage to rebasing in this case is that the blame (misplaced though it may be), at least lands on a commit that made a single small change, likely making the problem easier to diagnose. (As opposed to the case of a large merge, where all you may know is that somewhere in the hundreds of commits done on one side of the merge there was a conflict with the hundreds of commits on the other side.) I think a lot of people would see rebasing as an acceptable tradeof that gives up a small amount of accuracy in assigning blame to individuals in return for a large increase in ability to debug problems. I suppose one response to that would be that it's important that people learn how to work in parallel, that failures to do so are particularly important failures in the process, and that it's therefore worth it to make sure that such failures are always identified specifically as merge failures. It would be nice if merges, like patches, were broken up into somewhat smaller units. There's an understandable desire to wait to the last minute to actually commit to one's commits, but a willingness to do so a little earlier might avoid some of the problems that seem to come from having a lot of large merges happen all at once. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote: > On Tue, Feb 12, 2008 at 07:46:51PM +, Al Viro wrote: >... > > AFAICS, we are in situation when review bandwidth is where the bottleneck > > is. Not the merge one... > > Are there still large numbers of posted patches, not reviewed or picked > up by anyone laying around somewhere? I thought Andrew-the-patch-vacuum > had been doing a great job of keeping that from happening lately. I wrote in one of the many bug reports I sent for compile errors introduced in Linus' tree during this merge window: An architecture specific patch that breaks the one architecture it touches at the first file being compiled is even for kernel standards unusually bad... > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
Linus Torvalds wrote: > > On Tue, 12 Feb 2008, Greg KH wrote: >>> That's the point. >> Not it isn't. To quote you a number of years ago: >> "Linux is evolution, not intelligent design" > > Umm. Have you read a lot of books on evolution? > > It doesn't sound like you have. > > The fact is, evolution often does odd (and "suboptimal") things exactly > because it does incremental changes that DO NOT BREAK at any point. This is not entirely true if the pressure for changes are removed. For instance in mammals the bones in the ear are what used to be gills in fish. When fish became amphibians the gills weren't needed as much and evolution took a side path. > The examples are legion. The mammalian eye has the retina "backwards", > with the blind spot appearing because the fundmanetal infrastructure (the > optical nerves) actually being in *front* of the light sensor and needing > a hole in the retina to get the information (and blood flow) to go to the > brain! > > In other words, exactly *because* evolution requires "bisectability" (any > non-viable point in between is a dead end by definition) and does things > incrementally, it doesn't do big flips. It fixes the problems on an > incremental scale both when it comes to the details and when it comes to > both "details" (actual protein-coding genes that code directly for some > expression) and "infrastructure" (homeobox and non-coding genes). In nature there is a lot of duplication: several copies of genes can exist and different copies may have a distinct evolution. There is also a lot of 'junk' DNA that doesn't code for anything (although it may have regulating functions). In there some copies of genes may remain that are inactivated, as well as parts of virusses, slowly obtaining random mutations because there is no pressure on the evolution of them. Some may eventually become active again and have different functions. The duplication also often ensures there is fallback when random mutations are acquired and a protein is knocked out. Besides the two chromosomes several proteins also can have overlapping functions. The result is more like a balance. Evolution in nature and changes in code are different because in code junk and bugs are constantly removed. In biology junk is allowed and may provide a pool for future development. Linux development is intended and not survival. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 10:06:16AM -0500, John W. Linville wrote: > On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote: > > Make the distinction earlier. With ocfs2 and configfs (we got > > this scheme from Jeff), we keep the topic branches as "unsafe" - that > > is, officially rebaseable . We merge them all into a big "ALL" branch, > > which is also "unsafe". Andrew pulls this for -mm, and it gets tested > > here. If there is a brown-paper-bag problem, we can tell the original > > author to fix it. Then we re-pull the topic - effectively a rebase. > > The ALL is also rebased. But that's Ok, it will never go towards Linus. > > This is essentially the same process I've been using in wireless-2.6 > with the (regularly rebased) 'everything' branch. Still I find > that it causes lots of confusion and complaining. Perhaps I am not > communicating clearly enough... :-) > > Do you find that people are happy with that process? Forgive me for > not knowing, but how many developers are actively (or occasionaly) > involved in ocfs2 and configfs? How many 'normal' users pull your > tree looking for 'latest and greatest' code? Oh, I have no pretense that ocfs2 is as busy as wireless or net. Certainly Andrew has no problem with it. People I've interacted with while working on features, etc, also get it, but I'm usually pointing them to it up-front. I think you'd probably have lessons that larger trees could learn from. For example, do you have a 'things that will go to linus soon" branch that people can grab - something that's now stable/non-rebasing? Do you advertise the rebaseableness of "everything" in the web page where you say "grab 'everthing' for the latest stuff"? Joel -- "The suffering man ought really to consume his own smoke; there is no good in emitting smoke till you have made it into fire." - thomas carlyle Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 06:47:30PM -0800, Joel Becker wrote: > Make the distinction earlier. With ocfs2 and configfs (we got > this scheme from Jeff), we keep the topic branches as "unsafe" - that > is, officially rebaseable . We merge them all into a big "ALL" branch, > which is also "unsafe". Andrew pulls this for -mm, and it gets tested > here. If there is a brown-paper-bag problem, we can tell the original > author to fix it. Then we re-pull the topic - effectively a rebase. > The ALL is also rebased. But that's Ok, it will never go towards Linus. > When a topic is considered worthy of going upstream, we pull it > to a branch called "upstream-linus". This branch is *NEVER* rebased. > Now that the topic is in upstream-linus, the original topic branch can't > be rebased either. So any fixes to that topic going forward will stay > in the history. Since that topic was pulled into ALL for testing, we > are using the identical commits that got tested. This is essentially the same process I've been using in wireless-2.6 with the (regularly rebased) 'everything' branch. Still I find that it causes lots of confusion and complaining. Perhaps I am not communicating clearly enough... :-) Do you find that people are happy with that process? Forgive me for not knowing, but how many developers are actively (or occasionaly) involved in ocfs2 and configfs? How many 'normal' users pull your tree looking for 'latest and greatest' code? John -- John W. Linville [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
