Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
Diane Bruce wrote: > There certainly would not be a chance of putting > mercurial or git into base for example. Completely apart from licensing, another strike against mercurial is that it is written in Python, so it couldn't go into base unless Python also went into base. BTW this topic came up on ports@ about 3 months ago: http://lists.freebsd.org/pipermail/freebsd-ports/2010-September/063675.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On 25 January 2011 11:22, wrote: > Diane Bruce wrote: > >> There certainly would not be a chance of putting >> mercurial or git into base for example. > > Completely apart from licensing, another strike against > mercurial is that it is written in Python, so it couldn't > go into base unless Python also went into base. Of course. OTOH, this topic will only become relevant if anyone notices that Subversion gets committed into base ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Why not give git a try?
Hi. This is good topic. I am no body. But I want to mention things. I've use RCS, CVS, SVN, Hg and Git. To me, first three are really much one in same. Of later two still learning, Hg can be slightly easier, but Git has simple analogs too, not much hard to get. We all learn new thing. But overall, Git seems to be on curve as the one become defacto for all good reasons/purpose in new world. Just as was CVS. Coders will know it. Gitweb, etc. So it momentum to maybe break ties, lame but can be true. I am ok with it. Distributed also maybe, maybe, save project bandwidth, as ppl tracking multiple branches should mirror and checkout locally. Not checkout multiple branch over wire. And can work fully local. Yes, maybe distrib not as much enforce commit from private coders often. But people already have those involved/not, regular/not, central/not habits, repo make no diff. Yet better, distrib enables some new good models not possible before too, while still letting some old style happen too. Also, very important this one. Git provide hash authenticated chained repo possibility by default and native with every commit from init of new repo. CVS/SVN do not do that. FreeBSD is big project (with big users). With big project infrastruct. With big group with commit people login from bfe from some fubar systems sometime unknown. All good ppl and systems yes, but deteching errors and provide proofs and chains is important now days in IT worlds. Too, FreeBSD only sign release cd's and only on maj.min release, not security branche, releng branche etc. There is no strong trace back to repo, so link is cut there. It is repo hash that should be sign, first before cd, and from there all things roll down as extra bonus. Does pictures on this important one be clear? And if move beyond CVS/SVN legacy wanted, yes?, start tests, eval, pick and move on :) My local stuffs went CVS to Git, but is no matter that choice to this project topic. I try agnostic. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: >Diane Bruce wrote: >> There certainly would not be a chance of putting mercurial or git >> into base for example. > > Completely apart from licensing, another strike against mercurial is > that it is written in Python, so it couldn't go into base unless > Python also went into base. This argument is actually a bit weak for most of the VCS'es out there (including svn by the way). We don't really *need* to import the full VCS itself into FreeBSD. For instance, Subversion is also not part of the base system. It works fine as a port that people can install. There's really _nothing_ wrong with a VCS that is a port/package. We used to have CVS into the base system as "the official VCS", but this is no longer the case for the subversion repo of src/. IMO this hasn't really caused any major problem with the people who want to check out and patch the source tree. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
FreeBSD Status Report - 4Q/2010
FreeBSD Quarterly Status Report Introduction This report covers FreeBSD-related projects between October and December 2010. It is the last of the four reports planned for 2010. The work on the new minor versions of FreeBSD, 7.4 and 8.2, has been progressing well and they should be released around the end of this month. Thanks to all the reporters for the excellent work! This report contains 37 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between January and March 2011 is April 15th, 2011. __ Projects * BSDInstall * Non-executable Stacks * Webcamd * xz Compression for Packages and Log Files * ZFS pool version 28 FreeBSD Team Reports * FreeBSD Bugbusting Team Status Report * Release Engineering Team Status Report * The FreeBSD Foundation Status Report Network Infrastructure * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Ethernet Switch Framework * Five New TCP Congestion Control Algorithms for FreeBSD * FreeBSD 802.11n * FreeBSD VirtIO Network Driver * Generic IEEE 802.3 annex 31B full duplex flow control support for Ethernet in mii(4) * IPv6 and VIMAGE * TCP SMP scalability project Kernel * Resource Containers * SYSCTL Type Safety * TRIM support for UFS Documentation * mdocml Replacing groff For manpage Rendering * The FreeBSD German Documentation Project Status Report * The FreeBSD Japanese Documentation Project Userland Programs * FreeBSD Services Control (fsc) * GEOM-based ataraid(4) Replacement -- geom_raid * gpart Improvements Architectures * Bringing up OMAP3 * FreeBSD on the Playstation 3 * FreeBSD/EC2 * FreeBSD/sparc64 Ports * Chromium * FreeBSD as Home Theater PC * Port-Sandbox * Portmaster * Ports Additions * Ports Collection * Robot Operating System Miscellaneous * FOSDEM 2011 __ Bringing up OMAP3 URL: http://people.FreeBSD.org/~raj/patches/arm/dove_v6.diff Contact: Warner Losh Contact: Mohammed Farrag The attached file is an old patch for ARM. We are developing new patch and then we are going toward Porting OMAP3. __ BSDInstall URL: http://wiki.FreeBSD.org/BSDInstall Contact: Nathan Whitehorn BSDInstall is a replacement for the venerable sysinstall installer. It is designed to be modular and easily extensible, while being fully scriptable and streamlining the installation process. It is mostly complete, and installs working systems on i386, amd64, sparc64, powerpc, and powerpc64, with untested PC98 support. New Features: * Allows installation onto GPT disks on x86 systems * Can do installations spanning multiple disks * Allows installation into jails * Eases PXE installation * Virtualization friendly: can install from a live system onto disk images * Works on PowerPC * Streamlined system installation * More flexible scripting * Easily tweakable * All install CDs are live CDs Open tasks: 1. Wireless networking configuration wizard. 2. ZFS installation support. 3. Itanium disk setup. __ Chromium URL: http://www.chromium.org/Home URL: http://people.FreeBSD.org/~bapt/chrome9-fbsd.png Contact: René Ladan We are working on updating the Chromium web browser in our ports to stay up to date with the latest supported release. We currently have the Chromium 9 beta running, but not all features are fully implemented and the port still needs some polish before it can be committed to the Ports Collection. We have also been making arrangements with Google to merge our work with their upstream, which should ease the number of features and fixes we have to maintain for ourselves in the future. Our first release should be in a few weeks and coincide with the official release of Chromium 9. __ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander Contact: Grenville Armitage DIFFUSE is a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) techniques to assign flows into classes. In addition to tradit
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On Tue Jan 25 11, Giorgos Keramidas wrote: > On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: > >Diane Bruce wrote: > >> There certainly would not be a chance of putting mercurial or git > >> into base for example. > > > > Completely apart from licensing, another strike against mercurial is > > that it is written in Python, so it couldn't go into base unless > > Python also went into base. > > This argument is actually a bit weak for most of the VCS'es out there > (including svn by the way). > > We don't really *need* to import the full VCS itself into FreeBSD. For > instance, Subversion is also not part of the base system. It works fine > as a port that people can install. > > There's really _nothing_ wrong with a VCS that is a port/package. We > used to have CVS into the base system as "the official VCS", but this is > no longer the case for the subversion repo of src/. IMO this hasn't > really caused any major problem with the people who want to check out > and patch the source tree. imo having a VCS in base is a bad idea. it makes it much harder to keep it in sync with the vendor version. to update a port involves very little administrative work. on the other hand updating vendor software in base involves quite a lot of importing etc. also please don't forget that having a VCS in base means there's only *one* version of the VCS available. having it in the ports tree makes it possible to have a legacy release, a stable release, an experimental release and also a development snapshot. of course there could be a stable release in base and if users want to they can install a more recent version from ports, but that doesn't really make sense imo. also a VCS is not really an essential part of an OS. with clang/llvm e.g. a version must exist in base, since it's not possible to invoke /usr/local in order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). so -1 for moving a new VCS to base. also i think freebsd should stick to a major VCS, like git and not some lesser known obscure VCS. with git you have all the linux people behind it, which means it will be updated regularly, bugs will be fixed quite fast etc. there's no point in switching to some rather unknown VCS where the developers decide after 2 years that they don't have any more spare time and have to abandon the project. to be quite honest: the freebsd community doesn't have the manpower to maintain a VCS by itself. you *need* other developers in order to keep it up to date. just look at GNATS e.g. gnu abandoned it quite a while ago and the bugbusting community is just to small to either update to a more recent version of GNATS or switch to something like bugzilla. again: you *need* support from other developers in order to maintain a VCS properly. so git is the best choice imo. just my 0.02$ cheers. alex > -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pci_suspend/pci_resume of custom pcie board
Hi, I'm in a particular problem where I need to set my custom pcie adapter into d3hot power-mode and a couple of seconds later reset it back to d0. The board has an FPGA directly attached to the pcie interface, and as I need to re-configure the FPGA on the fly, I have to ensure the datalink layer between the upstream bridge and my device is idle to prevent any hickups. On linux I simply do a pci_save_state(device) followed by pci_set_power_state(device, d3hot), then after my magic on my board, I do the reverse: pci_set_power_state(device, d0) followed by pci_restore_state(device). On FreeBSD, say 8, I've found the pci_set_powerstate function, which is documented in PCI(9), but that function does not save nor restore the config space. I've tried, just for the fun of it, to go via pci_cfg_save(device, dinfo, 0) with dinfo being device_get_ivars(device) and then subsequently restoring the config space back via pci_cfg_restore(), but since both those functions are declared in I'm not sure if I'm supposed to use those directly or not.. Besides, I'm not really having any luck with that approach. Reading high and low on the net suggest that not all too many driver devs are concerned with suspend/resume operation of their device, and if they are, leave it to user-space to decide when to suspend/resume a device.. I would like to be able to save off my device' config space, put it to sleep (d3hot), wake it back up (d0) and restore the device' config space directly from the device' own driver.. Anyone who can help me with this? Thanks, Phil ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On Tue, Jan 25, 2011 at 01:40:50PM +0100, Giorgos Keramidas wrote: > On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: > >Diane Bruce wrote: > >> There certainly would not be a chance of putting mercurial or git > >> into base for example. > > > > Completely apart from licensing, another strike against mercurial is > > that it is written in Python, so it couldn't go into base unless > > Python also went into base. > > This argument is actually a bit weak for most of the VCS'es out there > (including svn by the way). Notice I never ever suggested we might want to do such a thing. All I said was there would be not a chance of GPL code being added. The additional argument of mercurial not being added because of its dependancy on python is immaterial. > > We don't really *need* to import the full VCS itself into FreeBSD. For > instance, Subversion is also not part of the base system. It works fine > as a port that people can install. I agree. Indeed, I would argue that there is other code in base that should come out. But I don't want to get that flamefest going again. ;-) The argument is not putting a VCS into base, the argument is what VCS to look at in future. 'fossil' is certainly a viable candidate. I am agreeing the arguments on which VCS to use should be based on the merits of the VCS itself, not on its licence. However, if in the long term we chose 'fossil' and then decided that 'fossil' was absolutely necessary for base, then it would have far less resistance than a GPL VCS. That's a small plus, I never said it was a strong plus. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On Tue, Jan 25, 2011 at 02:05:17PM +, Alexander Best wrote: > On Tue Jan 25 11, Giorgos Keramidas wrote: > > On Tue, 25 Jan 2011 02:22:34 -0800, per...@pluto.rain.com wrote: > > >Diane Bruce wrote: > > >> There certainly would not be a chance of putting mercurial or git > > >> into base for example. ... > > no longer the case for the subversion repo of src/. IMO this hasn't > > really caused any major problem with the people who want to check out > > and patch the source tree. Note I never said it should be importable into base. > also i think freebsd should stick to a major VCS, like git and not some lesser Argumentum ad populum. If the VCS is 1) easy to use 2) easy to maintain and has a body of people working on it already 3) can import other VCS formats, then why not? Also note that using an appeal to popularity suggests we should go with the flow and stop working on llvm/clang. Afer all, everyone else uses gcc. As it happens, fossil is quite tiny, fairly feature rich, BSDL'd and in active development. QED All that being said, I am not interested in bikeshedding right now. Those who will look at the alternatives intelligently should do so. > cheers. > alex - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] nmount ro, rw and negated option handling
On 2011-01-19, Jaakko Heinonen wrote:
> On 2011-01-19, Craig Rodrigues wrote:
> > I disagree with your patch and do not approve it.
>
> > > 1. Have mountd(8) running.
> > > 2. # mdconfig -a -t vnode -f ufsimg
> > > 3. # mount -o ro,rw /dev/md0 /mnt
>
> With your patch[1] after the third step the mount point has both "ro"
> and and "noro" active but the MNT_RDONLY flag is not set. Again, you
> will eventually get the "ffs_sync: rofs mod" (or similar) panic because
> the "ro" option is active during remount.
Could you please elaborate on why my patch isn't acceptable and/or
suggest an alternative approach to fix the bugs. As I said earlier the
patch you posted doesn't solve the issues. I really want to get these
bugs fixed.
One option would be to revert the file system code to use the MNT_RDONLY
flag instead of checking for the "ro" string option until nmount gets
fixed but I don't think it's feasible because too many file systems are
already testing for "ro".
A quick fix for the particular problem above would be to commit the
vfs_equalopts() part of my patch. I believe that the change is correct
as the code stands now. It is not enough to fix PR kern/150206.
Another related bug is in vfs_domount_update(): if VFS_MOUNT() succeeds
but vfs_export() fails, old mount flags and options are restored. I
think this shouldn't happen when VFS_MOUNT() has been already
successfully completed and this is the final reason why FFS fs_ronly and
the MNT_RDONLY flag get out of sync. Does the patch below look sane?
%%%
Index: sys/kern/vfs_mount.c
===
--- sys/kern/vfs_mount.c(revision 217792)
+++ sys/kern/vfs_mount.c(working copy)
@@ -683,8 +683,6 @@ bail:
}
}
- if (error != 0)
- vfs_freeopts(optlist);
return (error);
}
@@ -800,6 +798,7 @@ vfs_domount_first(
}
if (error != 0) {
vput(vp);
+ vfs_freeopts(fsdata);
return (error);
}
VOP_UNLOCK(vp, 0);
@@ -824,6 +823,7 @@ vfs_domount_first(
vp->v_iflag &= ~VI_MOUNT;
VI_UNLOCK(vp);
vrele(vp);
+ vfs_freeopts(fsdata);
return (error);
}
@@ -881,15 +881,15 @@ vfs_domount_update(
struct oexport_args oexport;
struct export_args export;
struct mount *mp;
- int error, flag;
+ int error, export_error, flag;
mtx_assert(&Giant, MA_OWNED);
ASSERT_VOP_ELOCKED(vp, __func__);
KASSERT((fsflags & MNT_UPDATE) != 0, ("MNT_UPDATE should be here"));
if ((vp->v_vflag & VV_ROOT) == 0) {
- vput(vp);
- return (EINVAL);
+ error = EINVAL;
+ goto fail;
}
mp = vp->v_mount;
/*
@@ -898,28 +898,26 @@ vfs_domount_update(
*/
flag = mp->mnt_flag;
if ((fsflags & MNT_RELOAD) != 0 && (flag & MNT_RDONLY) == 0) {
- vput(vp);
- return (EOPNOTSUPP);/* Needs translation */
+ error = EOPNOTSUPP; /* Needs translation */
+ goto fail;
}
/*
* Only privileged root, or (if MNT_USER is set) the user that
* did the original mount is permitted to update it.
*/
error = vfs_suser(mp, td);
- if (error != 0) {
- vput(vp);
- return (error);
- }
+ if (error != 0)
+ goto fail;
if (vfs_busy(mp, MBF_NOWAIT)) {
- vput(vp);
- return (EBUSY);
+ error = EBUSY;
+ goto fail;
}
VI_LOCK(vp);
if ((vp->v_iflag & VI_MOUNT) != 0 || vp->v_mountedhere != NULL) {
VI_UNLOCK(vp);
vfs_unbusy(mp);
- vput(vp);
- return (EBUSY);
+ error = EBUSY;
+ goto fail;
}
vp->v_iflag |= VI_MOUNT;
VI_UNLOCK(vp);
@@ -942,11 +940,12 @@ vfs_domount_update(
*/
error = VFS_MOUNT(mp);
+ export_error = 0;
if (error == 0) {
/* Process the export option. */
if (vfs_copyopt(mp->mnt_optnew, "export", &export,
sizeof(export)) == 0) {
- error = vfs_export(mp, &export);
+ export_error = vfs_export(mp, &export);
} else if (vfs_copyopt(mp->mnt_optnew, "export", &oexport,
sizeof(oexport)) == 0) {
export.ex_flags = oexport.ex_flags;
@@ -958,7 +957,7 @@ vfs_domount_update(
export.ex_masklen = oexport.ex_masklen;
export.ex_indexfile = oexport.ex_indexfile;
export.ex_numsecflavors = 0;
- error = vfs_export(mp, &export);
+ export_error = vfs_export(mp,
Re: pci_suspend/pci_resume of custom pcie board
On Tuesday, January 25, 2011 9:47:35 am Philip Soeberg wrote: > Hi, > > I'm in a particular problem where I need to set my custom pcie adapter > into d3hot power-mode and a couple of seconds later reset it back to d0. > The board has an FPGA directly attached to the pcie interface, and as I > need to re-configure the FPGA on the fly, I have to ensure the datalink > layer between the upstream bridge and my device is idle to prevent any > hickups. > > On linux I simply do a pci_save_state(device) followed by > pci_set_power_state(device, d3hot), then after my magic on my board, I > do the reverse: pci_set_power_state(device, d0) followed by > pci_restore_state(device). > > On FreeBSD, say 8, I've found the pci_set_powerstate function, which is > documented in PCI(9), but that function does not save nor restore the > config space. > > I've tried, just for the fun of it, to go via pci_cfg_save(device, > dinfo, 0) with dinfo being device_get_ivars(device) and then > subsequently restoring the config space back via pci_cfg_restore(), but > since both those functions are declared in I'm > not sure if I'm supposed to use those directly or not.. Besides, I'm not > really having any luck with that approach. > > Reading high and low on the net suggest that not all too many driver > devs are concerned with suspend/resume operation of their device, and if > they are, leave it to user-space to decide when to suspend/resume a > device.. I would like to be able to save off my device' config space, > put it to sleep (d3hot), wake it back up (d0) and restore the device' > config space directly from the device' own driver.. > > Anyone who can help me with this? Use this: pci_cfg_save(dev, dinfo, 0); pci_set_powerstate(dev, PCI_POWERSTATE_D3); /* do stuff */ /* Will set state to D0. */ pci_cfg_restore(dev, dinfo); We probably should create some wrapper routines (pci_save_state() and pci_restore_state() would be fine) that hide the 'dinfo' detail as that isn't something device drivers should have to know. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Is svn.freebsd.org broken
All I noticed this if you try to check out stable/6 or stable/7 from svn.freebsd.org you get stuck whit a missing file Here is the last few lines of my co Afreebsd/tools/regression/usr.bin/jot/regress.wx.out Afreebsd/tools/regression/usr.bin/jot/regress..out svn: In directory 'freebsd/tools/regression/usr.bin/jot' svn: Can't open file 'freebsd/tools/regression/usr.bin/jot/.svn/tmp/text-base/regress.wx.out.svn-base': No such file or directory -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
rtld optimizations
Hello Hackers The NetBSD folks have a nice improvement with the rtld-elf subsystem, known as "Negative Symbol Cache" . http://blog.netbsd.org/tnf/entry/netbsd_runtime_linker_gains_negative Roy Marples roy@ has a simple write up of the change. I took the basic idea from FreeBSD, but improved the performance drastically. Basically, the huge win is by caching both breadth and depth of the needed/weak symbol lookup. Easiest to think of a,b,c,d as a matrix and FreeBSD just cache a row where we cache both rows and columns. Has anyone looked into porting the changes back to FreeBSD ? The improvement on load time for things like firefox, openoffice, and java is huge on NetBSD. It looks like this change could improve load times on FreeBSD in the same ways. -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is svn.freebsd.org broken
On Tue, Jan 25, 2011 at 6:32 PM, Mark Saad wrote: > All > I noticed this if you try to check out stable/6 or stable/7 from > svn.freebsd.org you get stuck whit a missing file > > Here is the last few lines of my co > > A freebsd/tools/regression/usr.bin/jot/regress.wx.out > A freebsd/tools/regression/usr.bin/jot/regress..out > svn: In directory 'freebsd/tools/regression/usr.bin/jot' > svn: Can't open file > 'freebsd/tools/regression/usr.bin/jot/.svn/tmp/text-base/regress.wx.out.svn-base': > No such file or directory Worked for me :/. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: rtld optimizations
On Tue, 25 Jan 2011 21:40:42 -0500 Mark Saad wrote: > Hello Hackers > > The NetBSD folks have a nice improvement with the rtld-elf subsystem, > known as "Negative Symbol Cache" . > > http://blog.netbsd.org/tnf/entry/netbsd_runtime_linker_gains_negative > > Roy Marples roy@ has a simple write up of the change. > > I took the basic idea from FreeBSD, but improved the performance > drastically. Basically, the huge win is by caching both breadth and > depth of the needed/weak symbol lookup. > Easiest to think of a,b,c,d as a matrix and FreeBSD just cache a row > where we cache both rows and columns. > > Has anyone looked into porting the changes back to FreeBSD ? The > improvement on load time for things like firefox, openoffice, and java > is huge on NetBSD. It looks like this change could improve load times > on FreeBSD in the same ways. > This is a second time someone posts this to public mailing list and curiously enough is a second time it suggested that someone else is to do the investigation. From the quick look, the commit in question is more or less a direct rip-off of Donelists we had for ages and as such is completely over-hyped. The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. Said optimization is trivial and easy to try. Here you have it: http://people.freebsd.org/~kan/rtld-symlook-depth.diff Since it only applies to dlsym, it only affects programs that are heavy plugin users, which I suppose is the category OpenOffice and firefox both fall into. Care to do some benchmarks with and without the patch and report the results? I frankly doubt that you'll see any noticeable difference compared to our stock rtld's performance. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On (24/01/2011 11:33), Alexander Best wrote: > On Mon Jan 24 11, Garrett Cooper wrote: > > On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy wrote: > > > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" > > > wrote: > > >>Perhaps we should just set the tinderbox up to sync directly of > > >>cvsup-master instead if that makes it more useful? > > > > > > Can cvsup-master still lose atomicity of commits? I suspect it can, > > > in which case syncing directly off the SVN master would seem a better > > > approach. > > > > I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I > > wonder if it's time to look at another solution to this problem as > > these annoying stability issues don't appear to be going away. What > > about git? > > > > Just some things I'm able to rattle off that come to mind with git.. > > it would also be nice to have github running on freebsd.org. that way it would > be much easier to discuss src changes without having to point people at a > file, > a function or even a specific line. also it would finally kill the > mailinglists, which have lots of issues: spam, broken mailman installation, > people going berserker when they see lines > 80 etc. there have been a few > attempts to introduce a code review system, but since that was all hosted on > foreign websites the idea never cought on and afaik those websites weren't > being supported/promoted by freebsd.org. Having github would be nice, but it's not open source. Another option could be gitorious, there are merge requests with review option[1], patch review, already hosted freebsd repository[2]. All we need as a first step is developers starting accepting merge requests from each other, people use it already[3]. 1. http://blog.gitorious.org/2009/11/06/awesome-code-review/ 2. http://gitorious.org/freebsd 3. http://gitorious.org/freebsd/repositories > but personally i don't expect a change like this to happen in the near future. > basically most of the freebsd administrative people are quite conservative. i > wouldn't be surprised if some them are still trying to run freebsd on their > typewriters. ;) > > cheers. > alex > > > > > Some arguments `for git'... > > > > 1. One tool to rule them all: > >- cvsup/csup can be replaced with git archive [1]. > >- cvs git scales a bit better. > >- less support cost for p4 and lower likelihood of downtime in the > > event of critical failure (perforce's proprietary DB is a pain to > > recover I've recently discovered from other dealings). > >- svn <-> cvs exporter is no longer required as it's all one SCM. > >- As a side-effect, the bits present in CVS and SVN would now be > > 100% in sync, unlike cvs which can lead svn in terms of commits (at > > least that was the case when I last talked to someone about version > > numbering in pkg_install done by re@). > > 2. More evolved tool: > >- branches are cheap and can be local or remote. > >- distributed SCM seem to work well with large groups of developers. > >- works better with branching and merging from what I've seen. > > > > Some arguments against git... > > - The one caveat to cvsup/csup that's awesome is its componentization > > capability, i.e. being able to selectively download components in src > > / ports; I'm not 100% sure but there doesn't appear to be a clear > > analog in git. It might be achievable through gits remote. in > > git-config, git-remote, etc, but I would need to prototype whether or > > not this is true. > > - Higher learning curve. > > - Some slightly annoying nits with stashing local changes when working > > on separate branches (need to talk to git maintainers). > > - > > > > Some more git experienced folks could comment here, but it would > > be nice to unify all of the systems under `one flag' for the sake of > > simplicity and hopefully the sanity of the tool maintainers (Simon, et > > all). > > Thanks! > > -Garrett > > -- > a13x > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Why not give git a try? (was "Re: [head tinderbox] failure on amd64/amd64")
On Tue, Jan 25, 2011 at 11:09 PM, Gleb Kurtsou wrote: > On (24/01/2011 11:33), Alexander Best wrote: >> On Mon Jan 24 11, Garrett Cooper wrote: >> > On Sun, Jan 23, 2011 at 9:16 PM, Peter Jeremy wrote: >> > > On 2011-Jan-21 20:01:32 +0100, "Simon L. B. Nielsen" >> > > wrote: >> > >>Perhaps we should just set the tinderbox up to sync directly of >> > >>cvsup-master instead if that makes it more useful? >> > > >> > > Can cvsup-master still lose atomicity of commits? I suspect it can, >> > > in which case syncing directly off the SVN master would seem a better >> > > approach. >> > >> > I've seen a lot of `self-healing' failures lately w.r.t. cvsup, so I >> > wonder if it's time to look at another solution to this problem as >> > these annoying stability issues don't appear to be going away. What >> > about git? >> > >> > Just some things I'm able to rattle off that come to mind with git.. >> >> it would also be nice to have github running on freebsd.org. that way it >> would >> be much easier to discuss src changes without having to point people at a >> file, >> a function or even a specific line. also it would finally kill the >> mailinglists, which have lots of issues: spam, broken mailman installation, >> people going berserker when they see lines > 80 etc. there have been a few >> attempts to introduce a code review system, but since that was all hosted on >> foreign websites the idea never cought on and afaik those websites weren't >> being supported/promoted by freebsd.org. > > Having github would be nice, but it's not open source. Another option > could be gitorious, there are merge requests with review option[1], patch > review, already hosted freebsd repository[2]. > > All we need as a first step is developers starting accepting merge > requests from each other, people use it already[3]. > > 1. http://blog.gitorious.org/2009/11/06/awesome-code-review/ > 2. http://gitorious.org/freebsd > 3. http://gitorious.org/freebsd/repositories This is only for src though. I was going to start up some mirroring of ports as well on gitorious, but it would have been nice if it could have been covered like so: freebsd/docs.git freebsd/ports.git freebsd/src.git So that way people could just clone one of the above and work merrily in the component as they felt fit, or check out all three and work away as necessary. Plus it would be more 1:1 than it currently is. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is svn.freebsd.org broken
On 2011-01-26 03:32, Mark Saad wrote: svn: In directory 'freebsd/tools/regression/usr.bin/jot' svn: Can't open file 'freebsd/tools/regression/usr.bin/jot/.svn/tmp/text-base/regress.wx.out.svn-base': No such file or directory Your local checkout is most likely broken. Subversion's working copy code is extremely fragile, unfortunately. :( Try running "svn cleanup" in your working copy, in most cases that fixes the failure. If not, just delete the whole working copy, and checkout from scratch again. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
