Re: make -jN buildworld on 512MB ram
On Wed, Oct 31, 2012 at 12:58:18PM -0700, Alfred Perlstein wrote: It seems like the new compiler likes to get up to ~200+MB resident when building some basic things in our tree. Unfortunately this causes smaller machines (VMs) to take days because of swap thrashing. You could try reducing data seg size (ulimit -d) to something matching RAM size. GCC has two parameters to try to keep its memory usage reasonable: http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Optimize-Options.html 'ggc-min-expand' and 'ggc-min-heapsize'. ggc-min-expand ... If getrlimit is available, the notion of RAM is the smallest of actual RAM and RLIMIT_DATA ggc-min-heapsize The default is the smaller of RAM/8, RLIMIT_RSS, or a limit which tries to ensure that RLIMIT_DATA or RLIMIT_AS are not exceeded I don't know if Clang/LLVM has something similar or not. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote:
Here's an updated version of the workaround that works properly in all
cases and installs bmake as make and links make to pmake when
WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is
specified (this works better than the previous patch I sent to Simon).
Garrett,
I don't see how this could be committed -- it will make it difficult
for 10-CURRENT folks to build ports (and there are no pre-build packages
for 10-CURRENT).
Are you not able to use this instead (w/WANT_USRBIN_BMAKE= in /etc/src.conf)?
Index: usr.bin/Makefile
===
--- usr.bin/Makefile(revision 241927)
+++ usr.bin/Makefile(working copy)
@@ -281,6 +281,9 @@ SUBDIR+=msgs
.if ${MK_BMAKE} != no
SUBDIR+= bmake
.else
+.if defined(WANT_USRBIN_BMAKE)
+SUBDIR+= bmake
+.endif
SUBDIR+= make
.endif
.endif
--
-- David (obr...@freebsd.org)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote: Here's an updated version of the workaround that works properly in all cases and installs bmake as make and links make to pmake when WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is specified (this works better than the previous patch I sent to Simon). Also, please note we have a 'pmake' port that is the proper original pmake (before *BSD embellished it). Perhaps a different name than 'pmake' is appropriate. It would not surprise me for someone to end up adding a port of the current FreeBSD make in case there are folks that find bmake incompatible with their use of FreeBSD's make in their own projects. So picking a good name now would be helpful. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, Oct 02, 2012 at 07:19:55AM -0700, Garrett Cooper wrote: Hmmm... that's one of the 3 approaches I provided, but it turned out ... 1. Test programs live with the sources (this was the requested approach), e.g. 2. Test programs live in subdirs: 3. Test programs completely decoupled from the source tree: Could someone please commit at least one working .c test and one .sh test? There is nothing to follow for others trying to write their own tests in the FreeBSD-way. I could not find a single consumer of ATF in HEAD. This makes it seem this is still a WIP that should be living in a branch and not in HEAD. But we're paying the price for checkout build times, etc... See the recent 9.1-R thread and Peter Wemm (and others) comments in this regard. (this is why I hadn't committed the WIP I had - it wasn't ready for HEAD) thanks, -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 02:23:06PM -0700, Marcel Moolenaar wrote: I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. I'm trying to create an ATF test for filemon, but I don't want to have to build make back and forth when I want to build a port. Likely that doesn't put me in the people working on ATF in your book. So let's work the bmake side and be able to get rid of the knob as soon as possible. Do we have any commitment as to when Portmgr will have bandwidth to for testing bmake (I expect it will be several iterations)? I suspect they're pretty busy with 9.1-RELEASE, so is this gated by 9.1-R? 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. What can I and others do to work on this? I'm not on Portmgr and most aren't either. In short: this isn't a 2-knob problem by any stretch of the imagination. I disagree. Before sending my mail, I ran this by sjg and his response was: I have absolutely no objection. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Fri, Oct 26, 2012 at 09:41:36AM -0600, Ian Lepore wrote: We have to be able to build the same source for multiple versions of freebsd, so even finding all the old :U and :L and any other incompatibilities and fixing them isn't an option because we'd just trade works in freebsd 10 for broken in every other environment. Ian, If you're using FreeBSD 9 after 2012-06-14, or FreeBSD 8 or 7 after 2012-10-09 you can use the Bmake spelling of :U and :L (:tu/:tl). I am not aruging against you, just giving some information you may not be aware of. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Fri, Oct 26, 2012 at 12:12:44AM +0200, Baptiste Daroussin wrote: Do be able to get the ports tree working with bmake asap, I also asked him to MFC it to 9.1, from latest reply he got positive answer from re@ about this, but was waiting for something I don't remember. :tu/:tl is in releng/9.1, so it will also be in 9.1-RELEASE. -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Mon, Oct 08, 2012 at 09:11:29AM -0700, Marcel Moolenaar wrote: two independent efforts (ATF bmake) and there was no indication that one would be greatly benefitted from the other. At least not to the point of creating a dependency. It seems we do have the situation where folks feel there is a dependency between the two. Before we can switch permanently to bmake, we need to do the following first: 1. Request an EXP ports build with bmake as make(1). This should tell us the damage of switching to bmake for ports. 2. In parallel with 1: build www docs with bmake and assess the damage 3. Fix all the damage It could be a while (many weeks) before we get to 4, so the question Given the time this will take, I feel we need to add another knob to the Bmake build so that 'make world' gives one both the FreeBSD make as /usr/bin/make and Bmake as /usr/bin/bmake. thoughts, -- -- David (obr...@freebsd.org) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: OpenBSD sdiff Question
On Fri, Mar 14, 2008 at 07:14:04PM -0400, Steven Kreuzer wrote: I achieve 100% compatability with the GNU version, I need to add -v/--version and the issue I ran into is that since this program would become part of the base os, what exactly should be displayed. I see no reason you need to be 100% compatabile with respect to -v/--version. Just about every GNU util has a --version output, but few (none?) BSD utils do. -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenBSD sdiff Question
On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: Even if BSD has no tradition to keep a separate program version, it is still very handy to be able to give this data to other developers if something is failing. $ ident failing-binary is the output that means something. A version string will not. Programs that don't have a -v or --version switch are frustrating to Anyone used to working on BSD will not expect a -v switch. It isn't part of BSD tradition. The simple fact there is no obivous version to print just shows that in a OS that is developed and built as a whole, having a version on the util is meaningless. Dropping -v would be a bad thing, and make the tools not compatible, thus breaking many scripts that do expect a -v. Come on, how many scripts do you write that do sdiff -v today? -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vkernel GSoC, some questions
On Sat, Mar 15, 2008 at 02:58:40PM +0200, Jordan Gordeev wrote: I am a student who considers applying for Google's Summer of Code programme. One of my ideas for a GSoC project has the following synopsis: Add virtual kernel (vkernel) support to FreeBSD for the i386 and amd64 architectures. The vkernel support in question is the one found in DragonFlyBSD. Not being up on DragonFlyBSD, can you better describe what vkernel is? -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testers: CVSMode for csup
On Thu, Mar 06, 2008 at 01:44:59PM +0100, Ulf Lilleengen wrote: During the past few months, I've implemented CVSMode support for csup. This would be good to have. Have you looked at CVSync http://www.cvsync.org/ to see how he handled some of the wierdness in ,v files? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulate an end-of-media
On Tue, Feb 26, 2008 at 09:28:53PM +0100, Joerg Sonnenberger wrote: On Tue, Feb 26, 2008 at 07:44:48PM +0100, Martin Laabs wrote: I also made a comparison between gzip and bzip2 regarding the compression ratio on a dump of my home directory (3.2GB) bzip2 took about 74min to compress, gzip only 11minutes. And in terms of compression ratio bzip2 was only 3% better than gzip. That's not a realistic test case. bzip2 normally takes trice the time and compresses 10% better. I can't comment on compress. Actually I've found that it depends on which architecture you run bzip2 and gzip on. Taking a sample set of files, I found bzip2 was faster on amd64 than gzip; and gzip was faster on i386 than bzip2. [its been a while... I might have the two reversed] -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/nfsclient nfs_socket.c
On Tue, Aug 29, 2006 at 10:00:12PM +, Mohan Srinivasan wrote:
mohans 2006-08-29 22:00:12 UTC
FreeBSD src repository
Modified files:
sys/nfsclientnfs_socket.c
Log:
Fix for a deadlock triggered by a 'umount -f' causing a NFS request to never
retransmit (or return). Thanks to John Baldwin for helping nail this one.
Revision ChangesPath
1.144 +14 -2 src/sys/nfsclient/nfs_socket.c
http://cvsweb.freebsd.org/src/sys/nfsclient/nfs_socket.c.diff?r1=1.143r2=1.144
How does this look for a RELENG_6 version of this fix?
Index: nfsclient/nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfsclient/nfs_socket.c,v
retrieving revision 1.125.2.18
diff -u -p -r1.125.2.18 nfs_socket.c
--- nfsclient/nfs_socket.c 17 Jan 2008 21:04:51 - 1.125.2.18
+++ nfsclient/nfs_socket.c 25 Feb 2008 10:26:59 -
@@ -1323,6 +1323,18 @@ nfs_timer(void *arg)
continue;
if (nfs_sigintr(nmp, rep, rep-r_td))
continue;
+ else {
+ /*
+* Terminate request if force-unmount in progress.
+* Note that NFS could have vfs_busy'ed the mount,
+* causing the unmount to wait for the mnt_lock, making
+* this bit of logic necessary.
+*/
+ if (rep-r_nmp-nm_mountp-mnt_kern_flag
MNTK_UNMOUNTF) {
+ nfs_softterm(rep);
+ continue;
+ }
+ }
if (nmp-nm_tprintf_initial_delay != 0
(rep-r_rexmit 2 || (rep-r_flags R_RESENDERR))
rep-r_lastmsg + nmp-nm_tprintf_delay now.tv_sec) {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Wed, Mar 05, 2008 at 01:02:17PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: : On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: : Solaris lacks TAILQ_xxx stuff too, so I would prefer something like : bsdcompat.h or similar. : : Seconded - linux.h is far too generic. I must say I like the idea : of being able to build *BSD on Linux machines! : : Why? What are you going to do with it? Presumable install it : somewhere, where? : : Will the differences in the end result of what is built worth the risk, : vs. installing VMware player and building FreeBSD on FreeBSD on Linux? The end result will be the ability to build FreeBSD on a Linux host. VMware players aren't an option, and will not be contemplated as an acceptable solution. The overhead is too high, especially when explaining to people what needs to be done to deploy. I think you're wrong about the overhead is too high... - but the proof will be in the pudding. With installing VMware player and building FreeBSD on FreeBSD - all the 10,000's of docs explaining to users how to build will be valid. With this cross build these docs will be wrong - folks will be much more on their own. Beyond the docs - I think you underestimate the amount of work getting all the cross-tools built and installed will be. I guess we'll just have to wait and see. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: here's a set of diffs that will allow FreeBSD's usr.bin/make to build on Linux. I'm sure they are gross, and I don't plan to commit them (at least not all of them), but I thought I'd post them here to see what people think. Take a look at ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/bmake-20080215.tar.gz (a portable NetBSD make) there are probably ideas in there for a portable fbsdmake. I dare say you could just grab the autoconf bits from there (with a little modification) and avoid having to learn autoconf/automake. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 10:58:15AM +0100, Rink Springer wrote: On Tue, Mar 04, 2008 at 10:17:30AM +0200, Giorgos Keramidas wrote: Solaris lacks TAILQ_xxx stuff too, so I would prefer something like bsdcompat.h or similar. Seconded - linux.h is far too generic. I must say I like the idea of being able to build *BSD on Linux machines! Why? What are you going to do with it? Presumable install it somewhere, where? Will the differences in the end result of what is built worth the risk, vs. installing VMware player and building FreeBSD on FreeBSD on Linux? -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 03:15:32PM +, Robert Watson wrote: In most ports of FreeBSD parts to Linux that I've seen, the preferred solution has to been to bring the entire FreeBSD queue.h with you rather than relying on the native Linux queue.h. This is what we do for OpenBSM, for example; this also helps out when you get to Mac OS X, We should stand back and divide the goal of building FreeBSD on MacOS X, Solaris, and Linux this into two topics: 1. How to get a suitable set of build tools. This is everything FreeBSD's src/Makefile.inc calls bootstrap, build, and cross tools. This will 90% require scripts and duplicated (but portable) sources in the projects CVS repository, with distfiles on ftp.freebsd.org. These scripts and bootstrap tools should be able to depend on a checked out FreeBSD src/ tree to reach over into. We would probably need to trim less of our GNU tools in src/contrib when we import them. 2. Given a suitable set of tools (probably in the number of 20), built and installed on your MacOS X, Solaris, or Linux hosts - how do we now build FreeBSD. This is not the 'buildworld' or 'buildkernel' targets. Those targets are explicitly designed to build FreeBSD on a FreeBSD system. Those builds create bootstrap, build, and cross tools that we've covered in #1. I'm not sure how many folks know that this works (on FreeBSD): cd /usr/src make buildworld installworld make clean make that is, a simple 'make' does build everything. Why was the buildworld target created? Because if your installed system does not 100% match your sources, you're doing a cross build. Presumably we'd have to create a suitable target (say 'nonhosted-cross') that sets up CC, AR, etc... macros to use the tools from #1. DISTDIR would also need to be set. This target would do something like: make includes # this builds and installs make libaries # I don't recall if this includes installing make installlibaries make all make install -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 05:45:43PM +0200, Giorgos Keramidas wrote: To test just cpp(1) stuff, autoconf supports AC_PREPROC_IFELSE() too, which I used when I tried writing a check for __FBSDID(): Why are you writing a check for __FBSDID? Our sources so assume it that IMnoHO you just need to provide it. See missing/sys/cdefs.h in ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/bmake-20080215.tar.gz -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: #include arch.h +#include config.h Are you able to use CFLAGS+= -include config.h instead? If so, that would mean less .[ch] changes. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 05:37:30PM +0200, Giorgos Keramidas wrote: The next part, about the missing errx() functions on Solaris is going to be tonight's fun. If there are too many missing functions, it may be worth adding a static `libcompat' with copies of just the functions we need to run BSD make on non-BSD hosts. fbsdmake will be just one of many tools you'll find you need. A libfbsdcompat would be useful to this endevor. If I were you, I would try to create one using FreeBSD src/ - that is assume a checked out FreeBSD is available. See some of my sed'ing and unifdef*(1) hacks I've used over the years to build GNU stuff on FreeBSD. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 11:04:07AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: : #include arch.h : +#include config.h : : Are you able to use CFLAGS+= -include config.h instead? : If so, that would mean less .[ch] changes. There is also -imacros file Exactly like -include, except that any output produced by scanning file is thrown away. Macros it defines remain defined. This allows you to acquire all the macros from a header without also processing its declarations. that may be useful if you run into other problems. http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Preprocessor-Options.html#Preprocessor-Options lists other options that may be used for tricks in building. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
On Tue, Mar 04, 2008 at 09:38:25PM +0200, Giorgos Keramidas wrote: On 2008-03-04 09:58, David O'Brien [EMAIL PROTECTED] wrote: On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: #include arch.h +#include config.h Are you able to use CFLAGS+= -include config.h instead? If so, that would mean less .[ch] changes. Not with Sun Studio compilers on Solaris. You know... I really don't think you're going to get very far in your overall goal of building FreeBSD on Solaris if you insist on both Solaris and Sun Studio. GCC is bundled in Solaris 10, so you know its there. I don't think the performance differences between the SUNWspro compiler and GCC will matter to your fbsdmake performance. There's a fair amount of things that can be done without _any_ source code change at all, but there's also a limit to what can be done. Sun bought VirtualBox - it runs on Solaris you know... -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
[ DO NOT REPLY TO MY PREVIOUS MESSAGE WITH THESE SAME CONTENTS I GOOFED AND SET REPLY-TO freebsd-alpha !! ] On Tue, Mar 04, 2008 at 09:38:25PM +0200, Giorgos Keramidas wrote: On 2008-03-04 09:58, David O'Brien [EMAIL PROTECTED] wrote: On Mon, Mar 03, 2008 at 10:42:56PM -0700, M. Warner Losh wrote: #include arch.h +#include config.h Are you able to use CFLAGS+= -include config.h instead? If so, that would mean less .[ch] changes. Not with Sun Studio compilers on Solaris. You know... I really don't think you're going to get very far in your overall goal of building FreeBSD on Solaris if you insist on both Solaris and Sun Studio. GCC is bundled in Solaris 10, so you know its there. I don't think the performance differences between the SUNWspro compiler and GCC will matter to your fbsdmake performance. There's a fair amount of things that can be done without _any_ source code change at all, but there's also a limit to what can be done. Sun bought VirtualBox - it runs on Solaris you know... -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
On Mon, Feb 25, 2008 at 10:33:41PM +0200, Giorgos Keramidas wrote: On 2008-02-23 16:48, M. Warner Losh [EMAIL PROTECTED] wrote: This knee-jerk reaction against gnu find functionality baffles me. The changes are trivial and make FreeBSD more compatible. It is such an obvious no-brainer that I frankly didn't expect anybody to bat an eye. So should I expect similar knee-jerk reactions to the just committed `finger compatibility' option to implement du -l for hardlinks? You added a new useful feature - and you based the option letter on prior-art (and resumable doen't conflict with POSIX). -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modular type GENERIC?
On Tue, Feb 26, 2008 at 01:56:28PM +0900, Adrian Chadd wrote: On 26/02/2008, David O'Brien [EMAIL PROTECTED] wrote: As you've shown the magic is in the loader.conf. I don't know a good way to handle this other than attempt to load every module (like Microsoft NT installer does) - and hope the probe of a driver that doesn't claim a device doesn't leave that device in a bad state. Have you tried putting every module in /boot/kernel into loader.conf in a load statement? I'm going to try doing that tonight. Cool. Please let us(me) know how it goes. -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modular type GENERIC?
On Thu, Feb 28, 2008 at 03:26:55PM +0900, Adrian Chadd wrote: Is there some sane-ish way of auto-generating a list of modules given a config file? The device statements don't match up with the module name in all bar 4 or 5 places. Is there some chain of files I can munge to match things up? Not that I know of. :-( -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
On Sun, Feb 24, 2008 at 12:43:39PM -0700, M. Warner Losh wrote:
:{ -empty, c_empty,f_empty,0 },
:{ -exec, c_exec, f_exec, 0 },
:{ -execdir, c_exec, f_exec, F_EXECDIR },
: - { -false, c_simple, f_not, 0 },
: + { -false, c_simple, f_false,0 },
:
: This brakes FreeBSD compatiblity in the favor of GNU. What will
: old FreeBSD user think when his scripts will stop working
: after next cvsup? I suppose our target not to make FreeBSD
: to look like Linux. If you want to add GNU-like false option,
: please, add it under the different name.
I considered it, but rejected it. The current -false option doesn't
make any sense at all, likely isn't used, is just a short-cut for '!'
and had a very dubious justification when it was committed.
Hum... did you survey a sufficient number of folks to get a feel for its
usage in the wild? Do the other BSD's have this option and how have they
implemented it? Changing existing BSD behavior to match GNU seems wrong
on the surface as compatibility with FreeBSD is definitely compatibility
with GNU.
If you have looked into these things - cool.
--
-- David ([EMAIL PROTECTED])
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: find -lname and -ilname implemented
On Mon, Feb 25, 2008 at 12:07:44AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Mike Meyer [EMAIL PROTECTED] writes: You fail to understand the complex interplay of politics here. These people do not want to see beyond it. They want to shut you down because you aren't using their beloved Linux. They use stupid excuses to not do things. This is about removing barriers to entry. This isn't about being popular. .. : Um, if FreeBSD has to become GNU in order to win GNU users, what's the : point? Skip the pain, switch to GNU, and get the popularity you want : and the platform you deserve with no delay. Hello? BSDL calling. You left your GPL here and we don't want it. For some of these uses of FreeBSD - I really have to wonder if GNU/kFreeBSD (Debian GNU/kFreeBSD is a port that consists of GNU userland using the GNU C library on top of FreeBSD's kernel) isn't a better choice. http://www.debian.org/ports/kfreebsd-gnu/ One can keep their kernel changes private IP without worry. I doubt most companies would claim they have IP that needs protecting in their GNU userland changes. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modular type GENERIC?
On Sun, Feb 24, 2008 at 07:26:04PM +0900, Adrian Chadd wrote: I was just wondering why we're not shipping a GENERIC type configuration that simply loads the modules at startup, rather than a statically linked kernel. I thought that was a large part of the push for the modular framework in years past. .. http://people.freebsd.org/~adrian/loader.conf As you've shown the magic is in the loader.conf. I don't know a good way to handle this other than attempt to load every module (like Microsoft NT installer does) - and hope the probe of a driver that doesn't claim a device doesn't leave that device in a bad state. Have you tried putting every module in /boot/kernel into loader.conf in a load statement? -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Thu, Oct 18, 2007 at 02:04:21AM +0400, Yar Tikhiy wrote: On Mon, Oct 15, 2007 at 10:38:26AM -0700, David O'Brien wrote: I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) Just try to installworld FreeBSD/amd64 over a running FreeBSD/i386. ;-) I strongly feel that shouldn't be supported on a live system. So to me it shouldn't be an excuse to put a duplicated copy of /usr/[s]bin into /rescue. It is a delicate thing to get right - and there are easy ways to do it today: Boot from disc1; mount / and /usr; mv /mnt/etc /mnt/etc.hold; rm -rf the bits in bin,sbin,libexec; then run the install.sh from the disc1; mv /mnt/etc /mnt/etc.new ; mv /mnt/etc.hold /mnt/etc -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
On Sat, Oct 13, 2007 at 10:01:39AM +0400, Yar Tikhiy wrote: On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A .. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. But if we take this just a little bit farther then why don't we go back to a static /[s]bin except for the few things one might need LDAP, etc.. for? That is, what's the purpose in continuing to duplicate /[s]bin into /rescue? /rescue should be just enough to reasonably get a system who's shared libs are messed up working again. /stand was a left-over from installation and not intended to be a sysadmins' savor - it just happened to be because we didn't clean up / after the bits were laid down. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. I guess I'm still having trouble understanding why one would need 'ps' to fix a shared libs issue. Now is a reason to keep adding stuff to /rescue. Also why one would be running 'ps -aux', which is the only way I can think of to get more than one screen of output if a system is in trouble. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) Considering how few people are skilled in ed(1) these days, we have little choice but include vi. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse I guess I'm not creative enough in the ways I've screwed up my systems and needed tools from /rescue. 8-) I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin .. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue /rescue wasn't intended to be well orthogonal. /rescue was part of he corner stone of the deal to switch to shared /[s]bin. -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Useful tools missing from /rescue
Yar Tikhiy wrote: I've had to use /rescue recently and felt lack of a few basic tools in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), tail(1), and even tee(1) can be emulated if one has sed(1), but the tools are so tiny and convenient that it's a pity not to have them all handy during hard times. I also don't see the need for pgrep - I think needing that says your system is running multiuser pretty well. Also head and tail - why not just add 'more' as that would give more functionality if you're trying to read a file in /etc to fix something. In addition, there are chflags and chmod in /rescue, but there's no chown in it, so the toolset is a bit incomplete. I don't see the purpose of chown - if you have to fall back to /rescue you're user 'root' - and you're trying to fix enough so you can use standard /*lib /*bin chflags is needed so you can overwrite a file and chmod is needed so you can chmod +x something - those needs are clear. Please don't pestimize the build - unless there is a clear benefit. -- -- David ([EMAIL PROTECTED]) 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Anything weird about size or layout of 'struct thread'?
For a reason I haven't tracked down, this patch results in a panic on
6-STABLE when taking the GENERIC kernel and adding WITNESS, INVARIANTS,
INVARIANT_SUPPORT, MUTEX_DEBUG, KDB, KDB_TRACE, DDB.
Index: sys/proc.h
===
RCS file: /home/ncvs/src/sys/sys/proc.h,v
retrieving revision 1.432.2.11
diff -u -p -u -1 -r1.432.2.11 proc.h
--- sys/proc.h 4 Sep 2007 22:40:40 - 1.432.2.11
+++ sys/proc.h 18 Sep 2007 15:28:11 -
@@ -292,2 +292,3 @@ struct thread {
u_int64_t td_sticks; /* (k) Statclock hits in system mode. */
+ u_int xx_one;
u_int td_uuticks; /* (k) Statclock hits (usr), for UTS. */
The Panic(tm) [both on i386 and amd64]:
Timecounter TSC frequency 2192270208 Hz quality 800
Timecounters tick every 1.000 msec
panic: mutex sched lock not owned at ../../../kern/kern_fork.c:807
KDB: stack backtrace:
kdb_backtrace(c0a3d9d6,c0cd2f40,c0a3c5fc,e6fd2cd0,100,...) at 0xc07641de
= kdb_backtrace+0x2e
panic(c0a3c5fc,c0a3c715,c0a39de4,327,c83be4b3,...) at 0xc0744667 =
panic+0xb7
_mtx_assert(c0cd2c40,9,c0a39de4,327,,...) at 0xc0738ec7 =
_mtx_assert+0x87
fork_exit(c07297f0,c84b5c30,e6fd2d38) at 0xc072804a = fork_exit+0x5a
fork_trampoline() at 0xc099373c = fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe6fd2d6c, ebp = 0 ---
It should not be a dependancies or stale issue - as I rm the kernel
compile directory before config'ing the kernel and I still get the panic.
Ideas?
--
-- David ([EMAIL PROTECTED])
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] automated make -j value
With multi-socket systems becoming more prevalent, and the continued
increase in cores per processors, I thought it would be nice for
'make -j' to gain some automation.
Attached is a patch that makes -j- be the same as
-j `sysctl -n kern.smp.cpus` and -j= be twice that.
I've also thought that maybe just supporting -j- would be better - with
a definition of
num_core = `sysctl -n kern.smp.cpus`
-j = MAX(num_core * 5 / 4, num_core + 1)
the idea being one would want a few more jobs than cores, but not a whole
lot more.
comments? (redirected back to list)
--
-- David ([EMAIL PROTECTED])
Index: main.c
===
RCS file: /home/ncvs/src/usr.bin/make/main.c,v
retrieving revision 1.160
diff -u -p -r1.160 main.c
--- main.c 17 Jul 2006 19:16:12 - 1.160
+++ main.c 14 Dec 2006 02:26:15 -
@@ -456,11 +456,20 @@ rearg:
char *endptr;
forceJobs = TRUE;
+ size_t jLlen = sizeof(jobLimit);
jobLimit = strtol(optarg, endptr, 10);
- if (jobLimit = 0 || *endptr != '\0') {
- warnx(illegal number, -j argument -- %s,
- optarg);
- usage();
+ if ((*optarg == '-' || *optarg == '=')
+ *endptr != '\0') {
+ sysctlbyname(kern.smp.cpus, jobLimit, jLlen,
+ NULL, 0);
+ if (*optarg == '=')
+ jobLimit *= 2;
+ } else {
+ if (jobLimit = 0 || *endptr != '\0') {
+ warnx(illegal number, -j argument -- %s,
+ optarg);
+ usage();
+ }
}
MFLAGS_append(-j, optarg);
break;
Index: make.1
===
RCS file: /home/ncvs/src/usr.bin/make/make.1,v
retrieving revision 1.99
diff -u -p -r1.99 make.1
--- make.1 29 Sep 2006 21:17:10 - 1.99
+++ make.1 14 Dec 2006 04:19:22 -
@@ -218,6 +218,14 @@ may have running at any one time.
Turns compatibility mode off, unless the
.Fl B
flag is also specified.
+The special values
+.It Ar -
+and
+.It Ar =
+causes
+.It Ar max_jobs
+to be set to the value returned from the kern.smp.cpus sysctl and twice
+kern.smp.cpus respectively.
.It Fl k
Continue processing after errors are encountered, but only on those targets
that do not depend on the target whose creation caused the error.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My wish list for 6.1
On Fri, Dec 16, 2005 at 12:42:51AM -0700, Scott Long wrote: SMP laptops are right around the corner, and we should be ready to support SMP out-of-the-box. Already here - Alienware Aurora m7700 Athlon X2 dual-core. http://www.alienware.com/product_detail_pages/Aurora_m7700/aurora-m_features.aspx?SysCode=PC-LT-AURORA-M-7700SubCode=SKU-DEFAULT -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot
On Mon, Jun 06, 2005 at 12:02:33AM +0400, Slawa Olhovchenkov wrote: On Fri, Jun 03, 2005 at 09:14:26PM -0600, Scott Long wrote: All, The long anticipated and much feared 6.0 code freeze is about to begin! I'll cut to the chase: June 10 - Feature freeze + code slush ^^^ July 10 - RELENG_6 branch August 1 - RELENG_6_0 branch August 15 - 6.0-RELEASE Nice time for compat5x? Yes, it will be there. -- -- David ([EMAIL PROTECTED]) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp driver not 64 bit?
On Tue, Nov 30, 2004 at 03:42:55PM -0500, David Gilbert wrote: I just heard back from some people still onsite. The ISP driver booted with everything the same except hw.physmem=2g works. It's a memory issue. Try hw.physmem=4g. It should be the 4GB boundary, not 2GB boundary that is causing you trouble. -- -- David([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Sat, Nov 13, 2004 at 12:03:34AM +0100, Bernd Walter wrote: I often missed features in FreeBSD ash that Solaris /bin/sh had, such as using ^ sign as an | alternative (in germany one often has to search the | key on bad configured terminals, which was not uncommon in field service). That actually isn't a Solaris'ism -- '^' was used as the pipe character in Ken Thompson's Version 4 shell, before '|' was decided on. http://www.in-ulm.de/~mascheck/bourne/v4/ -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re; tcsh is not csh
On Fri, Nov 12, 2004 at 09:20:28AM -0600, Kevin Lyons wrote: FreeBSD - does not work (they knew better and renamed tcsh csh rather than just calling a spade a spade, some commit bit vandal got a hair to rename parts of the world for the sake of mankind.) That would be me. 1. Why don't you ask about this on the tcsh mailing lists? 2. OR why don't you send me a patch that fixes the bug? 3. OR why don't you test to see if you are running under tcsh and use a different code path: if ( $?tcsh ) then # something that will work with tcsh else # existing code endif -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcsh fix
On Thu, Nov 11, 2004 at 09:55:43PM -0800, Avleen Vig wrote: On Fri, Nov 12, 2004 at 04:11:22AM +0100, Erik Trulsson wrote: Personally I am of the opinion that csh (all versions) should be removed completely from the base system and relegated entirely to the ports system. Other than historical reasons there is not much point in having it in the base system. I strongly disagree. csh and sh should be 'pure' versions. That is to say, no matter what shell is actually being called as sh or csh, it should provide a 100% compatible version, no differences, no upgrades. This is to provide compatibility whn working with multiple versions of Unix. What is a pure 'csh'?? Please answer in detail. Have you ever looked at the source code for 4.3BSD 'csh'? What about 'tcsh' source code? Hint, Christos Zoulas had at CSRG login and was maintaining and enhancing BSD 'csh'. The 4.4BSD 'csh' was Zoulas's work. 'tcsh' is simply the continued evolution of BSD 'csh'. So do you want the original Bill Joy 'csh' from 3BSD?? Do you want the 'csh' that originally appeared in System 3 (or was it V)?? Do you wan the 4.4BSD-Lite2 'csh' (ie, the last from CSRG)?? THERE IS NO STANDARD 'csh'. POSIX doesn't even try to standardize it. 'csh' is an interactive shell, not a programming language. Anyone trying to write portable scripts in 'csh' should know why Csh Programming Considered Harmful http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/ I write many scripts in sh on Solaris, and find they just don't work on Linux because /bin/sh on Linux is really /bin/bash and is not bacwards compatible. I HATE this. This is a totally different story. There is a POSIX 'sh' standard, and bash leaks extensions even when exec'ed as /bin/sh. There is no such thing as pure sh. It you believe otherwise please tell us what you think such a shell would look like and exactly what features should be in it. (Hint: Current standards require /bin/sh to have several features that were not available on early Unix versions.) Then we should follow current standards. Not pretend one shell is another! Again, show me the standard addressing 'csh'. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 03:55:23PM -0400, Daniel Eischen wrote: David also has patches for debugging support at: http://people.freebsd.org/~davidxu/kse/dbg/ Unless David Xu completes full FSF paper work, we can't use his patches. Using them tants us forever in getting stock GDB to support our threading. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! KSE needs more attention
On Sun, Jun 06, 2004 at 01:48:17PM -0700, Marcel Moolenaar wrote: On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: Doug Rabson also has basic TLS support working in perforce. What platforms? My understanding was that new binutils and gcc was needed for sparc64 at a minimum. Yes. It's i386 only and not even close to being complete. In fact, there has been discussions that the thread pointer on i386 needs to change. Whether that's the case or not, it's likely that TLS will complicate matters way too much to for it to ever work in 5.3. It'd be nice to get TLS and debugging in before 5.3-release. Yes. Be aware that there is a serious effort to get GDB 6.x into the tree for 5.3. I just asked cvs@ and core@ to advice about importing gdb 6.1 into src/contrib/gdb6. We need to break this vicious circle of people waiting on each other. This came up before and you were already asked not to import into src/contrib/gdb6 (and what email would be sent to Core if you did). Any GDB imports need to go into src/contrib/gdb/. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Method of compiling boot0
On Fri, Apr 23, 2004 at 03:18:59PM -0600, Ryan Sommers wrote:
I was browsing over the boot0 makefiles and source when I was playing with
some boot sector code of mine and I was wondering why the designers chose
to use objcopy to output a binary file instead of just using the --oformat
option when it's run over the linker.
I converted most i386 boot things to use the linker options. I was
unable to us them on boot2.bin. Rather using them to produce boot2.bin
produced a different file than what is in CVS right now. I didn't have
time to track down why, but if you'd like to analyis this I'd appreciate
it.
Index: i386/boot2/Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/boot2/Makefile,v
retrieving revision 1.55
diff -u -r1.55 Makefile
--- i386/boot2/Makefile 17 Feb 2004 07:13:03 - 1.55
+++ i386/boot2/Makefile 25 Apr 2004 19:53:01 -
@@ -53,7 +53,7 @@
boot1.out: boot1.o
${LD} ${LDFLAGS} -e start -Ttext ${ORG1} -o ${.TARGET} boot1.o
-CLEANFILES+= boot2 boot2.ld boot2.ldr boot2.bin boot2.out boot2.o \
+CLEANFILES+= boot2 boot2.ld boot2.ldr boot2.bin boot2.o \
boot2.s boot2.s.tmp boot2.h sio.o
boot2: boot2.ld
@@ -68,11 +68,8 @@
boot2.ldr:
dd if=/dev/zero of=${.TARGET} bs=276 count=1
-boot2.bin: boot2.out
- objcopy -S -O binary boot2.out ${.TARGET}
-
-boot2.out: ${BTXCRT} boot2.o sio.o
- ${LD} ${LDFLAGS} -Ttext ${ORG2} -o ${.TARGET} ${.ALLSRC}
+boot2.bin: ${BTXCRT} boot2.o sio.o
+ ${LD} ${LDFLAGS} -Ttext ${ORG2} -S --oformat binary -o ${.TARGET} ${.ALLSRC}
boot2.o: boot2.s
--
-- David ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Mon, Mar 15, 2004 at 12:01:16PM -0700, [EMAIL PROTECTED] wrote: Replying to myself, I just tried hacking audio/tclmidi to use and require lang/gcc295, and it does not build with the gcc295 port. There is also the lang/gcc32, lang/gcc31, lang/gcc30 compilers. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Sun, Mar 14, 2004 at 07:55:18PM -0500, David Gilbert wrote: The error on bento comes down to bento not having strstream.h. I have that file as: /usr/include/c++/3.3/backward/strstream.h /usr/include/g++/backward/strstream.h on my -CURRENT (as of a week or two ago) laptop. bento does appear to have /usr/include/c++/3.3/backward/iostream.h ... but not strstream.h. Why? You need to clean out your /usr/include. RCS file: src/contrib/libstdc++/include/backward/strstream.h,v ... revision 1.1.1.2 date: 2004/01/05 21:04:40; author: kan; state: dead; lines: +0 -0 Remove bits which are not part of GCC 3.3.x anymore. try: # make buildworld # mv /usr/include /usr/include.old # make installworld ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 02:41:26PM +0100, Harti Brandt wrote: On Sat, 17 Jan 2004, David O'Brien wrote: DOOn Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: DO No, we should be using the __restrict as coded. But I wonder why DO we can't just use restrict... DO DO Because that would really mess up any user program that used DO 'restrict' as a variable or function name. I think the DO current approach is the best. DO DOSuch code isn't portable to C99, which is still a goal of ours. I like DORU's suggestion, because it is straight C[99] code and not an DOabstraction. I'll do a 'make world' test and see if we'd have trouble DOwith RU's form. What about third party code that reads cdefs.h and is pre-c99? It's perfectly ok to use restrict as a name there. Its also perfectly OK to use 'exp' as a varible, but we've been getting rid of those because they are difficult to deal with. The same is true of older C++ code when new reserved words were added. Sometimes one has to move forward to the modern world. This is all congecture -- can you find one thing in /usr/ports that uses restrict as a symbol? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __restrict__ vs __restrict ?
On Mon, Jan 19, 2004 at 09:20:24PM +0200, Ruslan Ermilov wrote: If we decide now that our kernel should be C99 clean, we should compile it with -std=c99, and replace all `__restrict''s in not headers with C99 `restrict's. $ grep -- -std /sys/conf/* /sys/conf/kern.mk: -fformat-extensions -std=c99 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __restrict__ vs __restrict ?
On Fri, Jan 16, 2004 at 08:03:05PM -0800, Tim Kientzle wrote: No, we should be using the __restrict as coded. But I wonder why we can't just use restrict... Because that would really mess up any user program that used 'restrict' as a variable or function name. I think the current approach is the best. Such code isn't portable to C99, which is still a goal of ours. I like RU's suggestion, because it is straight C[99] code and not an abstraction. I'll do a 'make world' test and see if we'd have trouble with RU's form. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machines with = 4GB of RAM
On Wed, Dec 17, 2003 at 03:44:49PM -0800, Julian Elischer wrote: Obviously for 4GB you need PAE Or an AMD64 machine. (which don't cost anymore than a machine you'd be worrying aboiut PAE on) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dd to floppies broken?
On Thu, Aug 21, 2003 at 02:39:44PM -0400, Leo Bicknell wrote: In a message written on Thu, Aug 21, 2003 at 02:34:21PM -0400, Brian Reichert wrote: # dd bs=8192 of=/dev/fd0 if=memtest86-2.9/precomp.bin 10+1 records in 10+1 records out 84480 bytes transferred in 3.775199 secs (22378 bytes/sec) fd0 is block buffered. Try: dd bs=18k of=/dev/rfd0c if=memtest86-2.9/precomp.bin Since FreeBSD 4.0 we haven't had block devices. rfd0 is an alias for fd0 now. You also don't need to specify the 'c' partition as the 'fd0' is already the entire media device -- rather than just the FreeBSD portion of it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVIDIA nForece2, again
On Sat, Aug 16, 2003 at 05:16:09PM -0700, Jin Guojun [NCS] wrote: It is a vague problem on term of best performance -- what. NVidia has better memory bandwidth in AMD motherboards. s/better/best/ In terms of IDE performance, the AMD 760MP has the best performance in all chipsets in the world. 760 gives true 200 MB/s I/O IDE throughput, where most other chipsets only gives 100/133 MB/s on both IDE buses with 4 drives. Acutally the nForce chip is based on the AMD 760 chipset. :-) My main machine has just fried a southbridge, and I'm looking for a replacement. From what I can see, in the AMD range, the current best performer is the nVIDIA nForece2. I've read Bill Paul's description of the problems with the onboard NIC, and if I buy one of these boards, I'll certainly swell his mailbox of disgruntled nVIDIA customers. The best nForce2 board is the Asus A7N8X Deluxe (rev 2.0 board). (note this isn't the -X board, which is stripped down). http://usa.asus.com/products/mb/socketa/a7n8x-d/overview.HTM Just one nice thing about this board is it has 2 NIC's. The nVidia proprity one, and an normal 3Com xl(4) one. I've heard that it has an IOAPIC on it, even for single processors. This is true for any nForce (original, 2, or 3) based board. You can probably even run an SMP kernel on it. Based on what I've read, I'd probably be putting a Barton 2600XP+ and 0.5 to 1 GB of DDR memory into it. Don't forget to install DIMM's in pairs. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! Major commits in the tree coming soon
On Thu, May 29, 2003 at 06:42:58PM +0100, Thorsten Futrega wrote: really tired of dealing with O'Brien ^^^ Thanks for getting the spelling right, too many people don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Broadcom 44xx (Re: Rrrrrr.....)
On Tue, May 27, 2003 at 12:08:22PM -0700, Bill Paul wrote: *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx devices are 10/100/1000. The 44xx are 10/100 *ONLY*. Where is the 44xx showing up? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Best serial console server construction method?
On Sun, May 25, 2003 at 09:15:13PM -0700, Will Andrews wrote: serial ports. How am I going to do that cheaply? Well, N-port serial cards (where N is = 4) cost a few hundred dollars from everywhere I could see (granted, they're niche items and are accordingly priced). I've eBay'ed both a Comtrol RocketPort PCI 8-port for $26 and a 16-port for $28. Non-Digi used devices can be had pretty cheaply. two 4-port USB hubs and get 8 single-port serial adapters. So far as I can tell, the total cost would be approximately: 8 x USB-RS232 DB9 Male @ $8/ea = $64 Where did you find these so cheap? They are $30-$40 at Fry's. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc iussue or ... ?
On Fri, Apr 11, 2003 at 09:41:26PM -0500, Loren James Rittle wrote: In article [EMAIL PROTECTED] you write: The problem is very simple. I mantain a unix/linux port of a UO emulator which works really fine natively under FreeBSD. Thank you for this report. Please consider this question: What versions of g++/binutils were used on the various platforms? Please know this: There is a per-platform and per-binutils version influence on mapping of program data/BSS to ELF section. g++ 3.3 with recent binutils on FreeBSD *will* allocate data as you saw on debian 3.0 (with a compiler version you didn't report). Created with g++ 3.3 (prerelease) with binutils 2.13.2.1: ; size lonewolf textdata bss dec hex filename 1792215 49768 2185059223692575169851f lonewolf ; ls -l lonewolf -rwxr-xr-x 1 rittle wheel 1992568 Apr 11 20:18 lonewolf* Hi Loren, Are you setup to easily try this with your g++ 3.3 binary + stock system binutils? It looks like this is due to the fact BSD's don't define either ASM_OUTPUT_BSS or ASM_OUTPUT_ALIGNED_BSS. From cp/decl.c: #if ! defined (ASM_OUTPUT_BSS) ! defined (ASM_OUTPUT_ALIGNED_BSS) /* Tell the back-end to use or not use .common as appropriate. If we say -fconserve-space, we want this to save .data space, at the expense of wrong semantics. If we say -fno-conserve-space, we want this to produce errors about redefs; to do this we force variables into the data segment. */ DECL_COMMON (tem) = flag_conserve_space || ! TREE_PUBLIC (tem); #endif I'm not sure we should change FreeBSD to do something that purposfully produces wrong semantics. From your test it sounds like either GCC 3.3 or Binutils 2.13.2.1 changes things for us. I haven't updated FreeBSD to 2.13.2.1 as the changes from 2.13.2 don't really change any of the FreeBSD architectures. The behavior change is probably due to improved g++ utilization of ELF features, or your FreeBSD-related bug fixes in 3.3. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sendmail: how to get the named of FreeBSD4.7 standards compliant?
On Fri, Jan 10, 2003 at 10:48:46PM +0100, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2003-01-10 11:32:22 -0800: To: Roman Neuhauser [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] you sent me a copy again, please, don't do it. 1. I don't want one, I'll read your message on the list. Then make this clear -- YOU don't provide a Reply-to: or Followup-to:. So Terry (and myself) aren't to blame. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Fri, Oct 04, 2002 at 12:44:30PM -0700, Julian Elischer wrote: No, it is established principal tha the importer of new features has the responsibility to make older subsystems work. So when is a KSE person going to fix the libc_r and releng4 binaries problem?? That certainly is old functionality that is broken. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Spark 5.
On Thu, Sep 26, 2002 at 03:17:24AM +0100, Mark Valentine wrote: For FreeBSD you'd want an Ultra 1 at least - 13w3.com has a 170MHz model Nope. We don't support the U1 -- neither the Ethernet controller or the SCSI controller. So you can't boot from any device. An Ultra 1e (Enterprise) is moderately usable as it has HME Ethernet, which we do support so you can at least use the machine diskless. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Wed, Sep 11, 2002 at 10:56:48AM -0700, Kris Kennaway wrote:
+. elif ${CPUTYPE} == athlon || ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
Can you think of a situtation where the athlon/athlon-xp capabilities
would need to be tested? i.e. what would they be used for?
I do not quite understand the question. Are you asking if there are any
differences between athlon and athlon-xp? Or are you maybe asking if
there are any differences between athlon-4, athlon-xp, and athlon-mp?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 06:08:23PM -0700, Maxime Henrion wrote:
Forgot that one. Here is an updated patch. I'm quite sure that on the
Intel side, only the pentium 4 have sse2, but I don't know if any AMD
chip supports it yet. The attached patch only adds it for p4's.
Athlon-{X,M}P support SSE[1]. AMD x86-64 will be the first AMD processor
to support SSE2.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 01:30:26PM -0700, Kris Kennaway wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
I'd like to commit these Athlon changes. I find this much easier to
understand.
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.18
diff -u -r1.18 bsd.cpu.mk
--- bsd.cpu.mk 7 Sep 2002 01:26:10 - 1.18
+++ bsd.cpu.mk 8 Sep 2002 23:25:51 -
@@ -42,16 +42,8 @@
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == athlon-mp
-_CPUCFLAGS = -march=athlon-mp
-. elif ${CPUTYPE} == athlon-xp
-_CPUCFLAGS = -march=athlon-xp
-. elif ${CPUTYPE} == athlon-4
-_CPUCFLAGS = -march=athlon-4
-. elif ${CPUTYPE} == athlon-tbird
-_CPUCFLAGS = -march=athlon-tbird
-. elif ${CPUTYPE} == athlon
-_CPUCFLAGS = -march=athlon
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
+athlon-4 || ${CPUTYPE} == athlon
+_CPUCFLAGS = -march=${CPUTYPE}
. elif ${CPUTYPE} == k6-3
_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
@@ -105,16 +97,10 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == athlon-mp
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-xp
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-4
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-tbird
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
+athlon-4
+MACHINE_CPU = athlon-xp k7 3dnow see mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon || ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-3
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: More dynamic KVA_SPACE
On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote: The original claims for the tape-out on the x86-64 from AMD so that this could happen were September 2001, with sample units 1Q2002. The AMD schedule slipped. LOL! This slippage is *NOTHING* compared to Merced/IA-64. When I was at HP in the summer of _1997_, Merced was going to come out by end of the year. Hum... a slippage of how many years??? I'd say Intel takes the cake for vapor CPU's. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rcorder cleanup from NetBSD
On Sun, Jul 14, 2002 at 02:39:36AM -0700, Alfred Perlstein wrote: NetBSD has cleaned up sbin/rcorder quite a bit, and chance someone feels up to integrating thier changes? When did they do this? I sznced us up just a few weeks ago. If I were to do it, would I need to 'cvs import' or simply commit the changes? How about letting me do it as I've done it in the past. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NFS server benchmarks vs. OpenBSD, NetBSD?
On Fri, Jun 21, 2002 at 09:57:55AM -0400, Matt Simerson wrote: FreeBSD has very solid NFS code in addition to being a very robust, versatile, and downright fun operating system. It's very easy to do everything I want to with FreeBSD. It's NFS is missing locking support but it's very fast and works very well with FreeBSD and Mac OS X clients. I haven't used it with anything else. Actually Matt Jacob has some NFS testsuites that makes FreeBSD servers blow chunks. Solaris still is the most robust NFS server of the general purpose UNIXes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: raidframe
On Wed, May 29, 2002 at 02:18:40PM -0500, Brandon D. Valentine wrote: If you really want to play with RAIDframe I'd guess you'll have a much easier time of it under NetBSD, where it is included with the operating system. Getting it working under FreeBSD could be a lot of fun and you might learn a lot, but I don't see it being a terribly useful exercise otherwise. I get the impression that most of us are quite happy with vinum and would not desire that FreeBSD bloat the kernel by including two software RAID frameworks. Then again, I speak for noone by myself. You quite speak for yourself. I've seen the FreeBSD community more split 50%-50% in their love-hate of Vinum. Many of us still use ccd(4) because Vinum did not meet our needs. Scott Long had just about ported RAIDframe to FreeBSD, when the bits got lost in a disk crash. So the rumor goes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding diffs to commit-mail on the fly
On Sat, Jun 01, 2002 at 04:17:54AM +0300, Giorgos Keramidas wrote: The idea was resting at the back of my mind, and tonight I hacked this Perl script that seems to mostly do what I want, when I pipe a single There's is also the `cvsmail' port that does that. :0 bf * ^Sender:.*owner-(freebsd-)?cvs-(committers|all)@.*FreeBSD.ORG | cvsmail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Fri, May 31, 2002 at 11:46:03PM -0500, Dan Nelson wrote: Automake avoids the issue entirely by simply listing the dependencies itself, so envuidgid: envuidgid.o $(CC) $(LDFLAGS) -o $@ $^ becomes $(CC) $(LDFLAGS) -o $@ envuidgid.o This is not always possible. If you have a VPATH, then you need make(1) to expand $^ to the full path it used to find the dependancy. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Improving GNU make compatibility in BSD make (+ patch)
On Thu, May 30, 2002 at 07:42:28PM -0700, Jos Backus wrote: The GNU make info file says: `$^' The names of all the prerequisites, with spaces between them. For prerequisites which are archive members, only the member named is used (*note Archives::). A target has only one prerequisite on each other file it depends on, no matter how many times each file is listed as a prerequisite. So if you list a prerequisite more than once for a target, the value of `$^' contains just one copy of the name. I tried to add support for this a while back, but never got it working right. Nor did Will who worked on our make file a while. I'll have to see if your patch does everything $^ should do. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: improved unifdef(1)
On Fri, Apr 26, 2002 at 04:58:32PM +0100, Mark Murray wrote: If anyone is interested I'd appreciate some testing, and it would be nice to get it committed eventually. Ooooh! :-) Yes please! I'll look at this. Please restore the CSRG ID's and Copyright along with other changes we usually don't do to original form before committing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: read a file from a driver
On Wed, Apr 03, 2002 at 10:44:17AM -0500, John Baldwin wrote: Or load the firmware using kldload or from the loader using a type string similar to the way we do MFS root filesystems. Or similar to the ISP (Qlogic SCSI) firmware. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: D-Link device ste tx underrun
On Sat, Mar 23, 2002 at 02:16:21PM -0800, Lucky Green wrote: Hi there, I just installed a new D-Link DFE-550TX NIC on my machine running FreeBSD 4.5-RELEASE-p2. I am seeing the following errors in the log file: Mar 23 15:01:05 pakastelohi /kernel: ste0: transmission error: 90 Mar 23 15:01:05 pakastelohi /kernel: ste0: tx underrun, increasing tx start threshold to 60 bytes Mar 23 18:40:17 pakastelohi /kernel: ste0: transmission error: 90 Mar 23 18:40:17 pakastelohi /kernel: ste0: tx underrun, increasing tx start threshold to 120 bytes A Google search showed that at least one other person has reported what looks like the same problem, but I have been unable to locate a cause or fix. Suggestions are appreciated. Why do you think this is a problem vs. just a diagnostic? This not unusual. This really should be in the FAQ. http://groups.google.com/groups?q=freebsd+ste+%22tx+underrun%22hl=ense lm=3BCAF3D8.70B95C82%40gmx.netrnum=1 Please ensure URL's are not wrapped by your MTA. In this case, there are 'watchdog timeouts'. Those are bad. But, you have not stated you are getting them. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Working with CVS and FreeBSD?
On Sun, Mar 17, 2002 at 07:05:13PM -0800, George V. Neville-Neil wrote: Hi Folks, I'm about to try and do some work on some kernel code in FreeBSD and I'm thinking about ways to track my changes. I'm currently mirroring the CVS repository with CVSup (i.e. CVS mode not checkout mode) and am thinking of making a branch in my local repository. Is this how the rest of you work or do you import the kernel (or whatever code you're working on) into your own local repository with import? Both. To just make your own branch see the CVSup FAQ at http://www.polstra.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: booting from extended slice
On Mon, Mar 18, 2002 at 09:44:07PM -0500, Brian T . Schellenberger wrote: What good will it do you if do boot it? FreeBSD doesn't support UFS in extended partitions anyway. Yes it does. Why do you say it doesn't? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 01:37:39PM +0100, Jan Stocker wrote: A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a There is no need to cause developers to go thru several ABI changes such that they cannot get their other FreeBSD development done. With GCC 3.1 a number of ABI changes will happen. Port has less patches. If you look at /usr/src/contrib/gcc/contrib/freebsd.h and /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things have to be modified because we support dual ELF/a.out [still]. This may be changed too for 5.0 shouldnt it? Why? I don't see how you justfied removing the functionality and I don't see how it is causing you any problems being there. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 04:54:59PM -0500, Kenneth Culver wrote: At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Rather than offer $0.02, send the patch. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 05:26:37PM -0500, Kenneth Culver wrote: At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out ... Rather than offer $0.02, send the patch. Well, I was just asking if it is necessary, I'd make a patch if there was interest. My mail was asking if there is interest. We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is zero reason for subjecting users to this ABI change for what would be gained. If you want to do something productive, submit patches that Bmake GCC 3.1 (which move us to Dwarf2 unwinding as a product). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote: 2) Bug is in os delivered gcc but not in port gcc. a) port has more or less patches / os gcc has been modified -- Didn't someone told they are the same? Port has less patches. If you look at /usr/src/contrib/gcc/contrib/freebsd.h and /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things have to be modified because we support dual ELF/a.out [still]. b) other options were set at compile time -- Why dont change to the same in the port? I am willing to -- the gcc295 port isn't used very much now AFAIK. However, it will probably be once 5-CURRENT moves to a newer version. The FSF GCC people had settings in the i386/freebsd.h file I did not agree with, but it would have been too much pain to change them in the FSF 2.95 release branch. I am willing (and may have to anyway), make the port more agree with the FreeBSD system compiler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Thu, Mar 14, 2002 at 01:20:51PM -0500, Alexander Kabaev wrote: b) other options were set at compile time -- Why dont change to the same in the port? Leads it to a broken world? If the only difference is the lost of binary compatibility, i would say, ok... do it now and we'll need to compile or ports... Pretty much each and every C++ binary and shared library will have to be recompiled. Massive binary compatibility breakage is not an option for -STABLE, one can hope. No it is not an option for -STABLE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 10:24:20PM +0100, Martin Blapp wrote: We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? cd /usr/ports/devel/stlport make install cd work/STL*/test/eh add -O to gcc-freebsd.mk gmake -f gcc-freebsd.mk clean gmake -f gcc-freebsd.mk and see what happens ... This is not a small, [relatively] simple example program. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 12:15:34PM -0800, Ed Hall wrote: Exception-handling is broken with -O in -stable, and has been for years. FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds to implement exceptions, so when the GCC folks broke that path, it was never fixed. There are supposedly patches floating around that fix the problem, but they either didn't work as advertised or the ball got dropped. We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: bin/34744: Add -a (same as -PpR) flag to cp(1)
On Sat, Mar 09, 2002 at 04:49:09AM +, Dima Dorfman wrote: Jordan DeLong [EMAIL PROTECTED] wrote: Number: 34744 Category: bin Synopsis: Add -a (same as -PpR) flag to cp(1) Description: some other cp(1) implementations (such as GNU cp) provide a -a flag, which just means -PpR. somewhat useful. Does anybody on -hackers object to this change? I find myself using `cp -RPp` frequently and would welcome this shortcut. If nobody I just see no need in this shortcut. When I added -v (yes, not POSUCKS), there was no other way to get that functionality. Here someone is just too lazy to type on extra keystroke (-P is the default). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Swapping performance
On Thu, Mar 07, 2002 at 08:09:06AM -0600, GB Clark wrote: I've tested it with : cc -O6 -o malloc_test malloc_test.c That -O6 does not look right from here. Do we support anything over -O2? And how about some source for malloc_test.c? The fact of running something at -O6 started some bells ringing. Not us, but GCC does not support anything over -O3. -O4 and above are treated as -O3. I *really* wish people would have a clue with with in the hell they think they are achieving with -Obignum. Not all optimizations are appropriate in all cases. And given this level of optimization and the fact that the linux box is probably a different version of GCC, I wonder how much of this could be due to the compiler. Please rerun your tests with '/usr/bin/time -l' on FreeBSD and however you achieve the same on Linux. P.S. are you sure you are swapping, vs. paging? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Swapping performance
On Thu, Mar 07, 2002 at 11:41:28AM +, Mike Silbersack wrote: In any case, we can't make any useful comparisons until Dimitar posts the source to his test program. Dimitar, post the source for the test program! Does your MTA strip attachments? - I 1 no description[text/plain, 7bit, US-ASCII, 1.2K] A 2 malloc_test.c [applica/octet-stre, base64, 0.7K] [-- Attachment #1 --] [-- Type: text/plain, Encoding: 7bit, Size: 1.2K --] Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit [-- Attachment #2: malloc_test.c --] [-- Type: application/octet-stream, Encoding: base64, Size: 0.7K --] Content-Type: application/octet-stream; name=malloc_test.c Content-Disposition: attachment; filename=malloc_test.c Content-Transfer-Encoding: base64 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 01:19:31AM -0600, Mike Meyer wrote: David O'Brien [EMAIL PROTECTED] types: On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Jeremiahs wrote: I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. As the original author of the PR, I'll point out that this chagne does *not* add rules. It clarifies the wording of a rule that's already there. If the rule is wrong, it should be removed. The reason I didn't post if for wider review was because it wasn't changing any rules. My thanks to Giorgos for moving this PR towards closure. I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 11:35:52PM -0700, M. Warner Losh wrote:
: I was giving one. :-)
: style(9) documents the practices of /sys. Thus we should not arbitaryly
: add rules w/o them being backed up in code.
I believe that sys/pccard, sys/dev/{pccard,pcic,pccbb,cardbus} tends
to follow this rule. If you are looking for examples.
Older code than PCCARD. :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 11:37:42AM +0100, Poul-Henning Kamp wrote: Ahh, but here you hit one of my pet-peeves. I hate assignments inside conditionals. I prefer the above written as: It does not matter. Style(9) does not [intentionally] avoid PHK's pet peeves. It documents the style used by the CSRG with some modernizations. All this IMO does not matter as much as showing actual code examples from /sys. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
On Wed, Mar 06, 2002 at 06:19:14AM -0600, D J Hawkey Jr wrote: They should have left well enough alone, and advocated languages that were/are OOPL by concept as well as design. *sigh* IF you say that then you really aren't thinking at at all. Why isn't Eiffel (one of those pure OOL's) used more? BECAUSE IT ISN'T C. Got it? No one is willing to learn a new language. How much bitching do we get because CVSup is written in Modula-3? It is a type-safer language than C. It has some OO-like constructs and its threading model and GUI lib allow JDP to quickly create a really nice application. But all the benefits of Modula-3 are lost on the I only do C crowd that is demanding CVSup be rewritten. Thus to repeat -- C++ was built on C SO IT WOULD BE ACCEPTED. I'll go away now. thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 02:37:45PM -0500, Garance A Drosihn wrote: At 7:49 PM +0100 3/6/02, Poul-Henning Kamp wrote: Garance A Drosihn writes: In one message, At 12:52 AM -0800 3/6/02, David O'Brien wrote: I don't think it is clarifying a rule. I think it is in fact adding a rule. You are extrapolating too much I think. All the rule is trying to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. If we change boolean to integer, then the proposed rule will not prevent if (!strcmp(a,b)) , because strcmp() *does* return an integer value. Or am I missing something here? Right, and since the integer is well defined, if (!strcmp(a, b)) is perfectly understandable so what is the problem ? Well, that's my question. David's comment implies that it is not good to do '!strcmp()', and I was wondering why it is not good... Implies??? I thought I was quite explicit: to prevent is if (!strcmp(a,b)) which when read is extremely wrong of that is actually happening. ! is pronounced NOT. When read if not string compare a with b then do X, is the opposite of the the logic of the expression does. Which is if string compare a with b is equal then do X. [if (strcmp(a,b) == 0)] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Thu, Mar 07, 2002 at 07:14:49AM +0100, Poul-Henning Kamp wrote: Guys, strcmp() has been defined that way for almost 30 years, get used to it, and don't demand obfuscation of every other if() in the kernel to try to hide the fact... We are not trying to hide anything. Style(9) says to don't do that, so we shouldn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. +For pointers, use: +.Bd -literal +if (p != NULL) +.Ed +.Pp +not +.PP +.Bd -literal +if (!p) +.Ed +.Pp +For other values, use: .Bd -literal if (*p == '\e0') .Ed .Pp not .Bd -literal -if (!*p) +if (*p) +.Ed +.Pp +unless the value is a boolean. In that case, use: +.Bd -literal +if (p) +.Ed +.Pp +and +.Bd -literal +if (!p) Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Myson drivers for 4.x
On Wed, Feb 27, 2002 at 02:52:41AM -0500, Matthew N. Dodd wrote: On Tue, 26 Feb 2002, Julian Elischer wrote: I have been speaking with the author. he is adding a BSD copyright. also he says we can KNFify (style(9)ify?) as it doesn't have to remain compatible with anything else. It might be nice if it could be folded into the driver it was copied from, if thats still possible. It would be nice, but other than admitting he has cards of this type; Bill Paul refused to answer if he is planning on supporting them. I think we need to commit the `my' driver as-is. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing.
On Wed, Mar 06, 2002 at 02:08:07AM +0200, Giorgos Keramidas wrote: On 2002-03-05 15:58, David O'Brien wrote: On Tue, Mar 05, 2002 at 10:13:50PM +0200, Giorgos Keramidas wrote: -Don't use '!' for tests unless it's a boolean, e.g. use +For tests, always compare the value to the appropriate 0 instead of +checking it directly, unless the value is a boolean. ... Please show examples from /sys that back up this change. To state this explicitly, I think a significant number of /sys files should be following it. Actually I was asking for comments, but anyways. I was giving one. :-) style(9) documents the practices of /sys. Thus we should not arbitaryly add rules w/o them being backed up in code. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: please remove blank line
On Wed, Mar 06, 2002 at 12:41:20PM +0800, David Xu wrote: could anyone remove a blank line in /sys/kern/kern_sysctl.c ? in FreeBSD 4.5 STABLE, it's at line 151, function sysctl_ctx_init(). Uh.. why? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AWK/perl hacker needed to assist the Sparc64 port
On Tue, Feb 12, 2002 at 04:44:49PM -0800, Alfred Perlstein wrote: IS IT IN THE LEAST BIT POSSIBLE TO STAY ON TOPIC ON FREEBSD LISTS ANYMORE??? And we wonder why so many do not bother with them any more. Please refrain from acting like a turd towards someone doing a bit of advocacy as well as offering some real world advice to us about something we may be considering. Please refrain from hijacking a thread in which I am trying to accomplish a single, quick goal. You are more than free to start a *new* tread (w/new subject) to accomplish your advocacy. If I got the gest of your emails in this thread, you are considering replacing /bin/sh. Alfred that has come up multiple times ever year since I can remember. It is one of our oldest bikesheads. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AWK/perl hacker needed to assist the Sparc64 port
On Tue, Feb 12, 2002 at 08:59:31PM -0500, Sergey Babkin wrote: Because in order to use (ie, run it), one needs to have perl on the machine. (1) We do not yet have Perl bootstrapped on the sparc64 platform. (2) Perl is harder to bootstrap than sh, sed, or BWK awk. Hm, that's a bit surprizing. How about getting perl4 bootstrapped first ? It should be way easier than perl5. If you've looked at the perl build, I am not sure why that is surprising. Perl4 is no longer bmaked in our source tree. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: to users of threads (GDB support)
On Mon, Feb 11, 2002 at 11:55:03PM -0500, Daniel Eischen wrote: But the latest and greatest GDB (which should be a port) isn't /usr/ports/devel/gdb51 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
AWK/perl hacker needed to assist the Sparc64 port
In rev 1.20 of sys/kern/vnode_if.pl Eivind converted this from a Bourne+AWK script into a Perl script. Well that just makes porting to new architectures VERY difficult as the boot strapping of Perl 5 is quite difficult. A shell hacker could really help out the FreeBSD/sparc64 porting effort by updating vnode_if.pl rev 1.19 to have all the functionality the perl version has today. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: AWK/perl hacker needed to assist the Sparc64 port
On Tue, Feb 12, 2002 at 01:07:16PM -0800, Terry Lambert wrote: Alfred Perlstein wrote: : : A shell hacker could really help out the FreeBSD/sparc64 : : porting effort by updating vnode_if.pl rev 1.19 to have all : : the functionality the perl version has today. vnode_if.pl is a perl script. I don't understand the request for a shell hacker in the first place. Because in order to use (ie, run it), one needs to have perl on the machine. (1) We do not yet have Perl bootstrapped on the sparc64 platform. (2) Perl is harder to bootstrap than sh, sed, or BWK awk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lsof and listening processes on 4.5
On Mon, Feb 11, 2002 at 04:18:35PM -0800, David O'Brien wrote:
We did with 4.5. Unfortunately the latest LSOF changed how it is packed.
I spent an hour trying to update the port but got pulled away before I
was done. Grab the latest tarball and build by hand.
Here is my patch in progress if someone wants to finish it for me.
Index: Makefile
===
RCS file: /home/ncvs/ports/sysutils/lsof/Makefile,v
retrieving revision 1.99
diff -u -r1.99 Makefile
--- Makefile9 Nov 2001 16:16:31 - 1.99
+++ Makefile12 Feb 2002 00:18:54 -
@@ -7,7 +7,7 @@
#
PORTNAME= lsof
-PORTVERSION= 4.60
+PORTVERSION= 4.61
CATEGORIES=sysutils
MASTER_SITES= ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/ \
ftp://vic.cc.purdue.edu/pub/tools/unix/lsof/NEW/ \
@@ -21,12 +21,12 @@
#DISTNAME= ${PORTNAME}_4.59B.freebsd
#FIXUP_RELEASE=yes
.if !defined(FIXUP_RELEASE)
-DISTNAME= ${PORTNAME}_${PORTVERSION}_W
+DISTNAME= ${PORTNAME}_${PORTVERSION}
.endif
MAINTAINER=[EMAIL PROTECTED]
-WRKSRC=${WRKDIR}/${SRCBALL_NAME}
+WRKSRC=${WRKDIR}/${DISTNAME}/${DISTNAME}_src
HAS_CONFIGURE= yes
CONFIGURE_SCRIPT= Configure
CONFIGURE_ARGS=-n freebsd
@@ -35,28 +35,6 @@
MAN8= lsof.8
SRCBALL_NAME= ${DISTNAME:S/_W$//}
-
-.if !defined(FIXUP_RELEASE)
-post-extract:
- @( cd ${WRKDIR} ; \
- EXPMD5=`${GREP} MD5 README.${SRCBALL_NAME} | ${SED} 's/^[ ]*//'` ; \
- CALCMD5=`${MD5} ${SRCBALL_NAME}.tar` ; \
- if [ $${EXPMD5}X != $${CALCMD5}X ]; then \
- ${ECHO} Expected and calculated MD5 signatures don't agree. ; \
- ${ECHO} ($$EXPMD5 != $$CALCMD5) ; \
- exit 1 ; \
- fi ; \
- ${EXTRACT_CMD} ${EXTRACT_BEFORE_ARGS:S/z//} ${SRCBALL_NAME}.tar \
- ${EXTRACT_AFTER_ARGS} \
- )
- @( cd ${WRKSRC} ; ${ECHO} y | ./Inventory || exit 1 )
-.endif
-
-#pre-patch:
-# @${ECHO_MSG} === Applying distribution patches for ${PKGNAME}
-# @${SED} -e s|^--- d|--- dialects/freebsd/d| \
-# ${DISTDIR}/freebsd_3.0_patch ${WRKDIR}/p
-# ${PATCH} ${PATCH_DIST_ARGS} ${WRKDIR}/p
do-install:
${INSTALL} ${COPY} ${STRIP} -o ${BINOWN} -m 2755 -g kmem ${WRKSRC}/lsof
${PREFIX}/sbin
Index: distinfo
===
RCS file: /home/ncvs/ports/sysutils/lsof/distinfo,v
retrieving revision 1.77
diff -u -r1.77 distinfo
--- distinfo9 Nov 2001 16:16:31 - 1.77
+++ distinfo12 Feb 2002 00:18:54 -
@@ -1 +1 @@
-MD5 (lsof_4.60_W.tar.gz) = a0f8cebc465ae26ad81e519264272175
+MD5 (lsof_4.61.tar.gz) = 583398bc99d265c5a64dbc30e99305cb
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
