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/ pgpU1bZOHxtWB.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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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] pgpUyhuiXiNk0.pgp Description: PGP signature
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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] pgpw1a0eJwf2U.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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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... pgpreerI0ayLS.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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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/ pgp7S52OFBriv.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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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/ pgpdguyAXPuYf.pgp Description: PGP signature
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Wed, Feb 13, 2008 at 07:06:24AM -0500, Jeff Garzik wrote: > Russell King wrote: > >We know that the -mm tree is pretty much useless in terms of code > >coverage for ARM, and it's getting increasingly unlikely that anything > >short of a build of all ARM defconfigs will pick up on merge issues - > >which is a lot of CPU cycles, and I'm not going to insist its something > >that should be done. > > > If you need help in that area (build-testing ARM), surely we can find > some fast machines that can do builds for you. Any interest? It would probably make some sense - it would help to get hold of the infrastructure that armlinux.simtec.co.uk uses to run their test builds of Linus' tree and apply it (on a separate machine) to -mm (or indeed whatever other) 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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
Russell King wrote: We know that the -mm tree is pretty much useless in terms of code coverage for ARM, and it's getting increasingly unlikely that anything short of a build of all ARM defconfigs will pick up on merge issues - which is a lot of CPU cycles, and I'm not going to insist its something that should be done. If you need help in that area (build-testing ARM), surely we can find some fast machines that can do builds for you. Any interest? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 21:16 -0500, Theodore Tso wrote: > I've never been very happy with stgit because of past experiences > which has scarred me when it got get confused and lost my entire patch > series (this was before git reflogs, so recovery was interesting). It got much better now :-). We are even working on transactions support and, if something fails, it restores the state of the stack. > There's always been something deeply comforting about having the ASCII > patch series since it's easy to back it up and know you're in no > danger of losing everything in case of a bug. There is "stg export" which could be made to export a patch automatically at every change. > The other advantage of storing the patch stack as a an ASCII quilt > series is we have a history of changes of the patches, which we don't > necessarily have if you just use stgit to rewrite the patch. As I said in a different e-mail, we got patch history tracking in StGIT. You can even annotate specific changes. For editing, there is "stg edit [--diff]" which allows both description and patch changes. However, the StGIT approach is not fully suited for multiple developers sharing the same set of patches, especially if they are allowed to modify the same patches. For this kind of workflow, you can export the series and add the patches to a separate shared repository. StGIT has a "sync" command to synchronise changes to patches in different series (either stored as quilt series or in a different branch). -- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote: > I can run the numbers, but almost every one of those changes has at > least 2 signed-off-by: on them, so they should all be being reviewed > properly. Good joke.. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 22:16 -0800, Greg KH wrote: > 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. I added some time ago patch history tracking in stgit and you can run "stg log [--graphical] " to see all the changes for that patch (as a list or via gitk). This is done by keeping a separate DAG of commits linking small changes to a patch. > 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. It shouldn't be slower than git-quiltimport (at least the recent stgit versions) as they seem to have a similar approach (using "git apply"). There is probably an extra check stgit does for local changes before starting the import. Otherwise, just use git-quiltimport and "stg uncommit" to generate the patches. StGIT approach for pushing patches is to use git-apply and, only if this fails, switch to a three-way merge. These days it seems that the three-way merge is pretty fast anyway, we might drop the former (after some benchmarking). > I had a number of issues last time I tried stgit out, but maybe they are > now resolved, I'll try it out tomorrow and report to the git list > anything I find that doesn't work for me. Please try the last stable release, 0.14. The current HEAD has some restructuring done (but gets nice features like transactions, undo). Thanks. -- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
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"). "guilt push -a" is a little bit slower than "quilt push -a", but not enough to be seriously annoying. And besides, "guilt pop -a" is slightly faster than "quilt pop -a". Using guilt is also nice because there is a bit of additional backup for previous work via the git reflogs, although to be honest I've rarely needed to use it. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:51:52PM +, Alan Cox wrote: > > We could simply decide that API changes affecting more than one subsystem > > Must Be Serialized(tm). Explicitly. As in "any such change is posted > > Welcome to dreamland. The only way I can get serial changes done is to > wait months and eventually simply persuade Andrew to ignore the > "maintainers" who are basically not responding. ... because we didn't realise that the pre-requisits for those patches had already gone in. If that had been the case, I'd have applied the ARM changes for the new tty ioctls immediately. It was a communication problem, not a process problem. -- 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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 11:19:14AM -0800, Greg KH wrote: > We usually get this warning today in -mm. We don't always - and I'd say in terms of ARM it would be extremely rare. The sysfs API changes at the start of the last merge window is one example of this. I had everything nicely prepared in the ARM tree for merging shortly after the window opened, and then wham bam thankyou mam, the merge window opened and a lot ended up breaking. We know that the -mm tree is pretty much useless in terms of code coverage for ARM, and it's getting increasingly unlikely that anything short of a build of all ARM defconfigs will pick up on merge issues - which is a lot of CPU cycles, and I'm not going to insist its something that should be done. -- 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-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > Here are some odd-the-cuff
> > suggestions:
> >
> > 1) Make feature-removal-schedule a directory with files in it.
> >Everyone touches that file, creating merge issues.
> >
> > 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
> >instead have each "thing" have it's own Kconfig.foo or
> >Makefile.foo that gets automatically sucked into the main
> >directory Makefile or Kconfig using file globs or similar.
> >
> >Even better, encode the building of things into the *.[ch]
> >files themselves, and have the Kconfig/Makefile machinery
> >automatically extract this information when you build.
>
> 3) teach people that you don't always have to add new includes right
>at the end of the list
>
> 4) teach people that you don't have to add Makefile rules right at the
>end of the list
If the list is already sorted, I insert it at the right position.
If not, well...
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-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
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,
2. Sometimes it's a lot of work to fixup the patches after an upstream
change. I wrote a script to do a tree-way-merge in case of a
conflict, but I haven't really tested it yet (not suitable big
conflict has happened since ;-)
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-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
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. > A pure patch-stack will be faster at that thing than git would be (it's > simply easier to just track patches), but on the other hand, using git > would get some other advantages outside of the integration issue (eg the > cherry-pick thing really is a proper three-way merge, not just an "apply > patch", so it can do better). 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 had a number of issues last time I tried stgit out, but maybe they are now resolved, I'll try it out tomorrow and report to the git list anything I find that doesn't work for me. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > Of course, if you didn't even want to save the old branch, just skip the > first step. If you have reflogs enabled (and git does that by default in > any half-way recent version), you can always find it again, even without > having to do "git fsck --lost-found", at least as long as you don't delete > that branch, and it hasn't gotten pruned away (kept around for the next 90 > days by default, iirc) Even if you delete that branch, the "HEAD" reflog will still contain it, since it is separate from any particular branch reflog. Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > So let's say that you have a remote branch that you track that goes > rebasing (let's call it "origin/pu" to match the real-life git behaviour), > then you should literally be able to do > > old=$(git rev-parse origin/pu) && > git fetch && > new=$(git rev-parse origin/pu) && > git rebase --onto $new $old > > and no, I didn't actually test it, but hey, it really should be that > simple. Or, with Git 1.5.4, just: git pull --rebase And I didn't test it yet either. Same caveats do apply. Nicolas - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
After glancing at some of this thread its clear to me what Stephen's real goal is: 1. collect kernel trees (or underpants) 2. ? 3. profit http://en.wikipedia.org/wiki/Underpants_Gnomes - k - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 05:20:51PM -0800, David Miller wrote: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST) > > > gitk --merge > ... > > This is something where I actually think git could and should do better: > > git has the capability to act as more of a "quilt replacement", but > > because it wasn't part of the original design, we never actualy exposed > > the simple queue management commands to do this (stgit does things like > > that, though). > > > > So if you haven't pushed out, right now you'd have to do this stupid > > thing: > > Thanks for all the useful info. > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. > > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. > > A rebase is just a series of events, and those could propagate to > people who are pulling from the tree. I'm pretty sure GIT could > support this. git checkout -b new-tree old-tree # hack on new-tree: rebase, drop bad commits, whatever git merge -s ours old-tree git push your-public-repo new-tree:public-tree Now public-tree has a merge commit on the top with two parents, public-tree^1 and public-tree^2. public-tree^1 is the tip of the new cleaned-up history, and public-tree^2 points to the old stuff. I sometimes use that privately as a way to keep track of the history of a patch-series, but I assume Linus would shoot anyone that tried to submit such a monstrosity upstream --b. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 09:00:16PM -0600, James Bottomley wrote: > On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > > downstream users of a rebased tree to rebase themselves correctly. > > > > > > All the information about the rebase is in the reflog ... it can't be > > > too difficult to pass it through on a pull and allow the downstream tree > > > to do the right thing. > > > > Guys, you simply have no idea what you're talking about. > > > > Those downstream trees can have done things themselves. They *depended* on > > the state you gave them. > > > > You can't just say "oops, I lied, this is the state you should have used, > > now it's _your_ mess to sort out". > > > > OF COURSE it's what you'd like to use - it absolves you of any and all > > actual responsibility. But dammit, that's not what anybody else wants than > > the irresponsible person who cannot be bothered to stand up for his work! > > > > If you're not confident enough about your work, don't push it out! It's > > that simple. Pushing out to a public branch is a small "release". > > > > Have the f*cking back-bone to be able to stand behind what you did! > > Erm, I would like this feature as a downstream user. > > I'm not asking for this to be the default or even easily available. > However, when you know you've based a downstream tree on what you know > to be a volatile base, it would be very useful information to have. > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. > > Basing on a tree I know to be volatile is sometimes a development > decision I make as a downstream user ... I'm just wishing the tools > could help me handle the problems better. > There's also a difference between a downstream user and a downstream developer. While rebasing does cause trouble for folks doing downstream development off of the tree in question, there's no reason why this should be the case for users that are simply trying to follow the tree. I push changes out to my tree so people have a chance to poke through it and to see what's going on, though I do not generally encourage people to fork off of it given that I end up rebasing periodically. At the moment the options seem to be down to the following: 1 - Push changes out without rebasing 2 - Push changes out periodically rebased 3 - Hide the tree away in my home directory on hera 4 - Force people to get at the current tree through -mm 4) generally isn't very realistic, given that -mm releases have far too many other changes and the releases are quite spread out. 3) is doable, but I publish the tree as a convenience to the folks wanting to see what's going on in the tree, and I would rather continue doing so. This leaves 2) my current workflow, and 1) which ends up creating a lot of extra metadata. The common cases thelre are patches + reversions and merge points. Holding on to a patch for some period of time before pushing it out to ensure that there won't be a reversion later rarely tends to work in practice. Most of the time I end up having to revert something it's because someone else found a problem with a given change _after_ the it was pushed out, and which was not caught with my local tree or testing. On the other hand, perhaps it's also useful to see the reversions in the history, particularly to see what the rationale for the change not working out was (which could be helpful for people working on the same stuff later on). This then leaves merge points. During merge window time people are pulling on a pretty frequent basis, which also breaks down to a few fairly common cases: 1 - Bringing in new stuff to be supported (ie, system calls). 2 - Infrastructure support bits that have gone in through a subsystem tree, when you have local patches blocked until the subsystem tree has merge. 3 - Catching and resolving conflicts before bisect gets broken. 4 - Trying to make sure that it all merges cleanly. I've generally worked around 2) by doing multiple merges during the merge window, but it's also appealing to just rebase and throw in the rest of the outstanding bits before sending out the initial merge request. 1) and 3) often tend to have dependencies on each other, and tend to be the area where the most troubles arise. 3) and 4) are really the places where rebasing appeals the most, and is also where we see the highest concentration of merge points. If there's a nice way to resolve this without a rebase that would be nice. For users in general, I suspect most people are just interested in a pull that can traverse a rebase without having
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 19:31 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Right at the moment, I maintain a and a -base and > > simply cherry pick the commits between the two to do the right thing > > when I know my volatile base has changed. It would be very helpful to > > have a version of rebase that new my base had been rebased. > > Hey, I know, you could use.. drumroll.. > > "git rebase" > > I know that's a big leap of faith, to use git rebase for rebasing, but > there you have it. Us git people are kind of odd that way. > > IOW, if you know the old broken base, and the new base, just do > > git rebase --onto newbase oldbase > > and it should do exactly that (basically lots of automated cherry-picks). OK, smarty-pants ... that works nicely, thanks! I'm used to maintaining and -base, so this probably suits my workflow better than getting the information from the reflog. It wasn't clear from the git rebase man page that it would work like that. James - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, Linus Torvalds wrote: > > git rebase --onto $new $old ..and in case it wasn't clear - this is just a general way of saying "move the commits on this branch since $old to be based on top of $new" instead. You can pick out those old/new commit ID's using gitk or whatever if you wish. Neither the $new or the $old needs to even be an existing branch - just pick them with gitk. So if you literally want to just move the top 5 commits (assuming those top five cmmits are just a nice linear thing you did) from the current branch to be on top on another branch instead, you can literally do this: # save this state, maybe we want to keep it around. Call it "old" git branch old-branch # rebase the top five commits onto $target git rebase --onto $target HEAD~5 ta-daa - all done. The branch you are on will now have been rewritten to be the top five commits moved to be on top of the $target you chose, and if you want to get back the old state, it's nicely squirrelled away in "old-branch". (That obviously assumes no merge conflicts - you'll have to resolve those yourself ;) Of course, if you didn't even want to save the old branch, just skip the first step. If you have reflogs enabled (and git does that by default in any half-way recent version), you can always find it again, even without having to do "git fsck --lost-found", at least as long as you don't delete that branch, and it hasn't gotten pruned away (kept around for the next 90 days by default, iirc) Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, James Bottomley wrote: > > Right at the moment, I maintain a and a -base and > simply cherry pick the commits between the two to do the right thing > when I know my volatile base has changed. It would be very helpful to > have a version of rebase that new my base had been rebased. Hey, I know, you could use.. drumroll.. "git rebase" I know that's a big leap of faith, to use git rebase for rebasing, but there you have it. Us git people are kind of odd that way. IOW, if you know the old broken base, and the new base, just do git rebase --onto newbase oldbase and it should do exactly that (basically lots of automated cherry-picks). [ But the fact is, if you did anything fancy (like pulled in other peoples work), you cannot sanely rebase _those_ peoples work. They didn't screw up to begin with! You can play with "git rebase -i --preserve-merges", of course, but I really think you're doing something wrong if you start pulling other peoples work into an unstable thing, so while it may work, I'd strongly suggest against even trying, because the problem is your workflow ] So let's say that you have a remote branch that you track that goes rebasing (let's call it "origin/pu" to match the real-life git behaviour), then you should literally be able to do old=$(git rev-parse origin/pu) && git fetch && new=$(git rev-parse origin/pu) && git rebase --onto $new $old and no, I didn't actually test it, but hey, it really should be that simple. [ And no, you don't really need to do those "old=" and "new=" things, they are there to make it explicit - you could easily just have done git fetch .. oh, noticed that origin/pu changed .. git rebase --onto origin/pu origin/[EMAIL PROTECTED] where we just let git take care of the old/new itself using the reflog, so that "origin/[EMAIL PROTECTED]" assumes that you just know that the only thing that has changed origin/pu was that previous "git fetch", and that really *did* change it. ] In other words, git does give you exactly what you want, but nothing really changes the fact that you should only rebase like this only if: - you haven't already exported the result (or only exported it as those unstables branches that people know to avoid) - your changes on top are just your own linear series of commits (where "applying a patch from somebody else" is still _your_ commit, of course, just with authorship attributed to somebody else) so that part really is very fundamental. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 18:35 -0800, Linus Torvalds wrote: > > On Tue, 12 Feb 2008, James Bottomley wrote: > > > > Yes, this is exactly the feature I'm looking for. It would allow the > > downstream users of a rebased tree to rebase themselves correctly. > > > > All the information about the rebase is in the reflog ... it can't be > > too difficult to pass it through on a pull and allow the downstream tree > > to do the right thing. > > Guys, you simply have no idea what you're talking about. > > Those downstream trees can have done things themselves. They *depended* on > the state you gave them. > > You can't just say "oops, I lied, this is the state you should have used, > now it's _your_ mess to sort out". > > OF COURSE it's what you'd like to use - it absolves you of any and all > actual responsibility. But dammit, that's not what anybody else wants than > the irresponsible person who cannot be bothered to stand up for his work! > > If you're not confident enough about your work, don't push it out! It's > that simple. Pushing out to a public branch is a small "release". > > Have the f*cking back-bone to be able to stand behind what you did! Erm, I would like this feature as a downstream user. I'm not asking for this to be the default or even easily available. However, when you know you've based a downstream tree on what you know to be a volatile base, it would be very useful information to have. Right at the moment, I maintain a and a -base and simply cherry pick the commits between the two to do the right thing when I know my volatile base has changed. It would be very helpful to have a version of rebase that new my base had been rebased. Basing on a tree I know to be volatile is sometimes a development decision I make as a downstream user ... I'm just wishing the tools could help me handle the problems better. James - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, James Bottomley wrote: > > Yes, this is exactly the feature I'm looking for. It would allow the > downstream users of a rebased tree to rebase themselves correctly. > > All the information about the rebase is in the reflog ... it can't be > too difficult to pass it through on a pull and allow the downstream tree > to do the right thing. Guys, you simply have no idea what you're talking about. Those downstream trees can have done things themselves. They *depended* on the state you gave them. You can't just say "oops, I lied, this is the state you should have used, now it's _your_ mess to sort out". OF COURSE it's what you'd like to use - it absolves you of any and all actual responsibility. But dammit, that's not what anybody else wants than the irresponsible person who cannot be bothered to stand up for his work! If you're not confident enough about your work, don't push it out! It's that simple. Pushing out to a public branch is a small "release". Have the f*cking back-bone to be able to stand behind what you did! Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 2008-02-12 at 17:20 -0800, David Miller wrote: > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. > > A rebase is just a series of events, and those could propagate to > people who are pulling from the tree. I'm pretty sure GIT could > support this. Yes, this is exactly the feature I'm looking for. It would allow the downstream users of a rebased tree to rebase themselves correctly. All the information about the rebase is in the reflog ... it can't be too difficult to pass it through on a pull and allow the downstream tree to do the right thing. James - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
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. So this is what I do for ext4 development. We maintain a quilt series in git, which is located here at: http://repo.or.cz/w/ext4-patch-queue.git A number of ext4 developers have write access to commit into that tree, and we coordinate amongst ourselves and on [EMAIL PROTECTED] I tend to suck it into git using the "guilt" package, and do periodic merge testing with a number of git queues to detect potential merge conflicts. Not as many as James does, but I may start doing more of that once I steal his scripts. :-) The patch queue also gets automatic testing on a number different platforms; for that reason the series files comments which version of the kernel it was last based off of, so the ABAT system can know what version of the kernel to use as the base of the quilt series. I do a fair amount of QA, including copy editing and in some cases rewriting the patch descriptions (which are often pretty vile, due to a number of the ext4 developers not being native English speakers; not their fault, but more than once I've had no idea what the patch description is trying to say until I read through the patch very closely, which is also good for me to do from a code QA point of view :-). Periodically, the patch queue gets pushed into the ext4.git tree and as a patch series on ftp.kernel.org. I've never been very happy with stgit because of past experiences which has scarred me when it got get confused and lost my entire patch series (this was before git reflogs, so recovery was interesting). There's always been something deeply comforting about having the ASCII patch series since it's easy to back it up and know you're in no danger of losing everything in case of a bug. Also, having the patch series stored in ASCII as a quilt stack means that we can store the quilt stack itself in git, and with repo.or.cz it allows us to have multiple write access to the shared quilt stack, while still giving us the off-line access advantages of git. (Yes, I've spent plane rides rewriting patch descriptions. :-) The other advantage of storing the patch stack as a an ASCII quilt series is we have a history of changes of the patches, which we don't necessarily have if you just use stgit to rewrite the patch. So we have the best of both worlds; what gets checked into Linus's tree is a clean patch series, but we keep some history of different versions of a patch over time in the ext4-patch-queue git repository. (I wish we had better changelog comments there too, but I'll take what I can get.) - Ted - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 17:16:03 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 16:37:42 -0800 > > > Well there's a case in point. rcupdate.h is not a part of networking, and > > it is random tree-wandering like this which causes me problems and which > > will cause Stephen problems. > > > > Now, I don't know which tree "owns" rcupdate.h but it ain't networking. > > Probably git-sched. > > > > Nothing in networking depends upon that change (which has a typo in the > > comment, btw) hence it can and should have gone through > > whichever-tree-owns-that-file. > > > > For Stephen's sake: please. > > At least thie time I did make sure that change got posted to > linux-kernel and got properly reviewed by the de-facto maintainer > (Paul McKenney). :-) Ah, thanks for that - I'm behind in my lkml reading. Again. > I'll toss it. While I was there I spotted a howling bug in rcu_assign_pointer(): a double-touch of the second arg. Nobody has done rcu_assign_pointer(p, something_with_side_effects); before? That would be surpising... Paul has been informed ;) > But how do I do that using GIT without rebasing and without > having this ugly changeset and revert in there? Who, me? umm, get git changed? It seems pretty clear that it isn't matching legitimate kernel development workflow. And it is a tool's job to do that, rather than forcing humans to change there practices. > That's the thing I want answered, and although Al claims it does, > git cherry-pick does not seem to do what I want either. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 17:41:19 -0800 (PST) > Trust me, you don't know how good you have it. I know, preserving history is valuable. I'll take up the various suggestions and try working a little differently this time around. We'll see how well it works. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > But as soon as I've applied any patches to my tree I've "pushed out". > So this scheme doesn't work for me. The first thing I do when I have > changes to apply is clone a tree locally and on master.kernel.org, > then I apply that first patch locally and push it out to master. I actually suggest you literally delay your push-out. I don't generally delay things by a lot, but I tend to try to at least do a compile in between pushing out - and even if I've pulled something in between the thing that broke, I'll just "git reset --hard" to a working state if something broke, and just re-pull instead of even trying to rebase or anything like that. (IOW, I often find it much easier to just start over and re-do than actually doing a rebase). I don't do it all the time, by any means, but there's really no huge reason to push out all the time. And that's doubly true for subsystem maintainers. Quite often, the right thing to do is to only push out when you are ready to do the "please pull" message. > What would be really cool is if you could do the rebase thing, push > that to a remote tree you were already pushing into and others could > pull from that and all the right things happen. It would also be really cool if Claudia Schiffer had decided that hiding under my desk is a good idea. IOW, you really haven't though that through. That is how TLA and darcs worked, and it's a total disaster. Trust me, you don't know how good you have it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:53:50 -0800 (PST) > The fact is, that "outlying code" is where we have all the bulk of the > code, and it's also where we have all those developers who aren't on the > "inside track". So we should help the outliers, not the core code. Good point. For the record I write drivers that use infrastructure too and have to deal with the API changes just as equally :-) - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:49:46 -0800 (PST) > 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. Sounds interesting and nice, but not relevant for my current workflow. I've always "already pushed out". - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:47:26 -0800 > My usual way of fixing these things when they pop up is to just move > the offending addition to some random position other than > end-of-list. I must have done this hundreds of times and as yet I > don't think anyone has noticed ;) That sounds like a real useful usage of your time. I think my proposal saves everyone, including you, this time and the effort necessary to implement it would only need to be expended once instead of this ever present time and learning sink you seem to be advocating. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 12:02:08 +1100 Stephen Rothwell wrote: > Hi all, > > Andrew was looking for someone to run a linux-next tree that just > contained the subsystem git and quilt trees for 2.6.x+1 and I (in a > moment of madness) volunteered. So, this is to announce the creating of > such a tree (it doesn't exist yet) which will require some (hopefully) > small amount of work on the part of subsystem maintainers. > > Those interested in discussion about this are encouraged to join the > [EMAIL PROTECTED] mailing list. > > 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. I am happy for there to be multiple branches/series (in > fact there probably will need to be in some cases where there are > dependencies on others work). Hi Stephen, Please merge the quilt series/patchset from http://oss.oracle.com/~rdunlap/kernel-doc-patches/current/ I expect this to be fairly small and localized (very few conflicts). Thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:44:47 -0800 (PST) > gitk --merge ... > This is something where I actually think git could and should do better: > git has the capability to act as more of a "quilt replacement", but > because it wasn't part of the original design, we never actualy exposed > the simple queue management commands to do this (stgit does things like > that, though). > > So if you haven't pushed out, right now you'd have to do this stupid > thing: Thanks for all the useful info. But as soon as I've applied any patches to my tree I've "pushed out". So this scheme doesn't work for me. The first thing I do when I have changes to apply is clone a tree locally and on master.kernel.org, then I apply that first patch locally and push it out to master. What would be really cool is if you could do the rebase thing, push that to a remote tree you were already pushing into and others could pull from that and all the right things happen. A rebase is just a series of events, and those could propagate to people who are pulling from the tree. I'm pretty sure GIT could support this. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 16:37:42 -0800 > Well there's a case in point. rcupdate.h is not a part of networking, and > it is random tree-wandering like this which causes me problems and which > will cause Stephen problems. > > Now, I don't know which tree "owns" rcupdate.h but it ain't networking. > Probably git-sched. > > Nothing in networking depends upon that change (which has a typo in the > comment, btw) hence it can and should have gone through > whichever-tree-owns-that-file. > > For Stephen's sake: please. At least thie time I did make sure that change got posted to linux-kernel and got properly reviewed by the de-facto maintainer (Paul McKenney). :-) I'll toss it. But how do I do that using GIT without rebasing and without having this ugly changeset and revert in there? That's the thing I want answered, and although Al claims it does, git cherry-pick does not seem to do what I want either. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST) > > > That sure as hell would put the pain on API changes solidly where it > > belongs. > > If a person does a driver API change and does all the work to sweep > the entire tree updating all the drivers, doesn't it penalize that > person a bit much to stick a new driver in front of that work? If that API change doesn't conflict with the work that hundreds of other people do, it's obviously not a problem whichever way it goes. And if the API change *does* cause conflicts, then yes, the onus of fixing those conflicts (again) goes to the person who changed the API. Everybody else did everything right. > People write code on top of infrastructure, both new and old, not the > other way around. At least to me, that seems how the merging ought to > work too. You think that infrastructure is more important than outlying code. But you do that only because you write the infrastructure, not because you have any logical reason to think so. The fact is, that "outlying code" is where we have all the bulk of the code, and it's also where we have all those developers who aren't on the "inside track". So we should help the outliers, not the core code. And very fundamentally, API changes are to be discouraged. If we make them harder to do and make people think twice (and occasionally say "not worth it"), that sounds like a damn good thing to me. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
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. A pure patch-stack will be faster at that thing than git would be (it's simply easier to just track patches), but on the other hand, using git would get some other advantages outside of the integration issue (eg the cherry-pick thing really is a proper three-way merge, not just an "apply patch", so it can do better). It wasn't the original goal of git, but not only are really doing all the series management anyway (that is largely what "rebase" is all about, after all), but the git goals have obviously expanded over time too. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 16:41:49 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
> Here are some odd-the-cuff
> suggestions:
>
> 1) Make feature-removal-schedule a directory with files in it.
>Everyone touches that file, creating merge issues.
>
> 2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
>instead have each "thing" have it's own Kconfig.foo or
>Makefile.foo that gets automatically sucked into the main
>directory Makefile or Kconfig using file globs or similar.
>
>Even better, encode the building of things into the *.[ch]
>files themselves, and have the Kconfig/Makefile machinery
>automatically extract this information when you build.
3) teach people that you don't always have to add new includes right
at the end of the list
4) teach people that you don't have to add Makefile rules right at the
end of the list
5) ditto feature-removal
6) ditto lots of other things.
My usual way of fixing these things when they pop up is to just move the
offending addition to some random position other than end-of-list. I must
have done this hundreds of times and as yet I don't think anyone has noticed ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008, David Miller wrote: > > At 1500 changesets, a merge conflict shows up about once > every day or two as 2.6.N nears it's release into final > as bug fixes trickle in. > > I find using GIT to fixup merge errors on a tree of that > scale to be really painful. And it only fixes up the final > result in a merge changeset. Heh. I've had the reverse situation: "git rebase" often results in *more* conflicts than "git merge" (ie "pull"). But one issue is also that when conflicts happen, different people are used to different things. I'm particularly used to merge-type conflicts, and in fact there's some fairly advanced support in git for helping resolve them that people who *don't* do merge-level conflict resolution may not even be aware of. In particular, if you want to try it, do something that conflicts and then do gitk --merge to see what the conflict is all about. That is just fancy shorthand for gitk HEAD...MERGE_HEAD -- so what it does is to show only the relevant history (the three dots means that it's a _symmetric_ set difference from HEAD to MERGE_HEAD) for the merge, and only for the particular files that had conflicts! This often means that even when you merge a thousand commits (or the thing you merge *into* has thousands of commits since the merge base, which is the common case for me), you actually only see a couple of commits - only the ones that actually modified the conflicting files! (If you have many files that conflict, you can further narrow it down to just one at a time by explicitly listing the file/directory you want to work on, ie do "gitk --merge "). > Let me give you a good example, just yesterday I had to rebase > my net-2.6 tree a few times. It's because I put a patch in there > that the person said was OK but it broke the build. There is > zero reason for me to push that tree to Linus with the bad > commit and the revert, it's just noise and makes the tree harder > for people to review. Actually, better than rebase in that situation is to just remove the bad commit. Yes, you'd use "rebase" for it, but you'd use it not to move the whole series to a newer place, you'd use it just to rebase the commits *after* the commit you remove. This is something where I actually think git could and should do better: git has the capability to act as more of a "quilt replacement", but because it wasn't part of the original design, we never actualy exposed the simple queue management commands to do this (stgit does things like that, though). So if you haven't pushed out, right now you'd have to do this stupid thing: [ start (and activate) a 'fixup' branch at X ] git checkout -b fixup X [ edit edit edit to fix it up ] .. [ commit the fixed state ] git commit --amend [ go back to the old broken state ] git checkout master [ now, rebase 'master' on top of the fix ] git rebase fixup [ ok, done, forget the fixup branch ] git branch -d fixup and I don't discourage this kind of behaviour at all, but it is only good iff: - you have not pushed things out (obviously), so nobody ever even notices that you've fixed up stuff - you haven't pulled anything from outside (so you aren't trying to rebase other peoples commits). If you *really* want to try to do this even across merges you've done, there is fancy a "--preserve-merges" thing that you can try to use (needs "-i" to work, but "-i" is often cool for other reasons too!) Basically, what I'm trying to say is that "git rebase" can be used in fancy ways to do things that people outside your repository will never even *know* were done. It's only when outsiders can see the effects of git rebase that you're in trouble! Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Greg KH <[EMAIL PROTECTED]>
Date: Tue, 12 Feb 2008 11:15:53 -0800
> On Tue, Feb 12, 2008 at 10:26:53AM -0800, Linus Torvalds wrote:
> > We absolutely MUST NOT have the mindset that "cross-subsystem conflicts
> > happen all the time".
>
> They usually don't, by virtue of our current development model and how
> we have the kernel structured.
BTW, there are some things we can do to with the kernel structure
to help a lot of really idiotic cases. Here are some odd-the-cuff
suggestions:
1) Make feature-removal-schedule a directory with files in it.
Everyone touches that file, creating merge issues.
2) Let's move away from some/dir/{Kconfig,Makefile} schemes and
instead have each "thing" have it's own Kconfig.foo or
Makefile.foo that gets automatically sucked into the main
directory Makefile or Kconfig using file globs or similar.
Even better, encode the building of things into the *.[ch]
files themselves, and have the Kconfig/Makefile machinery
automatically extract this information when you build.
Little things like this would go a long way to eliminating merge
hassles.
For example, with #2, when a driver is added it would only
every add files never edit existing files. Merge conflicts
are impossible unless two new drivers try to use the same
file names. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 15:58:53 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > But right now I have to redo the include/linux/rcupdate.h that's in > there because it has a bug. Well there's a case in point. rcupdate.h is not a part of networking, and it is random tree-wandering like this which causes me problems and which will cause Stephen problems. Now, I don't know which tree "owns" rcupdate.h but it ain't networking. Probably git-sched. Nothing in networking depends upon that change (which has a typo in the comment, btw) hence it can and should have gone through whichever-tree-owns-that-file. For Stephen's sake: please. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 10:59:00 -0800 (PST) > That sure as hell would put the pain on API changes solidly where it > belongs. If a person does a driver API change and does all the work to sweep the entire tree updating all the drivers, doesn't it penalize that person a bit much to stick a new driver in front of that work? People write code on top of infrastructure, both new and old, not the other way around. At least to me, that seems how the merging ought to work too. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 10:48:38 -0800 (PST) > On Tue, 12 Feb 2008, James Bottomley wrote: > > Yes ... I don't do that ... Like I said, I only rebase for an actual > > conflict. > > And this is how things should work. And if conflicts happen every day, what should someone do? This isn't fantasy, that's exactly how things got with the networking tree near the end of 2.6.24. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Linus Torvalds <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 10:26:53 -0800 (PST) > We absolutely MUST NOT have the mindset that "cross-subsystem conflicts > happen all the time". Perhaps not, but self-conflicts are the bigger issue for the networking. If I (or Jeff or John) push a bug fix to you outside of the merge window, that blows the entire development tree because at 1500+ changesets I can guarentee you there will be a merge conflict somewhere. Near the end of 2.6.24 every bug fix I merged to you created a conflict with my net-2.6.25 tree. Every time I rebased there were on the order of 10 to 20 patches with merge conflicts to resolve. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: James Bottomley <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 12:24:42 -0600 > Hm ... I think net is a counter example to this. Rebases certainly work > for them. The issue, I thought, was around the policy of rebasing and > how often. > > I see the question as being one of who creates the history. When > something goes into your tree, that's an obvious history point and we > can't rewrite it. However, when something goes into my trees, I don't > think it's as obviously a history point that has to be preserved, so I > can rebase obviously, rebasing causes disruption, so I don't do it > unless it's necessitated by an actual conflict. And I realize that regrettably I end up rebasing a lot. Let's say that today I merge a TCP bug fix into Linus's 2.6.24-rcX tree. When I have the net-2.6.25 tree going I know that this is going to create merge conflicts with the 80 or so odd TCP patches I have in there. Nobody can pull net-2.6.25 into Linus upstream without having to sift through the merging of that stuff. It never merges cleanly using the automated mechanisms, because since the changes are split up nicely there are long changeset dependency chains. So I rebase, and do the merging work by hand. Next, let's say Jeff merges some net driver bug fixes into upstream, resulting in potential conflicts with the several hundred or so driver changes that are in the net-2.6.25 tree too. In fact near the end of 2.6.24 development, there was a new merge conflict created on a daily basis with the net-2.6.25 tree. You simply cannot avoid this when you're managing 1500+ changes. I even had to rebase the net-2.6.25 tree once or twice in Australia as the merge window was openning up because I could push something cleanly to Linus. There were conflicts created by stuff that got in before the net-2.6.25 tree, mostly in files like the feature removal schedule, Kconfig files, and whatnot. At times I even felt the urge to avoid merging a bug fix upstream because of all the merge conflicts it would create, but I of course can't and won't do that. 8) It actually turns out that things simplify once a tree gets into the -stable folks hands. I pick out bug fixes as they go upstream, and toss it to them once Linus sucks it in and I have an upstream changeset ID to give them. I don't have to worry about -stable changesets causing development merge grief later on. And I've also yet to be shown how to completely remove a changeset from a GIT tree without rebasing :-) - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 03:58:53PM -0800, David Miller wrote: > From: Jeff Garzik <[EMAIL PROTECTED]> > Date: Tue, 12 Feb 2008 11:36:24 -0500 > > > Rebasing is low impact only if you don't have git downstream people. > > Otherwise, you're just treating it as a useful quilt clone, really. > > Understood. > > One of the key operations that I'm interested in is removing things > from the history. If I could do that using GIT without any side > effects and in a way that really would remove it from the tree, I > would do that in a heartbeat. > > At 1500 changesets, a merge conflict shows up about once > every day or two as 2.6.N nears it's release into final > as bug fixes trickle in. > > I find using GIT to fixup merge errors on a tree of that > scale to be really painful. And it only fixes up the final > result in a merge changeset. Perhaps you need to switch to using quilt. This is the main reason why I use it. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
From: Jeff Garzik <[EMAIL PROTECTED]> Date: Tue, 12 Feb 2008 11:36:24 -0500 > Rebasing is low impact only if you don't have git downstream people. > Otherwise, you're just treating it as a useful quilt clone, really. Understood. One of the key operations that I'm interested in is removing things from the history. If I could do that using GIT without any side effects and in a way that really would remove it from the tree, I would do that in a heartbeat. At 1500 changesets, a merge conflict shows up about once every day or two as 2.6.N nears it's release into final as bug fixes trickle in. I find using GIT to fixup merge errors on a tree of that scale to be really painful. And it only fixes up the final result in a merge changeset. Just like we expect submitters to refresh their patches as things change upstream, we as developers should be able to refresh trees of changes we are maintaining for similar effect. This is all made difficult because GIT's commit IDs are tied to where they are in the tree, and thus are dependant upon the wholeness of parents and subsequently their parents. That's why it's hard to "just remove" something completely without rebasing the tree. Let me give you a good example, just yesterday I had to rebase my net-2.6 tree a few times. It's because I put a patch in there that the person said was OK but it broke the build. There is zero reason for me to push that tree to Linus with the bad commit and the revert, it's just noise and makes the tree harder for people to review. Now, to preserver your tree's history I simply reapplied the stuff I wanted then repulled your tree. But right now I have to redo the include/linux/rcupdate.h that's in there because it has a bug. I now want to rebase again to just kick out the existing rcupdate.h changeset, because I know of no alternative that really lets me get rid of the original bogus changeset. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 12:48:13PM -0800, Greg KH wrote: > On Tue, Feb 12, 2008 at 11:55:45AM -0800, Linus Torvalds wrote: > > > > > > Not it isn't. To quote you a number of years ago: > > > "Linux is evolution, not intelligent design" I think this statement has been used unfortunately as a hard and fast rule (which we all know how much Linus loves :-) to mean, in its most extreme form, that we should *never* try to do some careful reflection about careful API design, and that the extremes of "no interface without an in-tree user" applies to (a) parameters in a function call (heck, we can always sweep through all the in-tree users to add that extra parameter later, and thats a *good* thing because it breaks those evil out-of-tree drivers) and (b) to not even thinking if some particular interface (that is not needed now but which reasonably will be needed later) is even *possible* without doing a sweep of all of the in-tree users of the interface. Related to this syndrome is the assumption that measuring the rate of changes in lines of code changed per second implies that any development process which causes the number of lines of code changed second, including frequent sweeps through the tree changing all interfaces, is a *good* thing. Yes, this is an extreme position, and I'm not accusing anyone of holding the above in its entirety --- but I've seen aspects of all of these from one developer or another. We come to it from the attacking another strawman, which assumes that *all* interfaces which don't have an in-tree are evil, and that keeping old __deprecated interfaces for a long time is an evil which causes intolerable pain, and that it's never worthwhile to try to anticipate future expandibility into an interface because you will inevitably get it wrong. Clearly, we are right to mock Solaris for making claims that they will never, ever, *ever* change an interface, not even one that goes back sixteen years to Solaris 2.3. But it doesn't follow the opposite point of view, that constant mutability of kernel interfaces to make sure that things are always perfect and pure and clean is the right one either. > > 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! Also, evolution also means that things like vestigal organs (like our appendix) are tolerated. So are things like clearly very badly designed things, like human backs. To the extent that we don't like vestigal old __deprecated interfaces, and want things to be perfect, we are actually straying into the realms where we want the sort of things that you would get if you *did* have an intelligent designer designing the human body from scratch. So the "Linux is evolution, not intelligent design" quote is unfortunately getting used to imply that no amount of intelligent foresight is worthwhile, and I think that's unfortunate. It implies an extreme position which is not warranted. > > > But they do happen about once or twice a kernel release, just by virtue > > > of the way things need to happen. > > > > And I violently disagree. > > > > It should not be "once of twice a kernel release". > > > > It should be "once or twice a year" that you hit a flag-day issue. The > > rest of the time you should be able to do it without breakage. It's > > doable. You just HAVEN'T EVEN TRIED, and seem to be actively against even > > doing so. > > No, not at all. > > 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. Collectively, we need to try harder. We can debate exactly where the right line is, in terms of whether it's only "once or twice a kernel release", or "once or twice a year", but clearly the current amount of interface changes and cross-tree dependencies has been causing Andrew pain. And to me, that means we need to turn the knob back a quarter turn towards tolerating __deprecated old interfaces a little bit more, and trying to get interfaces right just a little bit more and try building in just a little bit more future expandability, and to try just *little* bit harder to preserve a *little* bit more stable API. In other words, maybe we need to write a counterpoint to the stable_api_nonsense.txt and call it unstable_api_nonsense.txt --- and in it, we note that if we start burning out Andrew and he starts getting really, REALLY grumpy --- and if especially we start making Stephen (normally a very mild-mannered and not terribly excitable guy) grumpy, that it's time that we try just a l
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:59:00PM +, Alan Cox wrote: > On Tue, 12 Feb 2008 14:55:31 -0800 > Greg KH <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote: > > > > I think the best way to get the serial drivers maintained would be to > > > > cat > > > > them all onto the end of synclink.c and hope that Paul thinks he did it. > > > > > > Well I've already broken the buffering so he'd fix it ;) > > > > > > We have a pile of old ISA drivers that are going to break soon with the > > > locking changes and a pile of USB drivers that when I looked at the > > > locking were so terminally broken I couldn't be bothered to fix them. > > > > Let me know which USB ones are broken, I'll work to fix them. > > That I noticed doing an audit for unlocking the mctrl functions: > > ir-usb: global variables without locking used in per port operations > iuu_phoenix: no locking on internal data structures > mos7840: ditto > option: ditto > kobil_sct: ditto > > These drivers do interesting things (where interesting is probably not too > evil on a PC - except ir-usb) involving playing with data structures > without locks. It seems there was some kind of evolution along the way as > some drivers do have a carefully used port private data structure lock > (or two) but many do not. Ok, I'll look into them this week. I'm currently working on revamping the option driver as it had the mistake of being based on the keyspan drivers, which weren't the nicest to start with... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 11:01:32PM +, Alan Cox wrote: > > Hrm... How badly is pl2303 broken? I actually use that sucker, so if > > it needs help - count me in. > > 2303 is pretty good (in fact by usb serial standards outstanding). It has > all the internal locking needed for now and right down to killing > lock_kernel entirely outside of open/close (which is going to hit > everything). > > Only fixme I have tagged for it is > > - if you set an unsupported baud rate it reports it set rather than the > one you got > > Which is a trivial mend for someone who has suitable docs (its marked > FIXME: at the right spot) I'll see what I can do about fixing this. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
> Hrm... How badly is pl2303 broken? I actually use that sucker, so if > it needs help - count me in. 2303 is pretty good (in fact by usb serial standards outstanding). It has all the internal locking needed for now and right down to killing lock_kernel entirely outside of open/close (which is going to hit everything). Only fixme I have tagged for it is - if you set an unsupported baud rate it reports it set rather than the one you got Which is a trivial mend for someone who has suitable docs (its marked FIXME: at the right spot) - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 14:55:31 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote: > > > I think the best way to get the serial drivers maintained would be to cat > > > them all onto the end of synclink.c and hope that Paul thinks he did it. > > > > Well I've already broken the buffering so he'd fix it ;) > > > > We have a pile of old ISA drivers that are going to break soon with the > > locking changes and a pile of USB drivers that when I looked at the > > locking were so terminally broken I couldn't be bothered to fix them. > > Let me know which USB ones are broken, I'll work to fix them. That I noticed doing an audit for unlocking the mctrl functions: ir-usb: global variables without locking used in per port operations iuu_phoenix: no locking on internal data structures mos7840: ditto option: ditto kobil_sct: ditto These drivers do interesting things (where interesting is probably not too evil on a PC - except ir-usb) involving playing with data structures without locks. It seems there was some kind of evolution along the way as some drivers do have a carefully used port private data structure lock (or two) but many do not. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote: > > I think the best way to get the serial drivers maintained would be to cat > > them all onto the end of synclink.c and hope that Paul thinks he did it. > > Well I've already broken the buffering so he'd fix it ;) > > We have a pile of old ISA drivers that are going to break soon with the > locking changes and a pile of USB drivers that when I looked at the > locking were so terminally broken I couldn't be bothered to fix them. Let me know which USB ones are broken, I'll work to fix them. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Mon, Feb 11, 2008 at 11:06:17PM -0800, Arjan van de Ven wrote: > There is maybe a middle ground in this -next idea; as very first > part of the series, the new api gets added, current users converted > and api marked __deprecated. > > Then there's a second part to the patch, which is a separate tree, > which gets added at the very end, which removed the old api. > > Both will go in at the same merge window, and the next-meister needs > to track that no new users show up... but the final tree allows this > to be done somewhat more gentle. > > Doesn't work for API changes that just change the API rather than > extending it, and doesn't solve the dependency issues. So I still > think a cleansweep works best in general, but I suspect Andrew just > disagrees with that. Yes, that's exactly what I was suggesting. The __deprecate only lasts for the merge window, and we remove the old API at the end of the merge window. So it's only there for a very short time, and it's only there to make the cleen sweep a little less painful --- not one where "shit hangs around in the tree forever". - Ted - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote: > > I think the best way to get the serial drivers maintained would be to cat > > them all onto the end of synclink.c and hope that Paul thinks he did it. > > Well I've already broken the buffering so he'd fix it ;) > > We have a pile of old ISA drivers that are going to break soon with the > locking changes and a pile of USB drivers that when I looked at the > locking were so terminally broken I couldn't be bothered to fix them. > > So it'll be fun, lots of && BROKENs to add Hrm... How badly is pl2303 broken? I actually use that sucker, so if it needs help - count me in. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Feb 11 2008 20:21, Greg KH wrote: >> >> I hope to recreate this tree every day automatically. In order to do >> this, any tree that has a conflict will be dropped from that days tree. > >Oh oh oh, I get merged first! me me me! No, you can't have a tree like that. [森林 Not yours. 森林] Let's maximize the profit, by keeping the largest number of trees which do not cause a conflict amongst each other. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
> I think the best way to get the serial drivers maintained would be to cat > them all onto the end of synclink.c and hope that Paul thinks he did it. Well I've already broken the buffering so he'd fix it ;) We have a pile of old ISA drivers that are going to break soon with the locking changes and a pile of USB drivers that when I looked at the locking were so terminally broken I couldn't be bothered to fix them. So it'll be fun, lots of && BROKENs to add - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Announce: Linux-next (Or Andrew's dream :-))
On Tue, 12 Feb 2008 21:51:52 + Alan Cox <[EMAIL PROTECTED]> wrote: > > We could simply decide that API changes affecting more than one subsystem > > Must Be Serialized(tm). Explicitly. As in "any such change is posted > > Welcome to dreamland. The only way I can get serial changes done is to > wait months and eventually simply persuade Andrew to ignore the > "maintainers" who are basically not responding. "maintainers"? I think the best way to get the serial drivers maintained would be to cat them all onto the end of synclink.c and hope that Paul thinks he did it. - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
