Re: Kernel SCM saga..
Roman Zippel wrote: It seems you exported the complete parent information and this is exactly the "nitty-gritty" I was "whining" about and which is not available via bkcvs or bkweb and it's the most crucial information to make the bk data useful outside of bk. Larry was previously very clear about this that he considers this proprietary bk meta data and anyone attempting to export this information is in violation with the free bk licence, so you indeed just took the important parts and this is/was explicitly verboten for normal bk users. Yes, this is exactly the information that would be necessary to create a general interop tool between bk and darcs|arch|monotone, and is the fundamental objection I and others have had to open source projects using BK. Is Bitmover willing to grant a special dispensation to allow a lossless conversion of the linux history to another format? -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: It seems you exported the complete parent information and this is exactly the nitty-gritty I was whining about and which is not available via bkcvs or bkweb and it's the most crucial information to make the bk data useful outside of bk. Larry was previously very clear about this that he considers this proprietary bk meta data and anyone attempting to export this information is in violation with the free bk licence, so you indeed just took the important parts and this is/was explicitly verboten for normal bk users. Yes, this is exactly the information that would be necessary to create a general interop tool between bk and darcs|arch|monotone, and is the fundamental objection I and others have had to open source projects using BK. Is Bitmover willing to grant a special dispensation to allow a lossless conversion of the linux history to another format? -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman I'm not going to defend or attack arch since I haven't used it enough. I will say that darcs largely does suffer from the same problem that you describe since its fundamental unit of storage is individual patches (though it avoids the tarball issue). This is why David Roundy has indicated his intention of eventually having a per-file cache: http://kerneltrap.org/mailarchive/1/message/24317/flat You could then make the argument that if you have a per-file representation of the history, why do you also need/want a per-patch representation as the canonical format, but that's been argued plenty on both the darcs and arch mailing lists and probably isn't worth going into here. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex meta data, which has to be managed forever. I doubt that this is really an advantage in the long term. I expect that we were better off serializing changesets in the main repository. For example bk does something like this: A1 -> A2 -> A3 -> BM \-> B1 -> B2 --^ and instead of creating the merge changeset, one could merge them like this: A1 -> A2 -> A3 -> B1 -> B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. Both darcs and arch (and arch's siblings) have ways of maintaining the complete history but speeding up operations. Arch use's revision libraries: http://www.gnu.org/software/gnu-arch/tutorial/revision-libraries.html though i'm not all that up on arch so I'll just leave it at that. Darcs uses "darcs optimize --checkpoint" http://darcs.net/manual/node7.html#SECTION00764000 which "allows for users to retrieve a working repository with limited history with a savings of disk space and bandwidth." In darcs case, you can pull a partial repository by doing "darcs get --partial", in which case you only grab the state at the point that the repository was optimized and subsequent patches, and all operations only need to work against the set of patches since that optimize. Note, that I'm not promoting darcs for kernel usage because of speed (or the lack thereof) but I am curious why Linus would consider monotone given its speed issues but not consider darcs. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex meta data, which has to be managed forever. I doubt that this is really an advantage in the long term. I expect that we were better off serializing changesets in the main repository. For example bk does something like this: A1 - A2 - A3 - BM \- B1 - B2 --^ and instead of creating the merge changeset, one could merge them like this: A1 - A2 - A3 - B1 - B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. Both darcs and arch (and arch's siblings) have ways of maintaining the complete history but speeding up operations. Arch use's revision libraries: http://www.gnu.org/software/gnu-arch/tutorial/revision-libraries.html though i'm not all that up on arch so I'll just leave it at that. Darcs uses darcs optimize --checkpoint http://darcs.net/manual/node7.html#SECTION00764000 which allows for users to retrieve a working repository with limited history with a savings of disk space and bandwidth. In darcs case, you can pull a partial repository by doing darcs get --partial, in which case you only grab the state at the point that the repository was optimized and subsequent patches, and all operations only need to work against the set of patches since that optimize. Note, that I'm not promoting darcs for kernel usage because of speed (or the lack thereof) but I am curious why Linus would consider monotone given its speed issues but not consider darcs. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman I'm not going to defend or attack arch since I haven't used it enough. I will say that darcs largely does suffer from the same problem that you describe since its fundamental unit of storage is individual patches (though it avoids the tarball issue). This is why David Roundy has indicated his intention of eventually having a per-file cache: http://kerneltrap.org/mailarchive/1/message/24317/flat You could then make the argument that if you have a per-file representation of the history, why do you also need/want a per-patch representation as the canonical format, but that's been argued plenty on both the darcs and arch mailing lists and probably isn't worth going into here. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Arjan van de Ven wrote: * "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support it in any case. probably just one of those things implemented in the binary drivers in software, just like the "hardware" IDE raid is most of the time (3ware being the positive exception there) Incorrect. While the logic is is almost certainly implemented in the drivers, there is silicon acceleration of the functionality built into the Nforce4 chipset (unlike the nforce3), and requires almost no CPU time to do its job. Nvidia calls this chipset support ActiveArmor. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
Arjan van de Ven wrote: * hardware firewall -- sounds silly. Pretty sure Linux doesn't support it in any case. probably just one of those things implemented in the binary drivers in software, just like the hardware IDE raid is most of the time (3ware being the positive exception there) Incorrect. While the logic is is almost certainly implemented in the drivers, there is silicon acceleration of the functionality built into the Nforce4 chipset (unlike the nforce3), and requires almost no CPU time to do its job. Nvidia calls this chipset support ActiveArmor. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
Paul Mackerras wrote: Rik van Riel writes: Thing is, the rest of the kernel uses virt_to_phys for two different things. Only one of them has to do with the real physical address, the other is about getting the page frame number. So fix the places that are using virt_to_phys to get the page frame number to use virt_to_pfn instead. :) On native x86, x86-64 and others, the page frame number and physical address are directly related to each other. Under Xen, however, the two are different - and the AGPGART really needs to have the physical address ;) If Xen is letting the kernel program the GART, you just lost any memory isolation between partitions you might have been trying to enforce. :) Since xen only lets the dom0 (privileged domain) program the GART, all of the domU's (non-privileged domains) are still isolated from each other. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
Paul Mackerras wrote: Rik van Riel writes: Thing is, the rest of the kernel uses virt_to_phys for two different things. Only one of them has to do with the real physical address, the other is about getting the page frame number. So fix the places that are using virt_to_phys to get the page frame number to use virt_to_pfn instead. :) On native x86, x86-64 and others, the page frame number and physical address are directly related to each other. Under Xen, however, the two are different - and the AGPGART really needs to have the physical address ;) If Xen is letting the kernel program the GART, you just lost any memory isolation between partitions you might have been trying to enforce. :) Since xen only lets the dom0 (privileged domain) program the GART, all of the domU's (non-privileged domains) are still isolated from each other. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
Alan Cox wrote: On Mer, 2005-03-09 at 22:22, CaT wrote: Argh! Ok. I guess I shouldn't've just bought the card based on this driver then so that I could better debug my problems with my promise cards. 8( Its good hardware. It does lots of neat things providing you run -ac anyway. The raid1 performance is very good and it can do hotplug IDE transparently in hardware raid modes. Its a good solid little controller. Alan Alan...since you disagreed with the earlier characterization of what it would take to get into the mainline kernels, could you let us know what it would take in your opinion? FWIW, I'm happily using it with a -ac kernel. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11-ac1
Alan Cox wrote: On Mer, 2005-03-09 at 22:22, CaT wrote: Argh! Ok. I guess I shouldn't've just bought the card based on this driver then so that I could better debug my problems with my promise cards. 8( Its good hardware. It does lots of neat things providing you run -ac anyway. The raid1 performance is very good and it can do hotplug IDE transparently in hardware raid modes. Its a good solid little controller. Alan Alan...since you disagreed with the earlier characterization of what it would take to get into the mainline kernels, could you let us know what it would take in your opinion? FWIW, I'm happily using it with a -ac kernel. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Patrick McFarland wrote: On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? Speaking as somebody that uses Darcs evey day, my opinion is that the future of OSS SCM will be something like arch or darcs but that neither are ready for projects the size of the linux kernel yet. Darcs is definitely way too slow for really large projects (though great for small to medium sized ones). Last I checked, Arch was still too slow in some areas, though that might have changed in recent months. Also, many people, me included, find the usability of arch to be from ideal. My hope and expectation is that Arch and Darcs will both improve their performance, features, and usability and that in the not too distant future both of them will be viable alternatives for large scale source tree management. The important thing for the health of the SCM ecosystem is that there be ways to losslessly convert and interoperate between them as well as between legacy/centralized systems such as CVS and SVN as well as with BK. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Patrick McFarland wrote: On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? Speaking as somebody that uses Darcs evey day, my opinion is that the future of OSS SCM will be something like arch or darcs but that neither are ready for projects the size of the linux kernel yet. Darcs is definitely way too slow for really large projects (though great for small to medium sized ones). Last I checked, Arch was still too slow in some areas, though that might have changed in recent months. Also, many people, me included, find the usability of arch to be from ideal. My hope and expectation is that Arch and Darcs will both improve their performance, features, and usability and that in the not too distant future both of them will be viable alternatives for large scale source tree management. The important thing for the health of the SCM ecosystem is that there be ways to losslessly convert and interoperate between them as well as between legacy/centralized systems such as CVS and SVN as well as with BK. -Tupshin - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
