Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the I want to have my cake and eat it too Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to solve this problem of release cycles, but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by lead developers in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and go off and do their own thing (be it support their own custom distro, switch to another OS, etc). In the former case, there's duplication of effort, some (or most) of which is
Re: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
Resending to list, forgot to hit reply-all. On Wed, Jun 13, 2012 at 10:06 PM, Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. [snip] Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). [my wishlist snipped] No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . Catch-22. This honestly reads as we can't stop for gas, we're already late. :-) I should have been more clear that I understand that this would require someone to step away from the firehose of work that not having such tools perpetuates. I certainly understand that it requires an effort of will to raise one's head high enough out of the lists/PRs/email swamp long enough, shake off some learned helplessness, and be inspired to tackle one of them. I struggle with that daily myself. There's a Not Invented Here comic strip that is quite applicable: http://notinventedhe.re/on/2010-3-8 [good Garrett summary of the resource problem snipped] So, rather than do things this way by posting wishlist projects that won't happen in the immediate future, why not make developers' lives easier by spreading the load, increasing the domain knowledge in one or more areas, and improving the community in the meantime? Affected companies/the Foundation should have more than enough funds to devote towards a handful of staff to make this a reality, even if the position is part-time. Remember: low hanging fruit - more likely to succeed - quicker/better RoI results. Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) The objections you're raising to my wish list could have been used, in the past, to justify anything from not writing send-pr (which was somewhat low-hanging fruit) to not writing freebsd-update (decidedly less trivial). Not all of my wishlist items require Herculean effort to make progress on. They just require someone who can both code, and see the light at the end of the tunnel that such a project would reveal. It's the never-ending chronic pain and whack-a-mole game of troubleshooting that makes us frame these things as wishes. If we take as an assumption that they're within reach, they might be. It calls to mind the last lines of Say Anything (if I may indulge my John Cusack fanboyhood): Diane Court: Nobody thinks it will work, do they? Lloyd Dobler: No. You just described every great success story. Royce ___ 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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, Jun 13, 2012 at 11:06:15PM -0700, Garrett Cooper wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the I want to have my cake and eat it too Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to solve this problem of release cycles, but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by lead developers in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and go off
Re: Upcoming release schedule - 8.4 ?
On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris ___ 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: Upcoming release schedule - 8.4 ?
On 6/14/12 9:09 AM, Chris Rees wrote: On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. ___ 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: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 06:50:34AM +0200, Wojciech Puchar wrote: does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) The difference is the freeze-and-test work that goes between random date and release time. This requires a nontrivial time committment from both developers and users. mcl ___ 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: Upcoming release schedule - 8.4 ?
On Jun 14, 2012 9:30 AM, Damien Fleuriot m...@my.gd wrote: On 6/14/12 9:09 AM, Chris Rees wrote: On Jun 14, 2012 5:52 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Friends, I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. Chris Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. Too strong wording perhaps; but you can't claim that an EOL stable branch will have the level of support afforded to live branches. That was supposed to be my point, as Mark has also explained. Chris ___ 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: src builds and STDERR
Hello! On Fri, Mar 2, 2012 at 1:24 PM, Eygene Ryabinkin r...@freebsd.org wrote: Thu, Mar 01, 2012 at 09:38:06AM -0800, Garrett Cooper wrote: On Thu, Mar 1, 2012 at 9:01 AM, Chris Rees utis...@gmail.com wrote: On 1 Mar 2012 16:31, Garrett Cooper yaneg...@gmail.com wrote: See: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/029852.html . Why this patch is still not in FreeBSD proper, I do not know. [...] bin/165589 -- thanks! The patch from mailing list was already committed to HEAD more than 2 weeks ago, http://svnweb.freebsd.org/base?view=revisionrevision=231544 Don't see the MFC timeline, though. Max, any plans for MFC? JFYI: I MFC'ed Garret's patch to RELENG_9 several days ago. Max ___ 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: Upcoming release schedule - 8.4 ?
On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot m...@my.gd wrote: I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less MINOR releases as well? (8.4, 8.5, 9.1...) ___ 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: FreeBSD Boot Times
Thanks for the information -- I got scared by SysV init. This actually does look very nice. -Nathan On 06/13/12 13:35, Richard Yao wrote: The OpenRC is sysvinit compatible, but it has few of sysvinit's flaws. It has named runlevels, the presence of an init script does not cause it to start and it is in my opinion a joy to use. I suggest that you try OpenRC before drawing conclusions. You can install Gentoo FreeBSD in a jail. There are instructions for this on the Gentoo wiki: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail If you find deficiencies, I am certain that the OpenRC developers would appreciate feedback regarding them. On 06/13/12 10:19, Nathan Whitehorn wrote: On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falkbfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -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 Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ 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 Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ 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
groups and directories
assume we have timesharing system and multiple users. everyone have his/her home directory and here - the access right and ownership is simple. assume we need two shared directories - a and b directory a must be for user1,user2 and user3, directory b for user3,user4 and user5. things are simple - i create groups a and b, and add user1,2,3 to group a, and user3,4,5 to group b. when any of them create file in those directories, group is automatically added. setting umask to 007 allows anyone else from group to read and modify those files. but when user1 create file first at home directory and then move it to directory a, it still is in group user1. is it possible to make automatic chgrp anyway? or just completely different solution. I don't mean samba/ftp/nfs but directly accessing files by users working on the same machine. ___ 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: Upcoming release schedule - 8.4 ?
On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. This is why I think we need fewer branches so that there is less merging to do. Even in the bad old 4.x days developers would merge things (especially driver updates) from HEAD back to 4.x. If we move X.0 releases farther apart then developers will still MFC things, the issue is that they don't want to MFC to 2 stable branches. -- 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
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 08:20:02AM -0400, John Baldwin wrote: On Thursday, June 14, 2012 12:30:19 am Adrian Chadd wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. This is why I think we need fewer branches so that there is less merging to do. Even in the bad old 4.x days developers would merge things (especially driver updates) from HEAD back to 4.x. If we move X.0 releases farther apart then developers will still MFC things, the issue is that they don't want to MFC to 2 stable branches. I do not find it cumbersome to merge to two branches. What I find quite demotivating is the conflicts and drifted KPI/API. So my usual reaction to the attempt to merge to stable/8 which fails due to conflicts is just remove the MFC reminder. I do sometimes reconsider the choice if explicitely asked by somebody, but I really prefer to not do risky commits to old and presumably stable branches. I do not have much incentive to merge to 8 anyway, except a warm feeling of providing some relief to a peer. So having long-living stable/8 and not having stable/9 means not doing some merges at all, instead of doing just one merge. YMMV. pgp7HnmeiFCiv.pgp Description: PGP signature
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). In theory we try our best to keep -STABLE, well, stable in behavior and not just the API, but in practice any given snapshot of -stable may or may not have uncaught regressions in it. I reiterate, the major difference between -stable and -release is a more thorough QA process for the latter :-) mcl ___ 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: FreeBSD Boot Times
On 6/13/12 6:29 PM, Mehmet Erol Sanliturk wrote: On Wed, Jun 13, 2012 at 3:49 PM, Russell Cattelan catte...@thebarn.com mailto:catte...@thebarn.com wrote: On 6/13/12 2:16 AM, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl mailto:alpine.bsf.2.00.1206130909310.73...@wojtek.tensor.gdynia.pl, Wojci ech Puchar writes: One of the major slowdowns is that we do all the device drivers serially synchronously. Yes definitely. I have been looking into how to potentially defer or parallelize device_attach'es. Defer is turning out to be hard enough since each system is has different requirements to reach a state where it can run /sbin/init. I've started with the John Baldwin's multipass work and have a system stops probing/attaching devices and allows the boot to continue on. The remaining passes I'm triggering from userspace once the system is up. This is all very crude at this point and has been an some work just to understand how the kernel startup code all links together. Note systemd looks interesting from from a demand based startup scheme much like apples launchd. (note systemd uses linux process groups so porting it would take some effort) Ideally it would be nice to get to the point where many devices are only attached once there is a demand for it. Say network interfaces for example: attach it once the init scripts need to config it and then hopefully in an async fashion. Unfortunately that will require locking a bit more fine grain than the current Giant lock. -Russell To reduce the boot time , my opinion is as follows : During install or by using a program , generate a Hardware Profile File . By editing it , mark some devices No check ( for example , a network card or PS/2 mouse or key board , is not connected , RS-232 , Firewire , unused SATA ports , unused IDE ports , etc. , then it is not necessary to check them . ) During boot , first read that Hardware Profile File . Only check ports marked as Check . Linux does this by keeping a list of driver id's and corresponding driver modules. The installers can then generate of list of modules to load based on a scan done at install time. FreeBSD is much more into build everything into the kernel vs having a smaller kernel + modules. There really isn't anything limiting a smaller kernel right now. I have a config with just about everything stripped out to do multipass ordering testing and not have a ton of extra probes going on. After completion of boot , the other ports may checked to update Hardware Profile File if it is requested in Hardware Profile File . Later on , assume a new device is attached . Run the Hardware Profile program to regenerate the Hardware Profile File , or by using dmesg , manually add this device into Hardware Profile File . For removable devices , if some USB , etc. ports are not used , they all may be marked as No Check , for example internal USB ports , unused back panel ports . Making usb async would be a big help in terms of boot time it is one of the slowest subsystems to attach. cam already has a thread for drive scanning but unfortunately the boot still waits for it to scan everything before proceeding. One thing I would like to do is release the boot process once the root drive is found and let the rest of drive discovery happen in the background. The problem that then arises is what is the next barrier point? say when mount -a happening? Right now the rc scripts assume everything is probed and attached. What if the rc scripts could say load all drives, notify me when done, get notification, run mount -a. I was thinking anything new would have to take existing scripts and run them normally. But provide a new framework to allow for things to be migrated over. I do not know such a scheme is useful or not , or usable or not . If I were a boot manager program writer , I would try it . To my knowledge which I may be wrong , at present there is no such a facility . yes something could / should be done. So lets keep the discussion going. -Russell Thank you very much . Mehmet Erol Sanliturk signature.asc Description: OpenPGP digital signature
Re: FreeBSD Boot Times
Brandon writes: Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell 0.5-2 seconds from power-on to a shell prompt? How do you get through the firmware that fast, much less firmware plus an OS? Which reminds me, back when I was triple-booting Free, Net, and penguinix, I noticed that when rebooting, penguinix didn't go through all the firmware stuff like the BSDs do. That is one way to save a lot of time, at least for reboots. ___ 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: Upcoming release schedule - 8.4 ?
does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) Except STABLE is no good for production, and the problem is EoL- updates and support stop. using RELENG_8 everywhere except my private laptop with 9. ___ 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: Upcoming release schedule - 8.4 ?
I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). I've moved us to 8.3-STABLE recently and am quite happy with it, so far. as most people do who needs FreeBSD to perform crucial work. FreeBSD 9 is an improvement but still i would not classify it as stable. ___ 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: FreeBSD Boot Times
Linux does this by keeping a list of driver id's and corresponding driver modules. The installers can then generate of list of modules to load based on a scan done at install time. what a problem to compile custom kernel? ___ 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: FreeBSD Boot Times
That is a fairly common response. I would appreciate suggestions on how I can convey that OpenRC is a good init system. Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. On 06/14/12 10:34, Nathan Whitehorn wrote: Thanks for the information -- I got scared by SysV init. This actually does look very nice. -Nathan On 06/13/12 13:35, Richard Yao wrote: The OpenRC is sysvinit compatible, but it has few of sysvinit's flaws. It has named runlevels, the presence of an init script does not cause it to start and it is in my opinion a joy to use. I suggest that you try OpenRC before drawing conclusions. You can install Gentoo FreeBSD in a jail. There are instructions for this on the Gentoo wiki: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail If you find deficiencies, I am certain that the OpenRC developers would appreciate feedback regarding them. On 06/13/12 10:19, Nathan Whitehorn wrote: On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falkbfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -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 Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ 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 Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ 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
Import crt{begin,end}.S from NetBSD
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to import it
in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
___
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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 23:06:15 -0700 Garrett Cooper yaneg...@gmail.com wrote: On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). There's a GSoC project underway for this. - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . We have the ideas list for this (http://wiki.freebsd.org/IdeasPage). While it does not attract that much people during the year, it attracts a lot of students which want to participate in the GSoC. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, 13 Jun 2012 22:32:08 -0800 Royce Williams royce.willi...@gmail.com wrote: Even one item from my wish list would lower the branches so that more people could reach the fruit. :-) Well... maybe this year for the crashdump auto-submit part. For the rest I suggest to provide some text suitable for the ideas list (see my other reply). Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Solving the great resource problem
Spending resources to create more releases is pointless when the PRs aren't getting fixed. Oh, Look! Release 9.2.2.2.2.2 is out! The system still crashes every 5 seconds, but a typo on the true(1) man page is fixed. We need a more global discussion about all the things that resources are spent on, and which are the most useful. Replacing perfectly good components simply because they are GPL. The purpose of BSD is supposed to be creating a great OS, not providing software hoarders with a supply of free code to abuse. Sending people to conferences. Nice, but clearly a luxury. Meanwhile the hardware support is a disaster. PRs sit for years and years and years. The documentation has plenty of room for improvement. It seems there are never enough resources to fix problems, but somehow there are always resources to do yet another fork. FreeBSD, NetBSD, OpenBSD, DragonflyBSD, and now Bitrig. ___ 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: Solving the great resource problem
On Thu, 14 Jun 2012 15:23:11 -0500, Dieter BSD dieter...@engineer.com wrote: Replacing perfectly good components simply because they are GPL. The purpose of BSD is supposed to be creating a great OS, not providing software hoarders with a supply of free code to abuse. You realize that companies like Juniper have a huge investment in FreeBSD and the less GPL code they have to deal with the better. FYI they give back to us with things like code drops and paid developers. ___ 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: Upcoming release schedule - 8.4 ?
All I have an partial solution to this issue I was thinking about this on my morning train ride, so its a bit bumpy. Here are my solutions they are not complete but I think its a good start. 1. When official errata and security updates hit the tree . Providing updated install media could be step one . Maybe rebuild install media periodical say every 3 months, if it warrants it. 2. Change FreeBSD-update to allow you to select what updates you want, and make it work for stable. Simply put think freebsd-update fetch stable kernel or freebsd-update fetch release base 3. Change FreeBSD-update to tweak a library so the -pN level is not hardcoded into the kernel at compile time. Currently FreeBSD's patch or p level -pN is a newvers.sh function . 4. Publish a longer time line for future releases and make it easier to find. While ken smith's email about the 9.1-RELEASE time line was a good start , for 9.1,I feel that a short general time line on http://www.freebsd.org/releases/ would do a world of good for people want to know whats up next and when can I expect it. It does not need to be exact just a rough estimate. The sum total of all of this , in my eyes, is when updated drivers ( I know its a still a wish and not reality ) , bug fixes , security updates are released , new installs done around that time will start out with all of the good bits. Secondly when new updates are released users can apply base updates and kernel updates to both release and stable as needed. Lastly updates released via this new method would be easily checked via uname -a or maybe freebsd-update show version Fire away. --- Mark Saad | mark.s...@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: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 15:13, Mark Felder f...@feld.me wrote: On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot m...@my.gd wrote: I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less MINOR releases as well? (8.4, 8.5, 9.1...) Less major, I don't mind minor ones as much to be honest. I welcomed 8.3 with open arms, I'm steering clear of 9.x ___ 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: Upcoming release schedule - 8.4 ?
On 14 Jun 2012, at 16:41, Mark Linimon lini...@lonesome.com wrote: On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). In theory we try our best to keep -STABLE, well, stable in behavior and not just the API, but in practice any given snapshot of -stable may or may not have uncaught regressions in it. I reiterate, the major difference between -stable and -release is a more thorough QA process for the latter :-) mcl We're indeed pretty happy with 8-STABLE :) We're ready to take the risk of a regression if the update squashes a bug that's a major PITA Thanks for your work on the project guys___ 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: Import crt{begin,end}.S from NetBSD
On Thu, 14 Jun 2012 14:54:28 -0400
Richard Yao r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to import
it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do that?
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Import crt{begin,end}.S from NetBSD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/12 20:51, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 14:54:28 -0400
Richard Yao r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to import
it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do that?
These components should not be tied to a specific compiler. If GCC is
going to be deprecated, then they should be replaced.
Anyway, having this tied to GCC has caused headaches for Clang
integration in Gentoo. In particular, we let the user pick the toolchain
that he uses, so we cannot place GCC's crt{begin,end}.o in the same
location that FreeBSD uses. This makes it difficult for Clang to find
the correct crt{begin,end}.o. We will likely import the NetBSD
crt{begin,end}.S code to rectify this, but it would be preferable to do
this in upstreamFreeBSD.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP2pcyAAoJECDuEZm+6ExkVTgP/0fjD1+pvrwKypxIg9KoqJ0+
iwKcKVir8Hwi+lADb2xG1rmDXK/KuFp838Fxr02HTECsWKnH477GNb5WNiDT52Uc
jHfs9g8lY7W4BRNjnbVj0RxgZx8xhLFnrOUBrvkTd84Y5Mi+Y0qXx19+2L+NFVGd
ZHY6ndeggAsyhAo0kaakMLqnAPDqjHhgk7SUJPeH/Zy7KtrO8MFeEwNUVzjXYytW
YXmayxqyDjtN0UdYC7vHnes5dA6aiWDN4/LZTzybRz0GGaKkOXPPoN5QBFUen91j
YHwiCh9NxHOXdEuYLYk1PVu29T6lUE+4U+2k57wRsODEnhgwDyh5184wYfs3gp2k
ttsgBun4aH0AHNdUK6G0XLx/dR7hAPxommmRYVclr/7EpCYhHRDKGvGXUvK8XC79
+ON55vfGCho3kqevjGsQZR1f5hXbKKaKu8JqGQT3LaGz1eSs8jLRDilYA7nTKstY
rx83HU0YQa9c+NdZBYnHXgwjJXJLxIL6rr8E7NQE/co99iNKnHgyar9B6RwbDLMZ
iHX5PUOXikb7OOaXGTNCQas59eO6tHnNrWbmknm59w8fkOjXeiKEliT3Xk8qlLZx
l29JmAPMYzuNNoF0RJJ9QvUUJ9Q8CVScrzJVw4PuVdzJMSrKmG9/ggh2yDw161Lp
DJ8ETPIuVOCGdH2G2mqs
=51Ky
-END PGP SIGNATURE-
___
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: Import crt{begin,end}.S from NetBSD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 14 Jun 2012 22:00:18 -0400
Richard Yao r...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/12 20:51, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 14:54:28 -0400
Richard Yao r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to
import it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do that?
These components should not be tied to a specific compiler. If GCC is
going to be deprecated, then they should be replaced.
Anyway, having this tied to GCC has caused headaches for Clang
integration in Gentoo. In particular, we let the user pick the
toolchain that he uses, so we cannot place GCC's crt{begin,end}.o in
the same location that FreeBSD uses. This makes it difficult for
Clang to find the correct crt{begin,end}.o. We will likely import the
NetBSD crt{begin,end}.S code to rectify this, but it would be
preferable to do this in upstreamFreeBSD.
Assuming NetBSD version is a direct plugin for crtbegin/end provided
by GCC, I see no reason why we cannot do that. Are you are willing to do
the work and submit the patch, or would like to wait for someone on
our side?
- --
Alexander Kabaev
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
iD8DBQFP2pzlQ6z1jMm+XZYRAj9DAKDiYhGiRDL9Ow8/fkcBW+EOX1DrJwCfdJH7
bL9t1FXvMhua6bu2Sv5BwGE=
=DbLg
-END PGP SIGNATURE-
___
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: Upcoming release schedule - 8.4 ?
Hi, 9 will mature as people use it and report bugs/regressions. It would be really great if you could try some of your workload on -9 and provide feedback and file PRs. Engaging with the community (and hiring developers :) is by far the best way to get things to mature quickly. 2c, Adrian ___ 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: Import crt{begin,end}.S from NetBSD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/12 22:24, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 22:00:18 -0400 Richard Yao r...@gentoo.org
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 06/14/12 20:51, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 14:54:28 -0400 Richard Yao
r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to
import it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do
that?
These components should not be tied to a specific compiler. If
GCC is going to be deprecated, then they should be replaced.
Anyway, having this tied to GCC has caused headaches for Clang
integration in Gentoo. In particular, we let the user pick the
toolchain that he uses, so we cannot place GCC's crt{begin,end}.o
in the same location that FreeBSD uses. This makes it difficult
for Clang to find the correct crt{begin,end}.o. We will likely
import the NetBSD crt{begin,end}.S code to rectify this, but it
would be preferable to do this in upstreamFreeBSD.
Assuming NetBSD version is a direct plugin for crtbegin/end
provided by GCC, I see no reason why we cannot do that. Are you are
willing to do the work and submit the patch, or would like to wait
for someone on our side?
Gentoo FreeBSD is currently based on FreeBSD 9-RELEASE. I plan to do
the work to import this downstream within the week, but I am not
running CURRENT. It might be necessary to iterate on the patches
before they can be merged. When I have them, should I file a PR or
post them to the list?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP2qB8AAoJECDuEZm+6Exk9YIP/ih8FwyH48zp1GH4vtlF3NAq
kxqCefhDvgys+np6eYO65W7Gy55NGlwXuRlI8V5sVPea8pgFAXPceGureKrdJCda
HpTdSi/KTAg0Is9PO6Ev4AoLYhEslCbMbQCOAWhRymZIn2MuuEQMjWw8aRWayebJ
VVAIBLzUGrWlHxwfgkaxvO5V4obbetVFewJH+3X9kUDDawXZAYuTl+Llo4GW7lLn
z8/rOciUDqDKy1vFr7R/9998ruJpRG5hAfeA/ovZTUYkO0bmAOpMWrjA9z/rzBEq
2kKAyeQLYfcCtChWvtl3y3WwhBp7uJfbKhiNZlbg8iVZ4YVVJ4xxFUCsz+7CvAwt
BTJ3/Lt1xdrxvMTE/N8b/AwRW/sGgeEqdukPHFhhIbkYRHvvhU7LC7fXC3UxfhP4
J+KHQS1e2jjqqJUnFKa1g5AE6heB2ZlfCNIJH3pZXYGAfz9ff4000az+u9klYSOY
58mL3IR9X0BZboyG263P5cVsyYuT3BEhpEIhUzcvfJvS+vD8lBSYhkub2tgx27Hu
+ov0zvhefZfOpnIRv8K4/KTuEd2scVx4hwOOcnr79PZhPfuyEqqybqrgUJeHH7in
cviufLF0YpMwAutiE5g5ySKPlomKjRR3jRhJO9KyQ0giViT5Ppt/aq4UHb6WJDtf
KVWinFLrnibIKUWJczXZ
=brrQ
-END PGP SIGNATURE-
___
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: Import crt{begin,end}.S from NetBSD
On Thu, Jun 14, 2012 at 7:39 PM, Richard Yao r...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/12 22:24, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 22:00:18 -0400 Richard Yao r...@gentoo.org
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 06/14/12 20:51, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 14:54:28 -0400 Richard Yao
r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to
import it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do
that?
These components should not be tied to a specific compiler. If
GCC is going to be deprecated, then they should be replaced.
Anyway, having this tied to GCC has caused headaches for Clang
integration in Gentoo. In particular, we let the user pick the
toolchain that he uses, so we cannot place GCC's crt{begin,end}.o
in the same location that FreeBSD uses. This makes it difficult
for Clang to find the correct crt{begin,end}.o. We will likely
import the NetBSD crt{begin,end}.S code to rectify this, but it
would be preferable to do this in upstreamFreeBSD.
Assuming NetBSD version is a direct plugin for crtbegin/end
provided by GCC, I see no reason why we cannot do that. Are you are
willing to do the work and submit the patch, or would like to wait
for someone on our side?
Gentoo FreeBSD is currently based on FreeBSD 9-RELEASE. I plan to do
the work to import this downstream within the week, but I am not
running CURRENT. It might be necessary to iterate on the patches
before they can be merged. When I have them, should I file a PR or
post them to the list?
File a PR, post a link to the PR on a list / to devs generally is
the best way to go.
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
