Re: propose: all arch move into a separate dir
In article 20100307.144736.420173476735197890@bsdimp.com, Warner Losh i...@bsdimp.com writes: We don't have quite as many problems as the NetBSD/OpenBSD crowd in this respect. They tend to define a new MACHIINE more often then we have (or will). The need for sys/arch is less severe here than there because we don't have 40 different MACHINEs. Even if we did, I cannot think of any compelling reason to make such a change (and I don't recall one ever being brought up in our entire history). If we had forty architecture directories in /sys, so what? Why should it matter to anyone? If we were talking about 100 architectures, I might feel differently, but in this universe, we have, what? eight? And there are how many architectures currently in mass production? This whole discussion is ridiculous. -GAWollman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message 201003080329.o283tqic011...@hergotha.csail.mit.edu, Garrett Wollma n writes: If we were talking about 100 architectures, I might feel differently, but in this universe, we have, what? eight? And there are how many architectures currently in mass production? This whole discussion is ridiculous. Actually, that conclusion is probably premature. The System-On-Chip concept is boiling over these days, and everybody and his brother are designing CPUs for themselves. 100 is unlikely, but 8 may be 20 in two years time, depending on the way the wind blows. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Sat, 6 Mar 2010, David O'Brien wrote: No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. Indeed, this is precisely the problem: rearranging the tree upstream means that you most likely can't use the revision control system to manage your local difference set downstream. Instead, you have to manually extract your local changes, rework them to match arbitrary upstream rearrangement, and re-apply them as a single changeset creating a discontinuity in your revision history. This in turn creates problems with annotate, log, backing out changes prior to the merge, etc. All the reasons we like to use revision control for significant work. What you describe may work OK(ish) if you have to do it once every 3-6 years as a single massive merge and you were planning to do it by hand anyway (CVS and patches). However, other downstream users (including our own development branches in Subversion, P4, etc) reasonably expect to be able to use contemporary tools to manage the merge on a more frequent basis. As I said before: this isn't a vote not to rearrange things once in a while, it's instead a caution to say: this has a significant cost beyond svn mv that has to be taken into account when making the decision, so we should only do it with significant forethought and where there is significant benefit. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100307052949.gb70...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: : FWIW, NetBSD's charter has been to run their OS on a number of : architectures, not just a primary set of architectures; OpenBSD's : charter differs -- if we all were NetBSD or OpenBSD, then we'd all be : using the same thing. But we aren't and that's probably not going to : change anytime soon [at least not without community backing and a : : We aren't? At this point it seems any architecture an be brought into : FreeBSD without regard to critical mass or ability to support it to the : standards of our past. I do believe FreeBSD's character does not include : chasing every embedded platform where there is energy and talent for the : initial port. FreeBSD's charter includes whatever people have the time and energy to support. This means a lot more embedded platforms that I ever thought possible because FreeBSD is getting easier to move to new embedded platforms. This is a good thing, as it brings more people and energy to the project and makes the base support for those platforms better. We don't have quite as many problems as the NetBSD/OpenBSD crowd in this respect. They tend to define a new MACHIINE more often then we have (or will). The need for sys/arch is less severe here than there because we don't have 40 different MACHINEs. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100307054423.ge70...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: : On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: : In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert : Watso n writes: : Doing that kind of rearrangement [...] would be a nightmare for anyone : with large [...] patches, so I'd say we could pretty much rule that out : outright. : : I would say that we should do it occasionally, to encourage these FreeBSD : users to contribute as many of their local changes back to the project, as : possible :-) : : Absolutely -- and rearranging a tree is a good way to invalidate all those : patches as well :-). : : No, not it isn't. Provide a script to convert path's in the diff. : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. You are joking, right? This would be a nightmare for people that integrate early and often. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
In message: 20100307054423.ge70...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org,
Robert
: Watso n writes:
: Doing that kind of rearrangement [...] would be a nightmare for anyone
: with large [...] patches, so I'd say we could pretty much rule that out
: outright.
:
: I would say that we should do it occasionally, to encourage these
: FreeBSD users to contribute as many of their local changes back to
: the project, as possible :-)
:
: Absolutely -- and rearranging a tree is a good way to invalidate
: all those patches as well :-).
:
: No, not it isn't. Provide a script to convert path's in the diff.
: This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
You are joking, right? This would be a nightmare for people that
integrate early and often.
No I am not joking. I was responding to the point that a large patch
(that is a the output of running '$SCM diff') can be easily modified to
match a new directory layout. Thus patches in GNATS aren't useless.
I'm not sure what operation you are specifically speaking to . But, if
FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
do:
cd sys
mkdir arch
svn add arch
svn mv {list of dirs} arch
svn ci
and be done with it. Branches would merge that change - get a trivial
tree conflict, resolve it - and move on with life.
I would expect folks working in project branches to do the same.
For merging changes from FreeBSD HEAD to FreeBSD stable - that is
trivial:
cd sys
svn merge -c $GRN ^/head/sys/arch/amd64 amd64
svn ci
Subversion makes this a lot easier than CVS did.
--
-- David (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 08:51:22PM +, Robert Watson wrote: On Sat, 6 Mar 2010, David O'Brien wrote: No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. Indeed, this is precisely the problem: rearranging the tree upstream means that you most likely can't use the revision control system to manage your local difference set downstream. It does not mean downstream users cannot their revision control system manage changes - it only means those using CVS cannot easily. Lets say I'm a 3rd party based on FreeBSD. One vendor imports the FreeBSD sources for what ever version they are based on. When new FreeBSD version comes out with 'sys/arch/' that would be reflected in the SCM on that vendor branch. The SCM would track that directories moved. Now when the new FreeBSD import was merged into the working sources branch, the SCM would track that the directory moves would need to happen there also. Done deal. Instead, you have to manually extract your local changes, rework them to match arbitrary upstream rearrangement, and re-apply them as a single changeset creating a discontinuity in your revision history. No, you could use the SCM to do it. All modern SCM's that I'm familiar with track directory moves. Resulting in a situation where there is not lossage with log, blame, etc.. I am speaking as one of the downstream users of FreeBSD - $WORK could consume such a move - so please don't hold them up as a reason to not consider moving the CPU directories under arch/. I know of two 3rd parties with product based on FreeBSD - one uses subversion, and the other uses Perforce. Granted I don't know what the others use - but we could query them. However, other downstream users (including our own development branches in Subversion, P4, etc) reasonably expect to be able to use contemporary tools to manage the merge on a more frequent basis. Yes - have you had a bad experience with merging such changes from HEAD to a project branch in our own subversion tree? My experience is, given a HEADS UP to a directory move, it is not hard to handle merges in subversion. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100308000203.ga70...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: In message: 20100307054423.ge70...@dragon.nuxi.org
: David O'Brien obr...@freebsd.org writes:
: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: : On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: : In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org,
Robert
: : Watso n writes:
: : Doing that kind of rearrangement [...] would be a nightmare for
anyone
: : with large [...] patches, so I'd say we could pretty much rule that
out
: : outright.
: :
: : I would say that we should do it occasionally, to encourage these
: : FreeBSD users to contribute as many of their local changes back to
: : the project, as possible :-)
: :
: : Absolutely -- and rearranging a tree is a good way to invalidate
: : all those patches as well :-).
: :
: : No, not it isn't. Provide a script to convert path's in the diff.
: : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
:
: You are joking, right? This would be a nightmare for people that
: integrate early and often.
:
:
: No I am not joking. I was responding to the point that a large patch
: (that is a the output of running '$SCM diff') can be easily modified to
: match a new directory layout. Thus patches in GNATS aren't useless.
It seems like it would be a nightmare for anybody tracking the system
on a regular basis.
: I'm not sure what operation you are specifically speaking to . But, if
: FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
: do:
:
: cd sys
: mkdir arch
: svn add arch
: svn mv {list of dirs} arch
: svn ci
:
: and be done with it. Branches would merge that change - get a trivial
: tree conflict, resolve it - and move on with life.
And everybody who was tracking FreeBSD with their own changes would
have to scramble. It wouldn't be trivial by any stretch of the
imagination. The project is much larger than svn, and svn doesn't
lend itself well to having external agents track it.
: I would expect folks working in project branches to do the same.
:
: For merging changes from FreeBSD HEAD to FreeBSD stable - that is
: trivial:
:
: cd sys
: svn merge -c $GRN ^/head/sys/arch/amd64 amd64
: svn ci
:
: Subversion makes this a lot easier than CVS did.
Just because the task is doable with svn, where it was impossible with
CVS doesn't mean there wouldn't be a significant amount of pain to the
folks using FreeBSD. It is cool that Juniper kinda has it worked out,
but even there I'm skeptical about your claims. Especially since
Juniper imports source rarely, where as other firms do it more often,
and there'd be more pain for them.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Sun, Mar 7, 2010 at 4:49 PM, M. Warner Losh i...@bsdimp.com wrote:
In message: 20100308000203.ga70...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: In message: 20100307054423.ge70...@dragon.nuxi.org
: David O'Brien obr...@freebsd.org writes:
: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: : On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: : In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org,
Robert
: : Watso n writes:
: : Doing that kind of rearrangement [...] would be a nightmare for
anyone
: : with large [...] patches, so I'd say we could pretty much rule that
out
: : outright.
: :
: : I would say that we should do it occasionally, to encourage these
: : FreeBSD users to contribute as many of their local changes back to
: : the project, as possible :-)
: :
: : Absolutely -- and rearranging a tree is a good way to invalidate
: : all those patches as well :-).
: :
: : No, not it isn't. Provide a script to convert path's in the diff.
: : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
:
: You are joking, right? This would be a nightmare for people that
: integrate early and often.
:
:
: No I am not joking. I was responding to the point that a large patch
: (that is a the output of running '$SCM diff') can be easily modified to
: match a new directory layout. Thus patches in GNATS aren't useless.
It seems like it would be a nightmare for anybody tracking the system
on a regular basis.
: I'm not sure what operation you are specifically speaking to . But, if
: FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
: do:
:
: cd sys
: mkdir arch
: svn add arch
: svn mv {list of dirs} arch
: svn ci
:
: and be done with it. Branches would merge that change - get a trivial
: tree conflict, resolve it - and move on with life.
And everybody who was tracking FreeBSD with their own changes would
have to scramble. It wouldn't be trivial by any stretch of the
imagination. The project is much larger than svn, and svn doesn't
lend itself well to having external agents track it.
: I would expect folks working in project branches to do the same.
:
: For merging changes from FreeBSD HEAD to FreeBSD stable - that is
: trivial:
:
: cd sys
: svn merge -c $GRN ^/head/sys/arch/amd64 amd64
: svn ci
:
: Subversion makes this a lot easier than CVS did.
Just because the task is doable with svn, where it was impossible with
CVS doesn't mean there wouldn't be a significant amount of pain to the
folks using FreeBSD. It is cool that Juniper kinda has it worked out,
but even there I'm skeptical about your claims. Especially since
Juniper imports source rarely, where as other firms do it more often,
and there'd be more pain for them.
There are also folks (like Ironport) who don't import changes back
into the tree as often, and I'd rather not put more of a crimp on
folks' time for getting things back in because of this forced CVS -
SVN upgrade (I'd rather convince others gradually over time to switch
to svn as opposed to using CVS).
As long as CVS continues to be in base, some folks will prefer it
over SVN (not saying because it's better, but just because it's there
and it's established).
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Thu, Mar 4, 2010 at 11:13 AM, Mark Linimon lini...@lonesome.com wrote: There are two chief problems with a large-scale reorg of our src tree: - There are many companies who use FreeBSD as part of their business. In the case of ISPs or companies who use FreeBSD as a base of their products, this would make it much harder for them to synchronize their local changes with the master repository as changes occur. - We have a large number of existing Problem Reports containing patches against our src tree. These patches would be in the same situation. These are the reasons we've avoided doing so in the past, no matter how much 'cleaner' things might wind up being. I'm going to come off ignorant as well because I don't have the necessary history in the past attempts to reorganize this -- but would it make sense to gradually work in the changes over an extended period of time and encourage better directory structure in the short-term for new code or would it be too much of a blooming mess to consider. Probably the latter due to the inherent inconsistency with the rework, but I figured I should ask. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Thu, Mar 4, 2010 at 11:33 AM, paradox ddkp...@yahoo.com wrote: so, I really do not understand why it is so difficult to move a few folders in the shared folder is a big problem as is done in openbsd and netbsd http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/?only_with_tag=MAIN http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ as you can see Well, maybe my thoughts will be understood, then when the folder /usr/src/sys/ number of architectures to increase to ~ 50, then keep them all in one folder /usr/src/sys/ this is just a file cesspool without logical structure I haven't looked at NetBSD or OpenBSD's directory layouts, but Linux is #ifdef hell to work through just to figure out what the frak is going on in the kernel. That seems to be an excellent example of what _not_ to do when organizing architecture specific files, and from what I saw it also allowed for a greater set of feature disparity between architectures because not all camps had to implement feature X.Y.Z as they had their own underlying code to do the common code; granted, that's probably the way it's setup in any architecture-specific sourcebase, but it's a lot more difficult to understand and maintain (or at least it was for me trying to figure out what was going on). FWIW, NetBSD's charter has been to run their OS on a number of architectures, not just a primary set of architectures; OpenBSD's charter differs -- if we all were NetBSD or OpenBSD, then we'd all be using the same thing. But we aren't and that's probably not going to change anytime soon [at least not without community backing and a considerable amount of engineering effort on someone or some group's behalf]. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
Alex Keda writes: Let's wait another 10 years, and, coming at last to understand that this must be done, and do it was 20 times harder. First, all architectures are not equal in FreeBSD's eyes. Look for Tier 1 architectures in the docs and mailing lists. Second, if you want this badly enough ... then convince us. Build a system; do the work; _document it_ (what you did, how long it took, how many files were involved, etc.); and show us why your way is worth it. There are others who want this; maybe you can get them to help. If it really is worth the effort, I have faith it'll get done. Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 11:16:41AM +, Doug Rabson wrote: I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. To be fair - two years ago we were not using a source control system that understood moves within the repository. To do this two years ago, we had to make a choice between three poor paths of how to do CVS moves - repo copy (breaks date-based checkout), delete-add pairs (looses history), or copy the entire repository move files and use new repo for new releases and existing repo for old releases. Juniper now also uses Subversion - so with sufficient warning and planning, Juniper could consume a move of the CPU directories moving under arch/. Juniper also had a CVS based tree reorg 1.5 years go - taking the third path above. Please don't use Juniper as an reason to not move forward with this change. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: FWIW, NetBSD's charter has been to run their OS on a number of architectures, not just a primary set of architectures; OpenBSD's charter differs -- if we all were NetBSD or OpenBSD, then we'd all be using the same thing. But we aren't and that's probably not going to change anytime soon [at least not without community backing and a We aren't? At this point it seems any architecture an be brought into FreeBSD without regard to critical mass or ability to support it to the standards of our past. I do believe FreeBSD's character does not include chasing every embedded platform where there is energy and talent for the initial port. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 12:01:30PM +0100, Svein Skogen (Listmail Account) wrote: Oh, so because a lot of the programmers behind it receive wages, and the project itself won't commit ritual suicide by basically blocking the companies using FreeBSD from returning improvements they make to the project itself, it should be renamed. Svein, A source layout change is the lest of the problems pushing code back from companies using FreeBSD. When $WORK rearranged our FreeBSD-based tree, we simply provided a perl script to run over patch files that fixed up the patch. sed -e 's,sys/amd64,sys/arch/amd64,g' patchfile newpatchfile isn't that hard to do... The fact that we totally rototilled the bge and em drivers FreeBSD 6.1-6.2 is a MUCH bigger problem to the commercial users of FreeBSD and their patch sets. [medium seriousness bug fixes were done by a full MFC of the driver, vs. just spot fixing the needed changes] -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play Jeopardy-style quoting ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert Watso n writes: Doing that kind of rearrangement [...] would be a nightmare for anyone with large [...] patches, so I'd say we could pretty much rule that out outright. I would say that we should do it occasionally, to encourage these FreeBSD users to contribute as many of their local changes back to the project, as possible :-) Absolutely -- and rearranging a tree is a good way to invalidate all those patches as well :-). No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Thu, 4 Mar 2010, Xin LI wrote: One good thing (in my opinion) that NetBSD and Darwin have is that they have a common tree which holds the common files that shared between kernel and userland libc. Currently we have 2 or more copies of certain files in the tree but I'm not sure if it's a good idea to migrate them together into a src/common tree, or just modify the Makefile to reference the one copy? Eliminating duplicated files makes it easier for changes to propagate into different areas (like, we have optimization apply against all components, or have bug fixed in one time). Is this really widely a problem, or just a problem in a few specific cases? libc and other code depends on countless kernel files to get API definitions, system call lists, etc, without duplicating kernel code. Similarly, userland libraries sharing significant kernel code, such as libsbuf, will directly reference the kernel file, and in ipfilter, code is shared between the kernel and userspace directly as part of the test suite. The only real exceptions to this rule are libkern, which contains a very constrained part of libc, and the audit code, where the code structure is very similar but there are lots of small differences due to differing semantics for memory allocation in the kernel (M_WAITOK can't fail), so we maintain that copy/merge with the help of Perforce. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Thu, 4 Mar 2010, paradox wrote: so, I really do not understand why it is so difficult to move a few folders in the shared folder is a big problem as is done in openbsd and netbsd http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/?only_with_tag=MAIN http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ as you can see I would hesitate to say that there are no large forks of OpenBSD/NetBSD in products, but it may well be that the maintainers of those forks are less involved in their communities. We have downstream consumers like Isilon, NetApp, Juniper, and many others who have significant kernel features maintained against our tree. It's not just them either: we are our own downstream consumers. Every major branched project in Subversion, Perforce, or external git repositories, will have significant local changes. Every time we go wild rearranging the tree, they have to pick up the mess trying to figure out how to forward-merge changes -- and as someone who has been on the wrong end of that (the TrustedBSD work took 5+ years to go from inception to merge), I can say it's a really painful experience. It's not impossible, it's just a huge amount of work. This isn't to say we shouldn't do occasional rearrangements, but the argument has to be made pretty carefully that the gratuitous rename of the day offers a significant benefit, worth potentially dislodging all the downstream trees and requiring them to remerge all their work. It can't just be oh, if only we had five fewer directories at the top of the sys tree, because that's *not* worth it. Doing that kind of rearrangement on the network stack would be a nightmare for anyone with large network stack patches, so I'd say we could pretty much rule that out outright. I'm not sure how things compare in the machine-dependent code trees, but I'd guess there are people with non-trivial changes there as well. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert Watso n writes: Doing that kind of rearrangement [...] would be a nightmare for anyone with large [...] patches, so I'd say we could pretty much rule that out outright. I would say that we should do it occasionally, to encourage these FreeBSD users to contribute as many of their local changes back to the project, as possible :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert Watso n writes: Doing that kind of rearrangement [...] would be a nightmare for anyone with large [...] patches, so I'd say we could pretty much rule that out outright. I would say that we should do it occasionally, to encourage these FreeBSD users to contribute as many of their local changes back to the project, as possible :-) Absolutely -- and rearranging a tree is a good way to invalidate all those patches as well :-). It's a trade-off, obviously, but what it does mean is that we shouldn't rearrange the tree without thinking about both sides: it's not just the aesthetics of a particular layout over another, it's that changes in layout come with a less visible but much larger cost than svn mv. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message alpine.bsf.2.00.1003050940290.5...@fledge.watson.org, Robert Watso n writes: [...] it's that changes in layout come with a less visible but much larger cost than svn mv. Really stupid question: Doesn't svn support symlinks ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 5 Mar 2010, at 09:30, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message cf439450-14f1-4628-a012-cf6dd2a50...@rabson.org, Doug Rabson write s: Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. Right, but as Sun has so definitively shown, you don't do your customers any service either, by being mortally afraid of breaking backwards compatibility. It's a balance to be struck, and it was certainly a mistake that we didn't deal with it when the alpha arrived. Or PC98. Or spar64. Or ... Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 12:45, Doug Rabson wrote: On 5 Mar 2010, at 09:30, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 5 Mar 2010, at 09:56, Alex Keda wrote: On 05.03.2010 12:45, Doug Rabson wrote: On 5 Mar 2010, at 09:30, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. Someone always pays. If this project didn't have sponsors like Isilon, NetApp, Juniper, Yahoo, and many others it simply would not exist. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 5 Mar 2010, at 09:56, Alex Keda wrote: thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It isn't managed by them whatsoever. FreeBSD is a cooperative anarchy, driven by working code and rough consensus. That's what controls the checkins. However, FreeBSD also exists as part of a larger community. If there's no compelling reason to make the work of some of those in that community more difficult, why should we do so? Let's take a look at the current data in GNATS: $ showwithtag patch | wc -l 1880 To reiterate, that's nearly two thousand PRs with patches. (I don't have statistics for how many of those relate to arch-specific areas of the codebase, however.) Finally, IMVHO, if you want an operating system where philosophical purity overrides all practical concerns, you're going to be better off with something such as OpenBSD or Debian. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 12:59, Doug Rabson wrote: On 5 Mar 2010, at 09:56, Alex Keda wrote: On 05.03.2010 12:45, Doug Rabson wrote: On 5 Mar 2010, at 09:30, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. Someone always pays. If this project didn't have sponsors like Isilon, NetApp, Juniper, Yahoo, and many others it simply would not exist. then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? == I love FreeBSD, but then having to follow the guidance of someone even though everyone understands what you can do better - depressing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message 4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 13:48:17 +0300, Alex Keda ad...@lissyara.su wrote: On 05.03.2010 12:59, Doug Rabson wrote: On 5 Mar 2010, at 09:56, Alex Keda wrote: On 05.03.2010 12:45, Doug Rabson wrote: On 5 Mar 2010, at 09:30, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. Someone always pays. If this project didn't have sponsors like Isilon, NetApp, Juniper, Yahoo, and many others it simply would not exist. then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? No. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 14:10:43 +0300, Alex Keda ad...@lissyara.su wrote: On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 14:16, Doug Rabson wrote: On Fri, 05 Mar 2010 14:10:43 +0300, Alex Kedaad...@lissyara.su wrote: On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. And the fact that this issue was raised with enviable regularity - not make you think that it really needs to be done? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message e3e25b34d9476c02d80919fe5d09a...@mail.rabson.org, Doug Rabson writ es: I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. s/ten/fifteen/ :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 14:27:06 +0300, Alex Keda ad...@lissyara.su wrote: On 05.03.2010 14:16, Doug Rabson wrote: On Fri, 05 Mar 2010 14:10:43 +0300, Alex Kedaad...@lissyara.su wrote: On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. And the fact that this issue was raised with enviable regularity - not make you think that it really needs to be done? Read what I wrote. Consequences outweigh benefits so no. On the other hand, if you are just trolling, please try somewhere else. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 05.03.2010 14:16, Doug Rabson wrote: On Fri, 05 Mar 2010 14:10:43 +0300, Alex Kedaad...@lissyara.su wrote: On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. how many architectures supported 10 years ago? Two? It currently supports 11 or 12 - do not even know for sure. So make the transfer was 5 times harder. Let's wait another 10 years, and, coming at last to understand that this must be done, and do it was 20 times harder. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
paradox ddkp...@yahoo.com writes: so, I really do not understand why it is so difficult [...] Easy for you to say, since you're not the one who would have to do the work and spend the next two years cleaning up the resulting mess. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
Poul-Henning Kamp p...@phk.freebsd.dk writes: Really stupid question: Doesn't svn support symlinks ? It does, but the moment we move in that direction, someone will start complaining that they can't check out the source on Windows (which is the reason why we no longer have any files in the tree with colons in their name, or files with the same name but different case in the same directory) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 05 Mar 2010 12:01:30 +0100 Svein Skogen (Listmail Account) svein-listm...@stillbilde.net wrote: On 05.03.2010 11:48, Alex Keda wrote: On 05.03.2010 12:59, Doug Rabson wrote: On 5 Mar 2010, at 09:56, Alex Keda wrote: It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. Someone always pays. If this project didn't have sponsors like Isilon, NetApp, Juniper, Yahoo, and many others it simply would not exist. then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? == I love FreeBSD, but then having to follow the guidance of someone even though everyone understands what you can do better - depressing. Oh, so because a lot of the programmers behind it receive wages, and the project itself won't commit ritual suicide by basically blocking the companies using FreeBSD from returning improvements they make to the project itself, it should be renamed. There's maybe a little bit of misunderstanding here... 1. FreeBSD is free - you are allowed to do more with it than with e.g. GPLed software - we (the FreeBSD developers) are free to do with it what we want 2. if there is more than one person involved, it is better to have some rules everyone has to follow - to not stomp on each others toes - to have progress instead of catching up with changes of others (you want new features and bugfixes, don't you?) 3. companies are not involved in how FreeBSD is managed or what is allowed to reside in the FreeBSD source tree, but we listen what they tell us about their needs and constraints to be able to make decissions which are beneficial for FreeBSD (as we want that they give back some work to improve FreeBSD) Some examples: C does not require any style guidelines, but in FreeBSD we enforce a programming style. This is not to make it look nice, this is to make it more easy for all of us. The API in a stable branch does not need to be stable to get out a working OS, but it is better for the users (and we developers are users too) of FreeBSD to have the ABI stable. In the same way we are free to move around files in the development tree as we want, but we restrict ourself to not do it if not abolutely necessary, as we have the experience that this causes a slow-down for a lot of people (I am not even talking about companies which use FreeBSD in their products, I talk just about the pure development in the FreeBSD-project itself), and as such for FreeBSD itself. For those (and some more but similar reasons), there will be not such a change soon. Currently there is a somewhat related change going on, the i386, amd64 and pc98 bits which are the same, get merged into a common tree (a lot of code is shared, but the build infrastructure was not up to the task of sharing the files until recently). This is done because the benefit of moving those specific files outweights the burden of catching up with this change. For all other architectures there is currently no real benefit in moving the files, it would only cause a lot of time spend in merging the changes into another directory and making sure everything still works. While other people in this thread point to various companies which support FreeBSD (either with contributions, or as sponsors for various related events), I want to point to those developers, which do *not* get paid to work on FreeBSD. Those people do it just for fun in the time of the day/week/month they reserve for FreeBSD. Those with a tight schedule (e.g. because of family/kids) care IMO more about how this time is spend, than technicians which get paid to spend time with FreeBSD. Personally I am not interested in spending a lot of time to move around changes and test them, just because someone thinks it looks nicer this way. I agree that it would be nicer, no doubts, and if I would be a person working alone on one specific architecture, I would suggest to create an arch directory and move my architecture there. But as soon as there are more people working on one architecture, there needs to be at least an absolute majority (if not more) of those people agreeing to it. So far I count about 2 architectures which are maintained by only one person (at least as far as I noticed), but I can understand if those people do not want to spend their time doing a time consuming move (the build infrastructure needs to be adapted to handle both cases then; and even if everything is moved, this is not a quick searchreplace). Bye, Alexander. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, Mar 05, 2010 at 02:27:06PM +0300, Alex Keda wrote: On 05.03.2010 14:16, Doug Rabson wrote: On Fri, 05 Mar 2010 14:10:43 +0300, Alex Kedaad...@lissyara.su wrote: On 05.03.2010 13:59, Poul-Henning Kamp wrote: In message4b90e171.2040...@lissyara.su, Alex Keda writes: then can a more correct name of the project or ClosedBSD or ManagedBSD? =) or something abstract? You are free to use any other operating system of your choice, if you are not happy with FreeBSD. Don't let the door hit you on the way out. I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. It always ends up the same way - a re-org might make the source tree marginally prettier but the consequences for long-term maintenance and supporting downstream contributors outweigh any possible benefit. Having the same conversation every two years with the same outcome gets annoying. And the fact that this issue was raised with enviable regularity - not make you think that it really needs to be done? And the fact that weighting the arguments always ends in the same result - not make you think that this really shouldn't be done? A calculation always ends in the same result until the variables changes. So far this hasn't happen, so there is no need to recalculate/rethink every now and then. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 5 Mar 2010, Alex Keda wrote: On 05.03.2010 12:17, Robert Watson wrote: consumers like Isilon, NetApp, Juniper, and many others thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? These and other companies contribute significantly to the FreeBSD Project -- witness, for example, NFS locking support, new NFS RPC code, and the MPSAFE VFS, both contributed by Isilon in the last ten years. Not gratuitously renaming files and directories is not a high price to pay for those contributions :-). And, remember that a moderate number of our developers work for companies that use FreeBSD in products, so we're not just helping disconnected end-users: they are members of the community. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: In message alpine.bsf.2.00.1003050940290.5...@fledge.watson.org, Robert Watso n writes: [...] it's that changes in layout come with a less visible but much larger cost than svn mv. Really stupid question: Doesn't svn support symlinks ? Yes, but does that help? The issue is not user applications that can't find their header files, it's people who maintain patchsets in revision control systems, such as svn, Perforce, git, etc, whose work will be derailed when automatic merging fails. As I said, I've run into this with the TrustedBSD work several times: someone rearranges files in the network stack or VFS and you're left trying to figure out where the code moved, how to re-apply your changes, whether you've missed anything, etc. Continuity over time in code location makes that task orders of magnitude easier, and costs the project little. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Fri, 5 Mar 2010, Alex Keda wrote: thus, it is not 'Free', this managed by 'consumers like Isilon, NetApp, Juniper, and many others'? It might be helpful to think of them as 'customers' who are using our 'product' and paying for it by feeding back patches and employing FreeBSD developers. Normal business practice doesn't include intentionally making your customers' lives difficult - if you make a habit of it they tend to go elsewhere. It seems to me, business and freedom - are mutually exclusive things. or you can choose the path of development, or who pays - giver commands to community. no freedom there. Cute but no cigar. FreeBSD must ultimately be responsible to the communities it serves. Sometimes those interests are in conflict and we have to come to some technical or social compromise, but often as not they align. In this case, I think they align pretty well. Whether you're an academic building research changes into a network stack, a company building a firewall appliance, or a volunteer developer working on something that particularly motivates you in the network stack, you all lose if the source tree is rearranged out from under your feet. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 03/05/10 11:10, Alex Keda wrote: I'm not going anywhere, not even hope for it =) I'm trying to make FreeBSD a better, more logical. Maybe that's not very successful, but judging by the number of responses, it hurt many, and made to think even more people. One of the things which attracted me to FreeBSD in the first place was the relatively democratic development model and philosophy behind it. You may find this document helpful, How to Pay for Free Software, as it explains many points behind how free software funding works: http://users.puzzling.org/users/mary/HOWTO/Free/ FYI: I have not been directly funded by any of the entities called out in this thread. I often act as an unpaid volunteer on FreeBSD, or as an independent consultant. Much of my work has been funded by individuals directly, in some cases. I am therefore able to provide an unbiased opinion. I actually don't have a problem with not creating unnecessary code churn, regardless of third parties who may be using shared code. It seems to me quite reasonable not to make more work for oneself, or others, unnecessarily. I therefore disagree with the points you raise in your messages here, and actually find them unhelpful. I am saddened that you continue to make these irrational protestations despite my polite private message to you off-list. Could you please take your objections elsewhere? You are wasting people's time. regards, BMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
Poul-Henning Kamp wrote: In message e3e25b34d9476c02d80919fe5d09a...@mail.rabson.org, Doug Rabson writ es: I think you misunderstand. Some of us old-timers have been having this discussion repeatedly for well over ten years. s/ten/fifteen/ :-) s/fifteen/twenty five/ if you include BSD 4.2 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
propose: all arch move into a separate dir
iam propose all the architecture move in a separate directory
as is done in openbsd and netbsd
ie
#mkdir /usr/src/sys/arch
#mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
Would it ever done in freebsd?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On 2010-03-04 14:51, paradox wrote:
#mkdir /usr/src/sys/arch
#mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
Would it ever done in freebsd?
Sure, right after the switch to git.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
Date: Thu, 04 Mar 2010 15:48:19 +0100
From: Dimitry Andric dimi...@andric.com
Sender: owner-freebsd-curr...@freebsd.org
On 2010-03-04 14:51, paradox wrote:
#mkdir /usr/src/sys/arch
#mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
Would it ever done in freebsd?
Sure, right after the switch to git.
I would suggest a smiley after a comment like this. Someone might
actually think you were serious! Well, I suppose it is true that this
won't happen until after FreeBSD does switch to git. :-)
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 401095.35021...@web59107.mail.re1.yahoo.com
paradox ddkp...@yahoo.com writes:
: iam propose all the architecture move in a separate directory
: as is done in openbsd and netbsd
:
: ie
: #mkdir /usr/src/sys/arch
: #mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
:
: Would it ever done in freebsd?
No. That ship sailed in 1995.
Besides, it would be the mother of all bikesheds. Do we want to have
a sys/cpu/{mips,x86,arm,etc} for CPU support and a sys/arch/$MACHINE
for support for machines that use that, how does that interact with
source doe that assumes certain things in machine/foo.h. Or do we
want to have better organized sub-ports. Do we want to reorg config
while we're at it, and what about modules. And sys/dev is too
crowded, let's fix that too while we're at it.
The end result: gridlock and nothing will happen.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
On Thu, Mar 4, 2010 at 9:20 AM, M. Warner Losh i...@bsdimp.com wrote:
In message: 401095.35021...@web59107.mail.re1.yahoo.com
paradox ddkp...@yahoo.com writes:
: iam propose all the architecture move in a separate directory
: as is done in openbsd and netbsd
:
: ie
: #mkdir /usr/src/sys/arch
: #mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
:
: Would it ever done in freebsd?
No. That ship sailed in 1995.
Besides, it would be the mother of all bikesheds. Do we want to have
a sys/cpu/{mips,x86,arm,etc} for CPU support and a sys/arch/$MACHINE
for support for machines that use that, how does that interact with
source doe that assumes certain things in machine/foo.h. Or do we
want to have better organized sub-ports. Do we want to reorg config
while we're at it, and what about modules. And sys/dev is too
crowded, let's fix that too while we're at it.
The end result: gridlock and nothing will happen.
One good thing (in my opinion) that NetBSD and Darwin have is that
they have a common tree which holds the common files that shared
between kernel and userland libc. Currently we have 2 or more copies
of certain files in the tree but I'm not sure if it's a good idea to
migrate them together into a src/common tree, or just modify the
Makefile to reference the one copy? Eliminating duplicated files
makes it easier for changes to propagate into different areas (like,
we have optimization apply against all components, or have bug fixed
in one time).
Cheers,
--
Xin LI delp...@delphij.net http://www.delphij.net
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
There are two chief problems with a large-scale reorg of our src tree: - There are many companies who use FreeBSD as part of their business. In the case of ISPs or companies who use FreeBSD as a base of their products, this would make it much harder for them to synchronize their local changes with the master repository as changes occur. - We have a large number of existing Problem Reports containing patches against our src tree. These patches would be in the same situation. These are the reasons we've avoided doing so in the past, no matter how much 'cleaner' things might wind up being. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
so, I really do not understand why it is so difficult to move a few folders in the shared folder is a big problem as is done in openbsd and netbsd http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/?only_with_tag=MAIN http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/ as you can see Well, maybe my thoughts will be understood, then when the folder /usr/src/sys/ number of architectures to increase to ~ 50, then keep them all in one folder /usr/src/sys/ this is just a file cesspool without logical structure ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
Hi, * paradox ddkp...@yahoo.com wrote: Well, maybe my thoughts will be understood, then when the folder /usr/src/sys/ number of architectures to increase to ~ 50, [...] s/when/if/. ;-) I know this sounds lazy, but shouldn't we start discussing this problem by the time we support more than 10 architectures? Cheers, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpRYALO7z3KS.pgp Description: PGP signature
Re: propose: all arch move into a separate dir
* paradox wrote: Well, maybe my thoughts will be understood, then when the folder /usr/src/sys/ number of architectures to increase to ~ 50, [...] s/when/if/. ;-) more than ~ 5 years, it was necessary that would create /usr/src/sys/x86/ (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/x86/) dir Well, how many years that will need to understand that a good idea to create /usr/src/sys/arch/ ? I believe that the architecture that disposes in the folder /usr/src/sys/ is no place absolutely logical to located it in a common directory on the logic I know this sounds lazy, but shouldn't we start discussing this problem by the time we support more than 10 architectures? will wait for the next ~5-100... years? Cheers, -- Ed Schouten e...@80386.nl Well, I do not insist if the freebsd developers feel that it is not necessary, the question is close. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
