Re: changes to rc.diskless*
:The existing very bazaar and local policy in rc.diskless1 is Just Wrong; :and looks like no other Unix diskless configuration I've ever seen. I :plan on committing this patch to negate this. : :The use of an MFS /var should also be settable. Otherwise installing :ports(packages) is just a total PITA. While you've got rc.diskless* broken open it would be great if you could implement an override rc variable that completely overrides the script. i.e. so someone can set 'rc_diskless_script' in /etc/rc.conf (on the server) and /etc/rc will run that instead of /etc/rc.diskless1 if the machine is booted diskless. The problem we face is that the rc.diskless* scripts are simply not flexible enough to cover everyone's needs (or even most people's needs) and we need to provide a mechanism to allow the sysad to write his own without forcing him to edit a 'system standard' script (i.e. /etc/rc.diskless1 itself). In anycase, if you don't have time to add this I'd appreciate a head's up after you are done-and-committed your diskless scripts and I will have a go at it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Thu, Feb 21, 2002 at 05:00:37PM -0600, robert garrett wrote: > Could someone tell me where documentation concerning the > use of perforce and or, how to gain access to is located? > > Up until very recently I was not aware of it's existence. > This would make it very difficult for someone new to the > Project to contribute. You have read too much into the use of Perforce. It is a useful tool to some, and there is nothing wrong with people wanting to use a tool that handles merges much better than CVS does. Have you ever had a local change in /usr/src and had ''cvs up'' make a TOTAL mess of it? Or maybe done a vendor import into /usr/src/contrib and then tried to do a ''cvs co -j -j'' and seen just how totally idiotically STUPID CVS's merging can be? This is the problem space that some are using Perforce for -- because it can handle merges (integrations) more sanely. Thus there is nothing wrong with the _personal_ use of Perforce by some committers. > It seems to my line of thinking that the existence of a repository > That is undocumented, that is used for major development proccess's > Breaks our development model. My various local copies of the FreeBSD CVS repo where I do major toolchain work in is also undocumented. Since I have been using them for the better part of 5 years, I really don't a local private repository breaks our development model. What is breaking it, is for users of Perforce to expect the rest of the development community to use this tool also. Perforce is really a side issue of communication and collaboration in our development. In this case it boils down to one developer being told not to work on something because another developer has a work-in-progress also in that area. However the first developer felt that the work-in-progress was taking too long and thus should not be an impediment to his development in the same area. > Further enhancing the "Elite" attitude that is so often proscribed > To BSD* developers. No it isn't! I don't give you access to my local hard disk. Does that make me "Elite"? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
I'd love to see subversion beefed up. It looks like the most
promising of the replacements for cvs on the horizon.
One thing that it doesn't appear to have, that would be useful to the
BSD community, is the ability to cons up a tree from multiple repos
easily. If we had that, then we wouldn't need 5 different versions of
cat for {Free,Net,Open}BSD, Darwin and BSD/os. :-)
That reminds me, I gotta go fix FreeBSD's patch to grok patches
properly ...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On 21-Feb-02 Robert Watson wrote: > > On 21 Feb 2002, Dag-Erling Smorgrav wrote: > >> Matthew Dillon <[EMAIL PROTECTED]> writes: >> > I'm not interested in using P4. I think it's a mistake. That is, I >> > think it is being severely overused. [...] >> >> Frankly, although I use Perforce myself for PAM work, I agree with Matt >> here. Most of what is going on in the Perforce should be happening on >> branches in our main repo, if only CVS didn't suck so bad at branching. >> >> I would like to suggest that we consider transitioning our main repo to >> Subversion. It's reasonably similar to cvs, and has all the features we >> need that cvs lack: metadata versioning, atomic commits, cheap >> branching... > > The problem is CVS. The solution is unclear. In the mean time, people > are using Perforce because it's an effective tool to do the job. Believe > me, I'd rather *not* be using two (or two and a half) different version > control and software source management schemes, but the practical reality > is that CVS cannot provide what I need to do what I do. Once there's a > reliable free version control system that can be the One True System, I'll > be extremely pleased to use it. Until then, well... :-) Yep, if subversion ends up being a p4 + decent diffs + annotate + repository replication (p4's vcp looks uber leet) + offline mode, then I'm all for it. :) It would be much easier to not be having to use p4 for work branches since I and others could just reverse integrate our changes into HEAD from the side branches. As it is, we have to create diffs and then patch them into CVS. This is part of the reason I think that p4 doesn't have the greatest diffs btw: you don't need diffs to move code from a work branch into HEAD, you can just reverse integ and it DTRT for you. Plus, if others want to see what you are up to, they can just check out your branch rather than having to pass diffs around. Basically, I don't think p4 was designed for people passing diffs around, folks are supposed to instead be looking at each others branches. However, that's not the way FreeBSD works atm (esp. since CVS is our real SCM), so we end up using p4 in possibly one of the worst ways possible. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
changes to rc.diskless*
The existing very bazaar and local policy in rc.diskless1 is Just Wrong;
and looks like no other Unix diskless configuration I've ever seen. I
plan on committing this patch to negate this.
The use of an MFS /var should also be settable. Otherwise installing
ports(packages) is just a total PITA.
Index: rc.diskless1
===
RCS file: /home/ncvs/src/etc/rc.diskless1,v
retrieving revision 1.13
diff -u -r1.13 rc.diskless1
--- rc.diskless117 Jan 2002 00:10:28 - 1.13
+++ rc.diskless122 Feb 2002 03:52:41 -
@@ -92,13 +92,14 @@
done
echo "Interface ${bootp_ifc} IP-Address ${bootp_ipa} Broadcast ${bootp_ipbca}"
+if [ -d /conf/default/etc ]; then
+ mount_md 4096 /etc 0
+ chkerr $? "MFS mount on /etc"
+ /bin/chmod 755 /etc
-mount_md 4096 /etc 0
-chkerr $? "MFS mount on /etc"
-/bin/chmod 755 /etc
-
-/bin/cp -Rp /conf/default/etc/* /etc
-chkerr $? "cp /conf/default/etc to /etc MFS"
+ /bin/cp -Rp /conf/default/etc/* /etc
+ chkerr $? "cp /conf/default/etc to /etc MFS"
+fi
# Allow for override files to replace files in /etc. Use /conf/*/etc to find
# the override files. First choice is default files that # always override,
@@ -113,6 +114,11 @@
cp -Rp /conf/${i}/etc/* /etc
fi
done
+
+# Since we are starting with a very fresh /etc on an MFS:
+if [ -d /conf/default/etc ]; then
+ newaliases
+if
# Tell /etc/rc to run the specified script after it does its mounts but
# before it does anything else.
Index: rc.diskless2
===
RCS file: /home/ncvs/src/etc/rc.diskless2,v
retrieving revision 1.15
diff -u -r1.15 rc.diskless2
--- rc.diskless226 Dec 2001 17:18:39 - 1.15
+++ rc.diskless222 Feb 2002 03:56:18 -
@@ -56,7 +56,7 @@
fi
echo "+++ mount_md of /var"
-mount_md ${varsize:=65536} /var 1
+mount_md ${varsize:=32m} /var 1
echo "+++ populate /var using /etc/mtree/BSD.var.dist"
/usr/sbin/mtree -deU -f /etc/mtree/BSD.var.dist -p /var
@@ -83,7 +83,7 @@
# so if /var/tmp == /tmp, then you don't get a vi.recover.
#
if [ ! -h /tmp ]; then
- mount_md ${tmpsize:=20480} /tmp 2
+ mount_md ${tmpsize:=64m} /tmp 2
chmod 01777 /tmp
fi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers - are they WANTED yet?
At 9:00 PM -0500 2/21/02, Garance A Drosihn wrote: >At 1:08 PM -0500 2/19/02, Michael Lucas wrote: >>In an ideal world, you're correct. >> >>The real question here should have been: do those people who >>are actively committing rapidly to the tree want to see this >>happen? They are the people who will realistically have to >>deal with the PRs. > >I assume we'd still like 5.0 to "go -stable" in about 8-10 months, >so at which point to we start encouraging more people to jump >into it? It occurs to me that the "yet" that I added to this subject is a little misleading. Michael wasn't talking about articles which would appear this weekend... From Michael's original message: The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. My question to the community is: is it too early to do this? If I start now, the articles would probably appear April-May. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more -current testers - are they WANTED yet?
At 1:08 PM -0500 2/19/02, Michael Lucas wrote: >In an ideal world, you're correct. > >The real question here should have been: do those people who >are actively committing rapidly to the tree want to see this >happen? They are the people who will realistically have to >deal with the PRs. This is the main question of course, and I can't say that I've seen any of the really active developers comment on it. I do think it is important to get more people on -current, so I'm trying to do more with -current myself. So, for instance, I've already come across two small errors in -current which should certainly be fixed before 5.0 "goes -stable". However, looking at the bigger issues being discussed in -current right now, I expect it would be annoying if I bugged anyone about little cosmetic issues. I think if Michael writes up anything, it will certainly encourage more people to use current, including people who might very well start commenting on the little nit-picking items. Do the developers of current want that yet, or will they find it irritating to have people pointing out minor issues when they (the developers) are still trying to sort out some of the more major issues? Current is fine for me (at the moment at least, and if we ignore the topic of vmware...), and I do hope to write a few patches to fix the cosmetic things I do come across. But are the developers ready for maybe a hundred more people playing around with current, and reporting on all kinds of things? I assume we'd still like 5.0 to "go -stable" in about 8-10 months, so at which point to we start encouraging more people to jump into it? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> * Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020221 16:19] wrote:
> > Ah, of course! now why didn't I think of that? :)
> My first thought was:
> "If make(1) doesn't have that functionality I will beat it into it
>with a lead pipe..."
Heh :) Here's a patch, anyway.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: kern.post.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.post.mk,v
retrieving revision 1.7
diff -u -r1.7 kern.post.mk
--- kern.post.mk 10 Jan 2002 03:52:00 - 1.7
+++ kern.post.mk 22 Feb 2002 00:22:39 -
@@ -93,10 +93,10 @@
${SYSTEM_SFILES} ${MFILES:T:S/.m$/.h/}
if [ -f .olddep ]; then mv .olddep .depend; fi
rm -f .newdep
- env MKDEP_CPP="${CC} -E" CC="${CC}" \
- mkdep -a -f .newdep ${CFLAGS} ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES}
- env MKDEP_CPP="${CC} -E" \
- mkdep -a -f .newdep ${ASM_CFLAGS} ${SFILES} ${SYSTEM_SFILES}
+ ${MAKE} -VCFILES -VSYSTEM_CFILES -VGEN_CFILES | xargs\
+ env MKDEP_CPP="${CC} -E" CC="${CC}" mkdep -a -f .newdep ${CFLAGS}
+ ${MAKE} -VSFILES -VSYSTEM_FILES | xargs\
+ env MKDEP_CPP="${CC} -E" mkdep -a -f .newdep ${ASM_CFLAGS}
rm -f .depend
mv .newdep .depend
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
* Dag-Erling Smorgrav <[EMAIL PROTECTED]> [020221 16:19] wrote: > Luigi Rizzo <[EMAIL PROTECTED]> writes: > > i think Al's solution (make -V ... | xargs .. ) > > wins both in terms of simplicity and efficiency > > Ah, of course! now why didn't I think of that? :) My first thought was: "If make(1) doesn't have that functionality I will beat it into it with a lead pipe..." Luckly I can across the option. :) -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building php mod and cgi
* Joseph Wright ([EMAIL PROTECTED]) wrote: > Is their a way to build the port mod_php4 as the module version > for apache and the cgi for command line options. I currently have > mod_php+apache13+mysql+gd working perfect but I now have the need to > run php from the command prompt with mysql & gd. What is the best way > to go about this. Install lang/php4, it slaves off www/mod_php4 but produces a standalone executable instead. -- Thomas 'Freaky' Hurst - [EMAIL PROTECTED] - http://www.aagh.net/ - Documentation is the castor oil of programming. Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
Luigi Rizzo <[EMAIL PROTECTED]> writes: > i think Al's solution (make -V ... | xargs .. ) > wins both in terms of simplicity and efficiency Ah, of course! now why didn't I think of that? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
> Not particularly efficient... oh yes... i think Al's solution (make -V ... | xargs .. ) wins both in terms of simplicity and efficiency cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Forking" FreeBSD: CVS vs. P4
Mike Barcroft wrote: > [Discussion related to the root of the thread, rather than my message, > removed.] > > I see you are not interested in doing this. > > -CURRENT READERS TAKE NOTE: > No longer can Terry blame CVS, P4, Gnats, our two seperate branches of > development, FreeBSD developers, or the color of the sky; Terry can be > attributed to be the sole reason why these outside projects have never > been integrated into FreeBSD. Apparently, you weren't paying attention to the "too dangerous" part of the discussion, which would, by definition, keep my examples from getting committed. FWIW: I specifically chose my examples so that 3 out of the 4 of them were complex enough that they would hit the review wall. Also FWIW: Just because I came up with the examples does not mean they are my code. They are code that was current at the time the project was made aware of the patches, and the only thing missing from your 5 step process was the review and commit. Check the list archives for them, if you don't believe me. I'm amazed that I now suddenly own the integration of all forward looking projects into FreeBSD where the only steps necessary for their integration are "4) review, 5) commit". If that's the case, I hereby approve, after having reviewed it, John Baldwin's proc-locking patch. As my "mentor", I'm sure you'll commit it, now, right? If anyone else wants their code that's in P4, and not CVS, reviewed and committed to CVS, speak up, because Mike Barcroft is here to help you. PS: Grow up: you can't dismiss all my examples by waving an "it's Terry's problem" wand at them. There's a real process problem here that needs addressing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
* Luigi Rizzo <[EMAIL PROTECTED]> [020221 15:47] wrote:
> On Thu, Feb 21, 2002 at 03:41:46PM -0800, Alfred Perlstein wrote:
> > * Luigi Rizzo <[EMAIL PROTECTED]> [020221 15:14] wrote:
> > > So, in this thread a few days ago i reported that the
> > > list of arguments passed to mkdep can become quite large
> > > and exceed kern.argmax, especially if your sources are not in the
> ...
> > > Any better ideas ?
> >
> > Yes. :)
> >
> > $(MAKE) -V CFILES -V SYSTEM_CFILES -V |\
> > xargs env MKDEP_CPP="${CC} -E" CC="${CC}" mkdep -a -f .newdep ${CFLAGS}
>
> Nice one, didn't know about the -V option.
>
> Would you like to commit this or should I do it ?
Go for it.
> Also, do you know where to look for the same problem in RELENG_4 ?
Not offhand, sorry.
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: "Forking" FreeBSD: CVS vs. P4
Terry Lambert <[EMAIL PROTECTED]> writes: > Mike Barcroft wrote: > > I'm getting sick of reading this. Terry, if you want this code > > integrated into FreeBSD, here's what you do: 1) Find yourself a > > mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current > > sources, 4) Have them reviewed, 5) Commit them. > > > > If you aren't interested in doing this, you are the sole person to be > > blamed for them not being integrated into FreeBSD. > > And I'm getting sick of being dragged down into details in what > should be a meta-discussion, thus effectively glossing over the > major point in order to pick on one or two "objectionable" > paragraphs out of an entire posting. [Discussion related to the root of the thread, rather than my message, removed.] I see you are not interested in doing this. -CURRENT READERS TAKE NOTE: No longer can Terry blame CVS, P4, Gnats, our two seperate branches of development, FreeBSD developers, or the color of the sky; Terry can be attributed to be the sole reason why these outside projects have never been integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
Luigi Rizzo <[EMAIL PROTECTED]> writes:
> Any better ideas ?
You could just chicken out and do
Index: kern.post.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.post.mk,v
retrieving revision 1.7
diff -u -r1.7 kern.post.mk
--- kern.post.mk10 Jan 2002 03:52:00 - 1.7
+++ kern.post.mk21 Feb 2002 23:55:02 -
@@ -93,10 +93,15 @@
${SYSTEM_SFILES} ${MFILES:T:S/.m$/.h/}
if [ -f .olddep ]; then mv .olddep .depend; fi
rm -f .newdep
+# Do this one file at a time to avoid overly long command lines
+.for file in ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES}
env MKDEP_CPP="${CC} -E" CC="${CC}" \
- mkdep -a -f .newdep ${CFLAGS} ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES}
+ mkdep -a -f .newdep ${CFLAGS} ${file}
+.endfor
+.for file in ${SFILES} ${SYSTEM_SFILES}
env MKDEP_CPP="${CC} -E" \
- mkdep -a -f .newdep ${ASM_CFLAGS} ${SFILES} ${SYSTEM_SFILES}
+ mkdep -a -f .newdep ${ASM_CFLAGS} ${file}
+.endfor
rm -f .depend
mv .newdep .depend
Not particularly efficient, but shorter, simpler and clearer.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Dag-Erling Smorgrav wrote: > robert garrett <[EMAIL PROTECTED]> writes: > > Further enhancing the "Elite" attitude that is so often proscribed > > To BSD* developers. > > I hope you meant "ascribed" :) I think he means FreeBSD developers are not allowed to have that attitude. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
On Thu, Feb 21, 2002 at 03:41:46PM -0800, Alfred Perlstein wrote:
> * Luigi Rizzo <[EMAIL PROTECTED]> [020221 15:14] wrote:
> > So, in this thread a few days ago i reported that the
> > list of arguments passed to mkdep can become quite large
> > and exceed kern.argmax, especially if your sources are not in the
...
> > Any better ideas ?
>
> Yes. :)
>
> $(MAKE) -V CFILES -V SYSTEM_CFILES -V |\
> xargs env MKDEP_CPP="${CC} -E" CC="${CC}" mkdep -a -f .newdep ${CFLAGS}
Nice one, didn't know about the -V option.
Would you like to commit this or should I do it ?
Also, do you know where to look for the same problem in RELENG_4 ?
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
robert garrett wrote: > > Could someone tell me where documentation concerning the > use of perforce and or, how to gain access to is located? http://people.freebsd.org/~peter/p4cookbook.txt > Up until very recently I was not aware of it's existence. > This would make it very difficult for someone new to the > Project to contribute. To contribute to a seperate branch other than the main line branch, yes. You'd have to join the mailing list for the side project in question (e.g. SMP), and learn about it that way). Effectively, all it provides is a place for people to collaborate, and to gather in force in favor of a commit to the CVS repository. You could get the same effect from a small group working with a shared CVS repository, and having their code show up full blown, but this way, it at least happens under the umbrella, and therefore theoretically the oversight, of the project. It's also much easier to keep up to date, since CVSup pretty much hates local branches with merges to HEAD. > It seems to my line of thinking that the existence of a repository > That is undocumented, that is used for major development proccess's > Breaks our development model. > > Further enhancing the "Elite" attitude that is so often proscribed > To BSD* developers. Actually, the P4 repository has a lower barrier to entry than the CVS repository -- which is one of the main reasons people choose to use it. It overcomes an inherent weakness in the developement model. The real issues that need to be addressed are the underlying issues that cause people to move to P4 in the first place. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
* Luigi Rizzo <[EMAIL PROTECTED]> [020221 15:14] wrote:
> So, in this thread a few days ago i reported that the
> list of arguments passed to mkdep can become quite large
> and exceed kern.argmax, especially if your sources are not in the
> default place and you are compiling a file with lots of options
> such as LINT.
>
> The place to fix (for -current) is sys/conf/kern.post.mk, and
> as Alfred suggested, a fix involves using xargs (mkdep is already
> invoked with -a). Unfortunately it is not entirely trivial because
> the variable containing the argument list is a Make variable, and
> any attempt to expand it in a command will result in the "Argument
> list too long" error.
>
> The best I could come up with is the following (modulo cut&paste
> conversion of tabs in spaces), i.e. use make's .for to
> copy the list of files into a file that we can then pass
> to xargs.
>
> Any better ideas ?
Yes. :)
$(MAKE) -V CFILES -V SYSTEM_CFILES -V |\
xargs env MKDEP_CPP="${CC} -E" CC="${CC}" mkdep -a -f .newdep ${CFLAGS}
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
robert garrett <[EMAIL PROTECTED]> writes: > Further enhancing the "Elite" attitude that is so often proscribed > To BSD* developers. I hope you meant "ascribed" :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Proposed patch for "/bin/sh: Argument list too long" when compiling LINT ...
So, in this thread a few days ago i reported that the
list of arguments passed to mkdep can become quite large
and exceed kern.argmax, especially if your sources are not in the
default place and you are compiling a file with lots of options
such as LINT.
The place to fix (for -current) is sys/conf/kern.post.mk, and
as Alfred suggested, a fix involves using xargs (mkdep is already
invoked with -a). Unfortunately it is not entirely trivial because
the variable containing the argument list is a Make variable, and
any attempt to expand it in a command will result in the "Argument
list too long" error.
The best I could come up with is the following (modulo cut&paste
conversion of tabs in spaces), i.e. use make's .for to
copy the list of files into a file that we can then pass
to xargs.
Any better ideas ?
cheers
luigi
Index: kern.post.mk
===
RCS file: /home/ncvs/src/sys/conf/kern.post.mk,v
retrieving revision 1.4
diff -u -r1.4 kern.post.mk
--- kern.post.mk2001/11/11 06:16:53 1.4
+++ kern.post.mk2002/02/21 04:49:26
@@ -89,10 +89,28 @@
${SYSTEM_SFILES} ${MFILES:T:S/.m$/.h/}
if [ -f .olddep ]; then mv .olddep .depend; fi
rm -f .newdep
- env MKDEP_CPP="${CC} -E" CC="${CC}" \
- mkdep -a -f .newdep ${CFLAGS} ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILE
S}
- env MKDEP_CPP="${CC} -E" \
- mkdep -a -f .newdep ${ASM_CFLAGS} ${SFILES} ${SYSTEM_SFILES}
+ #
+ # The argument list can be very long, and the only way we have to
+ # split it is within make because anything else will cause
+ # an exec error if the list is too long!
+ rm -f .args
+.for I in ${CFILES} ${SYSTEM_CFILES} ${GEN_CFILES}
+ @echo -n "$I " >> .args
+.endfor
+ echo "" >> .args
+ echo "args len is " ; wc .args
+ # argument list...
+ cat .args | xargs env MKDEP_CPP="${CC} -E" CC="${CC}" \
+ mkdep -a -f .newdep ${CFLAGS}
+ rm -f .args
+.for I in ${SFILES} ${SYSTEM_SFILES}
+ @echo -n "$I " >> .args
+.endfor
+ echo "" >> .args
+ echo "args len is " ; wc .args
+ cat .args | xargs env MKDEP_CPP="${CC} -E" \
+ mkdep -a -f .newdep ${ASM_CFLAGS}
+ rm -f .args
rm -f .depend
mv .newdep .depend
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: Patch to improve mutex collision performance
Could someone tell me where documentation concerning the use of perforce and or, how to gain access to is located? Up until very recently I was not aware of it's existence. This would make it very difficult for someone new to the Project to contribute. It seems to my line of thinking that the existence of a repository That is undocumented, that is used for major development proccess's Breaks our development model. Further enhancing the "Elite" attitude that is so often proscribed To BSD* developers. Robert Garrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jochem Kossen Sent: Thursday, February 21, 2002 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Patch to improve mutex collision performance On Thu, Feb 21, 2002 at 10:36:39PM +0100, Dag-Erling Smorgrav wrote: > Miguel Mendez <[EMAIL PROTECTED]> writes: > > Well, if all developers started using p4, things would be easier and work > > better in the long term. p4 is lightyears ahead of cvs, and, from what > > I've read in this thread, developers are not exactly happy with cvs now, > > as it's limitations have become evident. > > Perforce also has limitations. It does a number of things better than > CVS, and a number of things worse. Its main problem, IMHO, is that it > tries to do too much, at the expense of basic functionality. As it seems people are forming a list of cvs alternatives, anyone ever took a look at arch? http://regexps.com/#arch A buddy of mine just mentioned it, and it seemed to fit in this discussion, i don't know it myself though. It's covered under the GPL. Jochem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Building php mod and cgi
Is their a way to build the port mod_php4 as the module version for apache and the cgi for command line options. I currently have mod_php+apache13+mysql+gd working perfect but I now have the need to run php from the command prompt with mysql & gd. What is the best way to go about this. thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Thu, Feb 21, 2002 at 10:36:39PM +0100, Dag-Erling Smorgrav wrote: > Miguel Mendez <[EMAIL PROTECTED]> writes: > > Well, if all developers started using p4, things would be easier and work > > better in the long term. p4 is lightyears ahead of cvs, and, from what > > I've read in this thread, developers are not exactly happy with cvs now, > > as it's limitations have become evident. > > Perforce also has limitations. It does a number of things better than > CVS, and a number of things worse. Its main problem, IMHO, is that it > tries to do too much, at the expense of basic functionality. As it seems people are forming a list of cvs alternatives, anyone ever took a look at arch? http://regexps.com/#arch A buddy of mine just mentioned it, and it seemed to fit in this discussion, i don't know it myself though. It's covered under the GPL. Jochem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
David O'Brien wrote: > It works in general for 'make world' and is suffient for FreeBSD > developent -- the purpose of 5-CURRENT. It is also allowing us to find > bugs that would otherwise go unfixed in Binutils 2.12.0 release. Or > would you perfer we stick to 2.11.x forever -- BTW that would not give us > support for IA-64 or x86-64. Surprisingly, this did not occur to me until the Developer's Summit report on other architectures, so it's probably not obvious to most people. For the record, then: binutils 2.12.0 is *required* by IA64, and so it's required going forward. Personally, I've been quiet since my initial Alpha breakage complaints, except to try to help track things down once in a while, since I had since realized this was an issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 21, 2002 at 11:29:46AM -0800, Terry Lambert wrote: > Actually, there was a discussion at BSDCon as to whether or > not to drop the a.out support in order to decrease the patch > size necessary to make the FSF distributed code do what FreeBSD That is true for GCC. For contrib/binutils, the code only supports FreeBSD/ELF. The old a.out as & ld are elsewhere in the tree -- and have not been updated for years. > needed it to do (personally, I would prefer that the a.out > code generation be integrated back into the FSF code base but > this is unlikely for FSF political reasons with regard to the I have tried many times... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
"Michael D. Harnois" wrote: > > I believe the intent is to ensure that the patches make it > > back into the FSF distributed code, so that in the future, > > there is less maintenance required for FreeBSD platforms. > > This is all wonderful. > > But then it seems to me that the entire new binutils should have been > backed out until it worked. Just like XFree-4.2.0 was backed out. Feel free to tilt at your windmills, all you want; I'm personally busy with other windmills; I was just pointing out what I thought was the rationale. FWIW: it *does* work on Intel, it's just Alpha that's in the dumps. The currently accepted fix is to use the older code until all the problems are out of there. -- Tery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 21, 2002 at 07:33:22AM -0600, Michael D. Harnois wrote: > On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > > > On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > > > > > > Maybe this can now be committed? > > > > NOT until I have sufficient feedback from the FSF Binutils developers. > > OK, I'm confused. binutils has been broken for three weeks. We have a > patch that we know fixes, at the very least, one of the known problems. I have also heard it caused a new problem. > However, it can't be committed without feedback from the developers. Yes, unless you can fully explain the problem and why the patch is the correct fix. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 21, 2002 at 03:39:08PM -0600, Michael D. Harnois wrote: > On Thu, 2002-02-21 at 13:29, Terry Lambert wrote: > > "Michael D. Harnois" wrote: > > > On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > > > > On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > > > > > > > > > > Maybe this can now be committed? > > > > > > > > NOT until I have sufficient feedback from the FSF Binutils developers. > > > > > > OK, I'm confused. binutils has been broken for three weeks. We have a > > > patch that we know fixes, at the very least, one of the known problems. > > > However, it can't be committed without feedback from the developers. > > > > > > So having binutils broken indefinitely is better than applying a patch > > > that *might* have to be backed out or altered later? > > > > I believe the intent is to ensure that the patches make it > > back into the FSF distributed code, so that in the future, > > there is less maintenance required for FreeBSD platforms. > > This is all wonderful. > > But then it seems to me that the entire new binutils should have been > backed out until it worked. Just like XFree-4.2.0 was backed out. It works in general for 'make world' and is suffient for FreeBSD developent -- the purpose of 5-CURRENT. It is also allowing us to find bugs that would otherwise go unfixed in Binutils 2.12.0 release. Or would you perfer we stick to 2.11.x forever -- BTW that would not give us support for IA-64 or x86-64. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, 2002-02-21 at 13:29, Terry Lambert wrote: > "Michael D. Harnois" wrote: > > On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > > > On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > > > > > > > > Maybe this can now be committed? > > > > > > NOT until I have sufficient feedback from the FSF Binutils developers. > > > > OK, I'm confused. binutils has been broken for three weeks. We have a > > patch that we know fixes, at the very least, one of the known problems. > > However, it can't be committed without feedback from the developers. > > > > So having binutils broken indefinitely is better than applying a patch > > that *might* have to be backed out or altered later? > > I believe the intent is to ensure that the patches make it > back into the FSF distributed code, so that in the future, > there is less maintenance required for FreeBSD platforms. This is all wonderful. But then it seems to me that the entire new binutils should have been backed out until it worked. Just like XFree-4.2.0 was backed out. -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota EDUCATION, n. That which discloses to the wise and disguises from the foolish their lack of understanding. -- Ambrose Bierce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Miguel Mendez <[EMAIL PROTECTED]> writes: > Well, if all developers started using p4, things would be easier and work > better in the long term. p4 is lightyears ahead of cvs, and, from what > I've read in this thread, developers are not exactly happy with cvs now, > as it's limitations have become evident. Perforce also has limitations. It does a number of things better than CVS, and a number of things worse. Its main problem, IMHO, is that it tries to do too much, at the expense of basic functionality. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On 21 Feb 2002, Dag-Erling Smorgrav wrote: > Matthew Dillon <[EMAIL PROTECTED]> writes: > > I'm not interested in using P4. I think it's a mistake. That is, I > > think it is being severely overused. [...] > > Frankly, although I use Perforce myself for PAM work, I agree with Matt > here. Most of what is going on in the Perforce should be happening on > branches in our main repo, if only CVS didn't suck so bad at branching. > > I would like to suggest that we consider transitioning our main repo to > Subversion. It's reasonably similar to cvs, and has all the features we > need that cvs lack: metadata versioning, atomic commits, cheap > branching... The problem is CVS. The solution is unclear. In the mean time, people are using Perforce because it's an effective tool to do the job. Believe me, I'd rather *not* be using two (or two and a half) different version control and software source management schemes, but the practical reality is that CVS cannot provide what I need to do what I do. Once there's a reliable free version control system that can be the One True System, I'll be extremely pleased to use it. Until then, well... :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Thu, Feb 21, 2002 at 01:49:09AM -0800, David O'Brien wrote: I'm not a commiter, but here comes my very humble opinion... > Users of Perforce are starting to force the rest of us to learn and use > it. That is totally not acceptable for the general FreeBSD population. This argument is pretty weak, learning perforce takes 15-20 minutes. > Those that chose to use it because they feel the tool is useful for > THEMSELVES are of course free to use it. HOWEVER, Perforce is NOT the CM > system of the FreeBSD project. Thus users of Perforce are expected to > share their bits via posting patches, not forcing everyone to pull them > out of the Perforce depot. Well, if all developers started using p4, things would be easier and work better in the long term. p4 is lightyears ahead of cvs, and, from what I've read in this thread, developers are not exactly happy with cvs now, as it's limitations have become evident. So, why not give it a try? Just my 0.02 Eur Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg35021/pgp0.pgp Description: PGP signature
"Forking" FreeBSD: CVS vs. P4
Mike Barcroft wrote: > I'm getting sick of reading this. Terry, if you want this code > integrated into FreeBSD, here's what you do: 1) Find yourself a > mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current > sources, 4) Have them reviewed, 5) Commit them. > > If you aren't interested in doing this, you are the sole person to be > blamed for them not being integrated into FreeBSD. And I'm getting sick of being dragged down into details in what should be a meta-discussion, thus effectively glossing over the major point in order to pick on one or two "objectionable" paragraphs out of an entire posting. Right now we have a situation where people are complaining about large scale changes being "dangerous", and at the same time complaining that they are taking place in the P4 repository instead of the CVS repository. One of these points of view has to give, so a uniform policy exists that people can comply with before they burn months of work for naught, or are unwilling to give up all that work -- just as the "386BSD 0.5 interim release" group was unwilling to give up their work, and "forked" 386BSD to create the first FreeBSD. Either it's OK to make large scale changes in the CVS repository, or it's OK to make them in a seperate (only currently P4) reposity, and integrate them later. Topologically, as far as the project is concerned, there's no difference between making changes locally or making them in the P4 tree. The alternative is to simply disallow the changes, which I'm sure would please some people. I prefer the dichotomy be resolved, rather than glossed over. I think it's valuable to look at why this "immune response" is suppressing, among other things, my list of examples... which was far from comprehensive, and which are not *my* examples, in particular, merely because I raised them. As was noted elsewhere, there are now 57 P4 branches, most of them active, in which work is taking place outside the umbrella of "the one true HEAD" of the CVS repository. There's no possible way this situation could have arisen in the first place, had not people found themselves beating their heads against _some_ obstacle that migrating to P4 based developement removed, and which removal was worth the cost of being yelled at for using P4 (among other costs). It seems to me that what people are getting upset about is the fact that the people using P4 are "routing around the damage" and are thus able to collaborate effectively towards goals that others won't believe in until they have a working example thrown in their face, and would prefer to not have that. We have to ask ourselves: what damage is being routed around that could be worth paying the "popularity penalty", when people yell "Hey! That's *my* barrier you're routing around!". The differences in the P4 vs. CVS environment are many, but the main ones which seem, sociologically, to favor P4 are: o Multiple lines of developement o Reduced politics o Reduced/removed review barrier o Better small project collaboration vs. patches and email I should think that people would be interested in *why* the situation has arisen, and not merely interested in bitching about the fact that it exists. Frankly, though I think having only "one true HEAD branch", as imposed by the use of CVS, has hurt FreeBSD's progress enormously (by creating a GlobalCop model game), I have to say that the middle two are probably primary in the minds of the people now using P4. In fact, I'll say it straight our: IMO, it's the review barrier. Matt's commit bit was yanked a long time ago, right after he reached the point where he could spend 12+ hours a day hacking on FreeBSD, and the reviewer resources simply could not keep up with his output. He effectively flood attacked the review process. The reaction of yanking the bit, and the subsequent backlash "corrected" this: not by increasing the review rate, but by decreasing the rate at which new code is submitted, and decreasing the maximum size that can make it through review. The problem is not the barrier itself, it's the rate at which the barrier processes, and the maximum load it can handle. Now we have a P4 repository, and there are at present 57 special interests who are routing around that barrier's inability to handle load. Perhaps it's time to follow the lead of Linux, and break the review barrier into multiple barriers, with seperately controlled review processes. People involved in review would then have to pick what they cared about most, and *trust* the rest of the people to make the right decisions. The overall ability to handle load would go up, just like adding machines to a web farm increases capacity. Doing this has certain drawbacks, as Linux has discovered (USL had a similar situation with similar drawbacks), the foremost being that cross-domain changes were inordinately hard to push through (cv. Linux's recent issues with their VM system "forking" betw
Re: Patch to improve mutex collision performance
On Thu, Feb 21, 2002 at 09:14:54PM +0100, Dag-Erling Smorgrav wrote: > Matthew Dillon <[EMAIL PROTECTED]> writes: > > I'm not interested in using P4. I think it's a mistake. That is, I > > think it is being severely overused. [...] > > Frankly, although I use Perforce myself for PAM work, I agree with > Matt here. Most of what is going on in the Perforce should be > happening on branches in our main repo, if only CVS didn't suck so bad > at branching. > > I would like to suggest that we consider transitioning our main repo > to Subversion. It's reasonably similar to cvs, and has all the > features we need that cvs lack: metadata versioning, atomic commits, > cheap branching... As a Subversion developer and a FreeBSD user, I'd love to see this happen some day. Subversion is designed for precisely this sort of thing, a version control system for a project that likes many things about CVS, but doesn't wish to deal with its many drawbacks. Unfortunately, at the moment, Suversion is far from mature enough for such a transition. Some day, perhaps even some day soon, but not quite yet. What I would suggest though, is that FreeBSD developers who are interested in the possibility of such a transition int he future should subscribe to the Subversion development list (see http://subversion.tigris.org/ for instructions on how to subscribe) and try to make sure that the features we're currently building into subversion will meet FreeBSD's needs in the future. There have already been some NetBSD and Apple developers on the lists, along with a few FreeBSD people giving us valuable feedback, and any additional FreeBSD people would be very welcome. -garrett -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)
On Thu, Feb 21, 2002 at 08:11:52PM +0100, Dag-Erling Smorgrav wrote: > Bernd Walter <[EMAIL PROTECTED]> writes: > > There is still missing an overview over the p4 collections. > > No - I'm not going to cvsup p4-all - I already had an increasing of > > 1G overnight without a single warning. > > A p4-self collection is also missing. > > p4-all is not a good idea - Perforce makes branching very cheap, and > the repo reflects that :) There are currently 52 branches, some of > which are full copies of the FreeBSD source tree, and some of which > only include the kernel sources. Depends on what you want to do. I had p4-all on cvsup.de.freebsd.org, but it growed massively without warnings and the collectios had to be created manualy. I stoped distributing p4* because of disk space limitations in december. If there is no overview to show which cvsup servers hold these special collections most people will fall back to cvsup10.freebsd.org, if they ever know them. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Matthew Dillon <[EMAIL PROTECTED]> writes: > I'm not interested in using P4. I think it's a mistake. That is, I > think it is being severely overused. [...] Frankly, although I use Perforce myself for PAM work, I agree with Matt here. Most of what is going on in the Perforce should be happening on branches in our main repo, if only CVS didn't suck so bad at branching. I would like to suggest that we consider transitioning our main repo to Subversion. It's reasonably similar to cvs, and has all the features we need that cvs lack: metadata versioning, atomic commits, cheap branching... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Terry Lambert <[EMAIL PROTECTED]> writes: > Other people's code has dropped by the wayside completely, and > been lost; the SACK/TSACK work Luigi did never got integrated > and accepted by the project, and LRP code that Peter Druschel > and Gaurav Banga did at Rice University, which was originally > done against FreeBSD 2.2. For that matter, we've also lost > out on integration of the IO-Lite code, also from Rice (both > were a result of the ScalaServer project). Likewise, the CMU > work on TCP Rate Halving (admittedly, it's based on NetBSD 1.3.2, > but that's not that significantly different from FreeBSD to matter), > as well as their FACK/SACK implementation. I'm getting sick of reading this. Terry, if you want this code integrated into FreeBSD, here's what you do: 1) Find yourself a mentor, 2) Get a commit bit, 3) Update worthy patchsets to -current sources, 4) Have them reviewed, 5) Commit them. If you aren't interested in doing this, you are the sole person to be blamed for them not being integrated into FreeBSD. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
"Michael D. Harnois" wrote: > On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > > On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > > > > > > Maybe this can now be committed? > > > > NOT until I have sufficient feedback from the FSF Binutils developers. > > OK, I'm confused. binutils has been broken for three weeks. We have a > patch that we know fixes, at the very least, one of the known problems. > However, it can't be committed without feedback from the developers. > > So having binutils broken indefinitely is better than applying a patch > that *might* have to be backed out or altered later? I believe the intent is to ensure that the patches make it back into the FSF distributed code, so that in the future, there is less maintenance required for FreeBSD platforms. This offloading of maintenance is a good idea, considering the stated positions of those with the currently thankless job of beating FSF code into submission to make it run on FreeBSD platforms. Actually, there was a discussion at BSDCon as to whether or not to drop the a.out support in order to decrease the patch size necessary to make the FSF distributed code do what FreeBSD needed it to do (personally, I would prefer that the a.out code generation be integrated back into the FSF code base but this is unlikely for FSF political reasons with regard to the intent to get rid of the a.out standard entirely). Such changes to the FreeBSD toolchain are necessary, unless there is sufficient support for what the FSF views as being gratuitous differences (e.g. not replacing BSD make with GNU make like FreeBSD is "supposed to do", etc.). While I would incredibly dislike losing a.out, since most of the promised advantages of ELF have not materialized (some, such as linking a library against a library have... but only for shared libraries), I have to side with David O'Brien, since he is at least actively involved in maintaining the code in question. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)
Bernd Walter <[EMAIL PROTECTED]> writes: > There is still missing an overview over the p4 collections. > No - I'm not going to cvsup p4-all - I already had an increasing of > 1G overnight without a single warning. > A p4-self collection is also missing. p4-all is not a good idea - Perforce makes branching very cheap, and the repo reflects that :) There are currently 52 branches, some of which are full copies of the FreeBSD source tree, and some of which only include the kernel sources. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compile errors after yesterdays cvsup and makeworld.
Quoting David Wolfskill <[EMAIL PROTECTED]>: > >Date: Thu, 21 Feb 2002 09:48:10 -0800 > >From: [EMAIL PROTECTED] > > >I sure missed something, I'm sorry. I still have the problem with > >buildworld. What should I do to fix it? > > ># /usr/bin/cc -print-search-dirs > >install: /usr/libexec/(null) > >programs: /usr/libexec/elf/ > >libraries: /usr/lib/ > > Well, you need to do something so the installed cc actually works. > > What worked for me was to do the following just before starting the > "make buildworld"": > > * cd /usr/libexec/elf > * ln -s ../cc* ../cpp* . David, Of course, I paniced. Thanks for the help. It sure seems to be working. It sure makes me feel good to see something compiling :-) Your help, as always is invaluable. Thanks, ed > > Then go through the usual "make buildworld" & friends. > > After the "make installworld" is done (I actually did this after > "mergemaster"): > > * cd /usr/libexec/elf > * rm cc* cpp* > > Following the reboot, I created a "hello.c" in /tmp, typed "make", and > was mildly gratified to see that it not only compiled without complaint, > it even ran properly. :-} > > Cheers, > david (links to my resume at http://www.catwhisker.org/~david) > -- > David H. Wolfskill[EMAIL PROTECTED] > I believe it would be irresponsible (and thus, unethical) for me to advise, > recommend, or support the use of any product that is or depends on any > Microsoft product for any purpose other than personal amusement. > - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
Michael D. Harnois wrote: > On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > > >>On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: >> >>>Maybe this can now be committed? >>> >>NOT until I have sufficient feedback from the FSF Binutils developers. >> > > OK, I'm confused. binutils has been broken for three weeks. We have a > patch that we know fixes, at the very least, one of the known roblems. > However, it can't be committed without feedback from the developers. > > So having binutils broken indefinitely is better than applying a patch > that *might* have to be backed out or altered later? > I would like to wait and see what David comes up with. I've applied the patch and things work for the most part, but there are some problems I'm having with the vim, open-motif-devel and AbiWord ports that I did not see until this patch. So I guess the lesson is that if you want to run -CURRENT you just have to roll with the punches. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compile errors after yesterdays cvsup and makeworld.
>Date: Thu, 21 Feb 2002 09:48:10 -0800 >From: [EMAIL PROTECTED] >I sure missed something, I'm sorry. I still have the problem with >buildworld. What should I do to fix it? ># /usr/bin/cc -print-search-dirs >install: /usr/libexec/(null) >programs: /usr/libexec/elf/ >libraries: /usr/lib/ Well, you need to do something so the installed cc actually works. What worked for me was to do the following just before starting the "make buildworld"": * cd /usr/libexec/elf * ln -s ../cc* ../cpp* . Then go through the usual "make buildworld" & friends. After the "make installworld" is done (I actually did this after "mergemaster"): * cd /usr/libexec/elf * rm cc* cpp* Following the reboot, I created a "hello.c" in /tmp, typed "make", and was mildly gratified to see that it not only compiled without complaint, it even ran properly. :-} Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
compile errors after yesterdays cvsup and makeworld.
I sure missed something, I'm sorry. I still have the problem with buildworld. What should I do to fix it? # /usr/bin/cc -print-search-dirs install: /usr/libexec/(null) programs: /usr/libexec/elf/ libraries: /usr/lib/ Thanks, ed Quoting Edwin Culp <[EMAIL PROTECTED]>: > David, > > I see it's already fixed so I'll assume that you no longer need the > compiler output. I'm sorry that I didn't answer before but I just > checked my email and went to some meetings and am just getting back. > > Thanks for your help, > > ed > > Quoting David O'Brien <[EMAIL PROTECTED]>: > > > On Wed, Feb 20, 2002 at 05:53:59AM -0800, Edwin Culp wrote: > > > On my daily build, my kernels are broken as per log: > > > > > > ===> wi > > > cd /usr/obj/usr/src/sys/PIII850N; > > MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm > > > make - > > > f /usr/src/sys/dev/aic7xxx/aicasm/Makefile > > > Warning: Object directory not changed from original > > /usr/obj/usr/src/sys/PIII850N > > > cc -O -pipe -I/usr/include -I.-c aicasm_gram.c > > > cc: installation problem, cannot exec `cpp0': No such file or directory > > > cc: installation problem, cannot exec `cc1': No such file or directory > > > *** Error code 1 > > > > > > I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the > > problematic compiler. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > > -- > To announce that there must be no criticism of the president, > or that we are to stand by the president, right or wrong, is not > only unpatriotic and servile, but is morally treasonable to > the American public. - Theodore Roosevelt > > > > --- > - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On 21-Feb-02 David O'Brien wrote: >>> I'm fairly sure JHB does not have a patch to address this but, please, >>> be my guest and check P4. >> >> Actually he does. Maybe you should have checked p4 first yourself. > > Users of Perforce are starting to force the rest of us to learn and use > it. That is totally not acceptable for the general FreeBSD population. > Those that chose to use it because they feel the tool is useful for > THEMSELVES are of course free to use it. HOWEVER, Perforce is NOT the CM > system of the FreeBSD project. Thus users of Perforce are expected to > share their bits via posting patches, not forcing everyone to pull them > out of the Perforce depot. They are shared now just as often as before. Actually, more so. Remember the days of my one big sys.patch where I'd have to spend a night trying to commit the bits piecemeal? Contrast that with the way the MI pcpu stuff went in, or the first round of changes to add td_ucred. I actually have cron jobs that can generate updated diffs of the important p4 trees every 15 min or so but don't have most of them on for fear of hurting freefall with the extra load. You are asking for people to do more than they have done before and blaming their not doing it on the tools they are using. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
http://www.freebsd.org/smp/ Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Wed, 20 Feb 2002, George V. Neville-Neil wrote: > I'm not in the core of the SMP stuff (the closest I'll get is the > networking stuff) but I wonder if there is: > > 1) A work list of things that need to be done. > > 2) If that list is easy to read/update. > > Has anyone considered a Wiki to do this kind of coordination? We used > TWiki at my last employer to decent effect. Check out www.twiki.org. > > Later, > George > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, 2002-02-21 at 04:03, David O'Brien wrote: > On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > > > > Maybe this can now be committed? > > NOT until I have sufficient feedback from the FSF Binutils developers. OK, I'm confused. binutils has been broken for three weeks. We have a patch that we know fixes, at the very least, one of the known problems. However, it can't be committed without feedback from the developers. So having binutils broken indefinitely is better than applying a patch that *might* have to be backed out or altered later? -- Michael D. Harnois bilocational bivocational Pastor, Redeemer Lutheran ChurchWashburn, Iowa 1L, UST School of Law Minneapolis, Minnesota Creative thought means that you forgot where you read it. --Stanley Hauerwas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: Minor rc.firewall{,6} Change
I just made a few _minor_ changes to the rc.firewall{,6} scripts. The
vast majority of users will not be affected. However, since a few may
be, and this is a security issue with the potential to cause some
subtle breakage, I felt a small HEADS UP was in order. (For the very
security conscious and paranoid, note that this change can only
"fail-safe" if people apply it blindly. You'll be "more secure," but
it may break stuff.)
If you do not use firewalling or rc.firewall{,6} at all (that is, you
do not have 'firewall_enable="YES"' and/or
'ipv6_firewall_enable="YES"') or if you use custom rc.firewall{,6}
scripts, you are not affected. Two groups of people who use the
provided firewall scripts are affected:
1) Those who put a rules file in the 'firewall_type' variable, or
2) Those who put a non-existent type in the 'firewall_type' variable.
In both cases, you will no longer get the rules,
100 pass all from any to any via lo0
200 deny all from any to 127.0.0.0/8
300 deny ip from 127.0.0.0/8 to any
In rc.firewall, and,
100 pass all from any to any via lo0
200 pass ipv6-icmp from :: to ff02::/16
300 pass ipv6-icmp from fe80::/10 to fe80::/10
400 pass ipv6-icmp from fe80::/10 to ff02::/16
In rc.firewall6 added to your firewall by the system scripts.
If you are in group (1), you should add whatever rules like these
_you_ want for _your_ site into your rule file. If you are in group
(2), use 'firewall_type="closed"' (which now works as advertised) will
give you the same effect as your current configuration.
The motivation for the change was mainly for the people in group
(1). Up until now, those rules were added _unconditionally_ by the
rc.network{,6} scripts. For people who want to define their own
rulesets outside of the simple ones provided in the rc.firewall{,6}
scripts, the system should make NO assumptions about your site's
policy and be adding rules.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: make release failure in kerberos
On Thu, Feb 21, 2002 at 06:24:59AM +0200, John Hay wrote: > Hi Jacques, > > Make release fails here. Can it be your changes to kerberos? Could be; I'll have a look. Thanks! -- Jacques A. Vidrine <[EMAIL PROTECTED]> http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
On Thu, 21 Feb 2002, Greg Lehey wrote: > On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: > > > >>> What John's patch does is spin while the lock owner is running on > >>> another cpu. Spinning while there are no other processes on the run > >>> queues as well makes sense but you'll also be doing a lot of > >>> acquires and releases of sched_lock. > >> > >> I must be misinterpreting this statement. Under what circumstances do > >> you spin? Yes, I read the "while the owner is running in another > >> CPU", but the way I read that, it turns the blocking lock into a spin > >> lock. > > > > Only in some cases. This is the classic way of implementing an adaptive mutex. > > Well, no, the classic way of implementing an adaptive lock is to spin > a little bit and then block. Alternatives would be to learn what's > going on and then decide whether to spin or block, or how long to spin > before blocking. I've never heard it applied to a choice of CPU. > Obviously any "spin lock" shouldn't spin if the lock holder is in the > same CPU. The spin only if the owner is running on another CPU is an optimization. There's no sense in spinning unconditionally when you can see if the mutex' owner is running on another CPU. This is how adaptive mutexes in Solaris work also. > > You spin if the other thread is actually executing on another CPU (the idea > > being it will release the lock soon so you are better off avoiding the context > > switch) and block if it is not executing on another CPU (releasing the lock is > > already at least one context switch away, so we might as well > > switch). > > If you're talking about Giant here, one of us is seriously > misunderstanding something. The whole idea of Giant is that it should > be a blocking lock, not a spin lock. Tell me I'm misunderstanding > you. The very first project milestone at http://www.freebsd.org/smp/ > read "Convert the giant lock from spinning to blocking". The spin should be very short lived if the current owner is running on another CPU. There is a lot of overhead in blocking and switching contexts, plus don't you also have to take sched lock if you block? If you know the current owner of the mutex is running on another CPU, then you should acquire the mutex within a few cycles. You have to make the assumption that mutexes are held for very short periods of time, and that there are not a lot of highly contested adaptive mutexes. > You might say "ah, but the average system call takes less time than a > schedule". We can test that. I've run lmbench on zaphod and found: > > Scheduling overhead: 18 µs > Null syscall (1 CPU): 9 µs > Null syscall (2 CPUs):57 µs > > So this doesn't stand up. Note also that if there are more than two > CPUs, the loss of time is much more significant. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
On Thu, Feb 21, 2002 at 12:05:31AM +0100, Stijn Hoop wrote: > I ventured into this brave new world a few days ago and ran into > this very problem. Alexander's patch (along with a make install in > /usr/src/gnu/usr.bin/binutils) fixed it, as advertised. > > Maybe this can now be committed? NOT until I have sufficient feedback from the FSF Binutils developers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
>> I'm fairly sure JHB does not have a patch to address this but, please, >> be my guest and check P4. > > Actually he does. Maybe you should have checked p4 first yourself. Users of Perforce are starting to force the rest of us to learn and use it. That is totally not acceptable for the general FreeBSD population. Those that chose to use it because they feel the tool is useful for THEMSELVES are of course free to use it. HOWEVER, Perforce is NOT the CM system of the FreeBSD project. Thus users of Perforce are expected to share their bits via posting patches, not forcing everyone to pull them out of the Perforce depot. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch to improve mutex collision performance
Matthew Dillon wrote: [ ... ] > :How do you reconcile these divergent points of view? > > These are not divergent points of view. I am saying quite clearly that > the ucred code and proc-locking code can be committed in a piecemeal > fashion. In fact, good chunk of the proc locking code already has been > with no ill effect on the tree - it might not be completely operational > due to Giant, but just comitting it tests a great deal of infrastructure > including potential lock order reversals and mismatched locks. That's > the whole point of doing things this way. If you'll notice, the post to which you are replying was posted before your last post on the same topic. > :Do you have a set of rules, that would let us look at a patch > :set and instantly decide which of these two categories the > :code fell into? > : > :I'm not trying to be a jerk, but not everything can be broken > :down into 1 line commits, and not everything can be broken down > :into 8 line commits, or 64 line commits, or 512 line commits, > :etc. (if you'll forgive my proof by induction). > > This is getting a bit absurd. I am arguing a general principle here, > you are not contributing anything by stretching it into an irrational > statement. One line commits? Oh come on! I'm asking because I've made changes like this which never got in, and the review cycle was such that unless they were reviewed immediately, the patches wouldn't cleanly apply. In other words, anything that makes an interface change is going to fall into the category os "too big". I've also done changes that were very large scale, and could be broken up, but when they were actually broken up, there was no obvious benefit to about 3/4's of them, so the broken up pieces were labelled as "gratuitous", when in fact they were necessary foundation work for the last 1/4 of the changes. Rarely, I've made sweeping changes, and they've been sheparded into the source tree by Julian's dogged (and appreciated) persistance, e.g. when I rewrote init_main.c and added the original SYSINIT() construct using linker sets, or reinvented later by someone else, e.g. my nameifree() changes to make it so that there was no longer a "caller allocate/callee free" interface for nameidata. Other people's code has dropped by the wayside completely, and been lost; the SACK/TSACK work Luigi did never got integrated and accepted by the project, and LRP code that Peter Druschel and Gaurav Banga did at Rice University, which was originally done against FreeBSD 2.2. For that matter, we've also lost out on integration of the IO-Lite code, also from Rice (both were a result of the ScalaServer project). Likewise, the CMU work on TCP Rate Halving (admittedly, it's based on NetBSD 1.3.2, but that's not that significantly different from FreeBSD to matter), as well as their FACK/SACK implementation. It just seems to me that FreeBSD is blocking integration of important research advances, and I don't see a clear criteria being used to make this decision... a "general principle". > I will say that the work *I* am doing on -current is mostly piecemeal > in nature. I even expect the VM locking to wind up being piecemeal. > Everything I have posted to date has been piecemeal. For example, > the ucred patchset I posted does not patch all the ucred functions, > it just patched the read-only functions. But as a side effect that > gave me a basis to track down the other uses of Giant in the general > syscall path. That was a good demarkation point for me. It is by > no means the end... it is, as I have said, piecemeal. Not "everything to date"; "everything recently", perhaps. It was not so long ago that you had your commit priviledges yanked for, in effect, producing code faster than it could be reviewed and vetted, so you checked in anyway. You've got them back, and have since got the "incremental changes" religion: there are none so zealous as a recent convert, it seems. Right now, you're trying to enforce this world-view, which was enforced on you, on others. All I'm asking is "where is the line in the sand?". I know that a lot of the people doing work in the P4 repository would just as soon be commiting to the main CVS repository, instead, but, frankly, they are not *permitted* to do this. So they do the work in P4, in order to build a consensus around the code, so that it can be jammed in over the "go slow" objections. > The result? I was able to immediately note the use of Giant in > trap.c (the ucred clearing code) as well as its use in userret(), > plus I could test a few of the ucred functions like getuid() and test > the Giant instrumentation. Look, I'm not faulting your work, or your choice of the "interesting problems" you choose to work on, but I do maintain that not everything can be done as incrementally as you seem to want it done these days. You as much as admitted th
