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: 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: 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"
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]"
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]"
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
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: 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: 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: 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 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: 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: 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.143&r2=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: 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]"
Will FreeBSD ever see native IPv6 ??
So is FreeBSD *EVER* going to see native IPv6 ??
I attended a talk by a group of Intrusion Detection researchers. They
were basing their research on FreeBSD because they needed divert
sockets and found FreeBSD worked perfectly for this in this respect.
However, once they needed IPv6 and IPsec guess what happened??? They
moved to Linux and now have such a time investment in their custom kernel
hacks FreeBSD will never be an option for them again.
NetBSD and OpenBSD get more and more coverage from IPv6/IPsec
capabilities every day. FreeBSD has lost considerable ground if we want
to be a platform of choice for network and security researchers.
Now ever LSOF has IPv6 support for NetBSD and OpenBSD...
- Forwarded message from Vic Abell -
Date: Wed, 21 Jul 1999 10:53:51 -0500
Subject: 64 bit lsof for Solaris 7; IPv6 support for {Net,Open}BSD
IPv6 Support for {Net,Open}BSD
==
..snip..
An lsof 4.45 pre-release distribution of the NetBSD and OpenBSD
sources with the IPv6 updates is available at:
..snip..
- End forwarded message -
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
> This one raised a number of eyebrows and a few people asked you to hold > on to legacy support for a single release. It's a reasonable request, > given the obscure error message one gets for providing the previously > supported syntax: > > newsyslog: error in config file; bad permissions: > /var/log/exim/mainlog exim.mail 640 7 *24Z I will be adding the ":" syntax to -STABLE before 3.3-R, and it will accept both ":" and ".". It was a one character fix in -CURRENT and I don't see any reason to ugly the code with supporting both syntaxes in -CURRENT. The change will be documented in 4.0-R's release notes. If people don't read that, then they will be in trouble in many other ways. Anyway, it has been only ":" in -CURRENT for a while now, and I haven't received any death threats, so people must not be tripping over this on a daily basis. :-) The problem with printing out warnings is ``newsyslog'' is usually run from cron(8), and anything printed out will often not be seen as I am of the opinion many do not read root's mail. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
> COMPATIBILITY > Previous versions of the chown utility used the dot (``.'') > character to distinguish the group name. Begining with FreeBSD > 4.0, this has been changed to be a colon (``:'') character so that > user and group names may contain the dot character. Hum... I think I should change this text slightly. I should not refer to chown(8) so strongly. It's on my list now. :-) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
On Tue, Jul 27, 1999 at 05:25:23PM +0200, Sheldon Hearn wrote: > > Hi Brian, To paraphase Bill Paul: G that's part of my last name. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: newsyslog owner.group -> owner:group
> A better patch would check to see if the text to the right of the '.'
> is a valid group... However, the above will still parse
>
> fred.jones:fred.jones
>
> in the most desirable way, so I suppose the validity checking is
> overkill.
This is what I plan to commit (w/in minutes):
-if ((group = strchr(q, ':')) != NULL) {
+if ((group = strchr(q, ':')) != NULL ||
+(group = strrchr(q, '.')) != NULL) {
It the becomes [almost totally] non-ambigitous (since the separator is
required) and allows "david.obrien.staff". In my mind more people use
dots in usernames than group names. Anyay, it is documented to use :,
and I am just trying to be "liberal in what is accepted" (w/o
obfuscating the code).
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
> http://www.freebsd.org/~des/software/grep-0.7.tar.gz> Before importing, it must display a version number of 1.0 (or drop the version number). This is not Linux where everything is version 0.xy. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
$ uname -a
$ grep foo NONEXIST
Segmentation fault (core dumped)
$ gdb /usr/bin/grep grep.core
...
(no debugging symbols found)...
Core was generated by `grep'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libc.so.3...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x280a8538 in ftello (fp=0x0)
at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76
76 if (fp->_seek == NULL) {
(gdb) where
#0 0x280a8538 in ftello (fp=0x0)
at /FBSD/src/lib/libc/../libc/stdio/ftell.c:76
#1 0x280a84e1 in ftell (fp=0x0) at /FBSD/src/lib/libc/../libc/stdio/ftell.c:59
#2 0x80490b7 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#3 0x80499f1 in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#4 0x804968b in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
#5 0x8048d3d in free () at /FBSD/src/lib/libc/../libc/stdlib/malloc.c:1089
(gdb)
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
> A more general concern is whether Henry Spencer's regex routines > -- at least in our present "alpha-quality" version -- are up to I spoke to Henry at USENIX and he said he has a new version of his regex library. I have added it to my plate of things to update. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> I've had some interesting comments from David Bushong, motivating for > inclusion of his Magdir candidate on PR 12554. He makes a strong case > for a bloated file(1) Magdir. The only thing we're battling with is a > filename for his submission. My advice would be to submit his PR to Chris Demtrito(sp?), file's maintainer. Then import NetBSD's file (Chris is a NetBSD guy). Thus we see what Chris calls it, and we stay in sync with the offical distribution. ...something on my list of things to update in src/contrib/ over the summer. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing ld.so in 3.2?
> I think u must read following: > http://www.freebsd.org/releases/3.2R/errata.html There is nothing on the 3.2 errata that addresses this. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Will FreeBSD ever see native IPv6 ??
> various researchers and early-adopters, all of which can go to the > KAME site and grab the patches to 3.2-stable if they want to play now, > today. If we haven't done a good enough job of making that clear and > are suffering from defections to other *BSDs because of this, then we > just need to get the word out better. :-) Since KAME is probably closest to unified, I think we need to point people to the "offical" IPv6 patch set. The problem is the IPv6 wanting user does not know which of the available stacks to go with. It is easy to feel one would have to download 3 different stacks and experiement with all to determine which one works well. Lets help these people out. How about adding this to 3.3's RELEASE notes and a pointer from our website? (maybe also http://www.freebsd.org/handbook/install.html) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> > > My advice would be to submit his PR to Chris Demtrito(sp?), file's > > You may want to verify this. I'm pretty sure that Christos Zoulas > (another NetBSD guy) maintains file(1): chris...@zoulas.com. My major Duh!! If Christos sees this thread, my apologies. There is no excuse for me not checking the source to make sure I was accurate before opening my mouth. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: file(1) Magdir candidate: wintendo
> > My major Duh!! If Christos sees this thread, my apologies. > > David, I was trying to be helpful; sorry if my msg came across wrong. ^ Not in the least. I was being stupid and that's all. I'm certainly not mad about anything. (1) I don't like it when people just toss "facts" off the top of their head w/o making sure they are facts. I went against this. (2) people often get my name wrong, which is slightly irritating, and here I did it to someone else. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Initio INI-* SCSI card support
Has anybody taken a look at the FreeBSD driver source at http://www.initio.com/source.zip for the INI-* cards? Is this something we should import into -CURRENT? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Please review: rc file changes
> I've had a week-end away from a keyboard to think about this. The only > reason we have to use case statements for case-insensitive variable > testing is because sh(1) doesn't offer any upper/lower case handling Also so that common settings can be added. Besides "yes" and "no" there could be other forms of wanting and not wanting. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3.2-RELEASE and netscape problem.
> It breaks because compat22 is installing _everything_ in > /usr/lib/compat/aout. We've reproduced this locally - compat22 is > hosed. Will fix this. I followed the lead of the "unoffical" compat22 which was built from libs on Hub. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
a.out lib placment (was: 3.2-RELEASE and netscape problem.)
> It breaks because compat22 is installing _everything_ in
> /usr/lib/compat/aout. We've reproduced this locally - compat22 is
> hosed.
I *knew* this was going to bite us in the ass. I brought it up at E-day
time... and was ignored.
Some body please decide where bits should live. *IF* you upgrade from
2.2.x to 3.x, your /usr/lib a.out libs are moved to /usr/lib/aout, *AND*
your /usr/lib/compat a.out libs are moved to /usr/lib/compat/aout. Fine.
NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
install into /usr/lib/compat/. Thus we have no consistancy. So compat22
is no more broken than ``make aout-to-elf''.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: a.out lib placment (was: 3.2-RELEASE and netscape problem.)
> > NOW if you look at the compat2{0,1} bits we shipped with 3.2, they
> > install into /usr/lib/compat/. Thus we have no consistancy. So compat22
> > is no more broken than ``make aout-to-elf''.
>
> I think you are abusing compat22 by adding the aout (legacy) stuff.
> Why not just build a legacy library bundle and install it where it
> belongs.
Huh? I don't follow you here.
What non-a.out stuff should be in compat22? The everything in the
compat22 I made is a.out.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> Just noticed David's commits into HEAD... ;-) > David, you have forgotten to put ld.so into compat22 No I didn't (and I wish people would stop accusing me of forgetting stuff!). For some reason, I am now having problems with remove CVS commits. :-( -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> Problem > --- > > Fact: ld.so (rtld-aout) is built as part of ``legacy-build'' and then > installed as part of ``legacy-install''. In order to build it, > one needs to pass -DWANT_AOUT to the ``make world'' process. > This will build a.out libraries and legacy boot as well. Ok, I'm going to blow up here... People PLEASE drop this topic. It is being addressed -- maybe not as fast as people like, but it is being addressed. I really, REALLY don't understand why all of a sudden this problem is comming up when the compat22 distribution was made a while ago. Also, I install the compat* distributions and forget about them. I've never had ld.so problems. I really don't understand why so many people want to reinstall the compatXX files with every ``make world''. But I guess we do support such functionality, so someone should use it. So are people deleting ld.so before evey ``make world''. I also never make the a.out libs. Remember any a.out libs made with "WANT_AOUT" will be 3.2 libs with the same functional contents as the ELF ones. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> And would it be possible to MFC this stuff After it is tested in -CURRENT first. > and add an 3.2-ERRATA entry... Why? The compat22 distribution on the FTP site has ld.so in it, as wil the CDROM. Did you install 3.2 on the very first day? -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> > Why? The compat22 distribution on the FTP site has ld.so in it, as wil > > the CDROM. Did you install 3.2 on the very first day? > > Just about. Did a make release for local internal use. Is there a > slightly newer CVS tag other than RELENG_3_2_0_RELEASE that gets us all we > need to build completely functional COMPATxx's? I'm not sure if the RELENG_3_2_0_RELEASE was slid forward for my fix. Since doing so would allow someone to build what was on the 3.2-RELEASE CDROM, maybe we should ask Jordan if the tag shouldn't be slid forward for src/lib/compat/compat22/Makefile. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: 3c589d and FreeBSD 3.1
> I compiled the ISC DHCP client seperately, since the port was marked > broken in 3.1, but I see it's been fixed in 3.2. You should not have needed to do that -- see /sbin/dhclient. (ie, the ISC DHCP client has been part of the base system since just before 3.1-RELEASE). Enjoy! -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: getopt.c in gnu/*/*
> Is there any reason to have getopt.c replicated in so many different > programs: > cvs, grep, gzip, patch, ptx, sort, tar > and maybe a few others that I missed... for src/contrib/ we try not to dink too much with the code. Otherwise the maintance can get heavy. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> > Why? The compat22 distribution on the FTP site has ld.so in it, as wil > > the CDROM. Did you install 3.2 on the very first day? > > Just about. Did a make release for local internal use. Is there a > slightly newer CVS tag other than RELENG_3_2_0_RELEASE that gets us all we > need to build completely functional COMPATxx's? Jordan just slid the "RELENG_3_2_0_RELEASE" forward to include my changes to compat22 that match the hand-hacked versions on the CDROM/FTP site. One should now be able to build a duplicate 3.2-RELEASE. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: [ALERT] a.out support is broken in 3.2-STABLE and 4.0-CURRENT
> > Jordan just slid the "RELENG_3_2_0_RELEASE" forward to include my changes > > to compat22 that match the hand-hacked versions on the CDROM/FTP site. > > > > One should now be able to build a duplicate 3.2-RELEASE. > > Did I see a commit to 3.2's ERRATA.TXT that needs to be backed out now? Nope. The errata commit I made was that the compat20 and compat21 distributions unpack into the wrong place. A mostly independent issue from the lack of ld.so in the 1st rolling of 3.2-RELEASE. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: getopt.c in gnu/*/*
> All of the programs listed, except cvs, were not under contrib. They will be on the next upgrade. :-) > I was thinking of factoring out gnugetopt into a libgnugetopt under > contrib It would be better to create src/gnu/lib/libgnugetopt/Makefile and point ".PATH:" to the newest src file we have in the tree. If some package gets updated and there is a newer GNUgetopt(), then we change the ".PATH:". JDP suggested this is a cleaner way than extracting part of a GNU package, and I have to agree with him. (I am considering something simular with libiberty and libbfd) -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
libss
Does anybody know what /usr/src/lib/libss/ is? There isn't a manpage for it, and viewing the source I still can't figure out what it is other than it came from MIT (Athena). -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: inetd/tcpd...changing hosts.allow...plus a documentation issue
> on another note, LIBWRAP_INTERNAL looks like it must be defined for > internal services to be wrapped, yet it is not defined during freebsd's > compile -- only LIBWRAP is. yet freebsd's inetd man page says that internal > services may be wrapped. since it is not currently so by default, perhaps There was a bug in LIBWRAP_INTERNAL, that has now been fixed in -CURRENT. If you are using 3.2-STABLE, ask Sheldon Hearn when it will be merged from -CURRENT. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: tcpdump(1) additions.
On Tue, Jun 29, 1999 at 06:54:06PM -0400, Bill Fumerola wrote: > Unless there is strong feelings against it, I'd like to commit the smb > patches (as seen on www.samba.org) Cool! I've been meaning to do this for quite some time. HOWEVER, please reference this PGP signed email (I'll send you the full copy) in the commit message: Sender: tri...@samba.anu.edu.au From: Andrew Tridgell To: obr...@nuxi.com In-reply-to: <19990106131559.a18...@dragon.nuxi.com> (obr...@nuxi.com) Subject: Re: tcpdump patches copyright References: <19990106131559.a18...@dragon.nuxi.com> Message-Id: <19990106234704z12605236-3608+4...@samba.anu.edu.au> Date: Thu, 7 Jan 1999 10:47:03 +1100 yes, you are welcome to use those files under the tcpdump copyright. ..snip.. Note that the Tcpdump patches from www.samba.org are under the GPL. Andrew Tridgell also warned: I should warn you though that there are some security issues with my tcpdump-smb patches. It is possible for a malicious user to put packets on the wire that will cause a buffer overflow in the SMB parser in that code. That could lead to a root exploit. I just haven't got around to fixing it yet. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.bin/ftp Makefile fetch.c ftp.1 ftp.c ftp_var.h main.c util.c
> ... compared to the sources as of today. This gives minimal semantic > difference from the way it worked before the change (which was that if > FTP_PASSIVE_MODE existed, ftp used passive mode). I have to agree with Eivind, I know of people in my lab that have FTP_PASSIVE_MODE defined to nosense values since that is all that was required before. Now what are these poor souls to do when they upgrade to 3.3-R and their environment stops working -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.bin/ftp Makefile fetch.c ftp.1 ftp.c ftp_var.h main.c util.c
On Fri, Jul 02, 1999 at 05:15:14PM -0700, Mike Smith wrote: > > I have to agree with Eivind, I know of people in my lab that have > > FTP_PASSIVE_MODE defined to nosense values since that is all that was > > required before. Now what are these poor souls to do when they upgrade > > to 3.3-R and their environment stops working > > Unless they were dumb enough to set it to "no", the "right" fix would > have it keep working. So that makes three of us that believe the check should be agaist "no" rather than "yes". -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
> The Xircom ethernet driver needs to read/write PCCARD attribute memory from > its probe routine, in order to identify the type of card and to beat ... > then making crdread() and crdwrite() (in /sys/pccard/pccard.c) > non-static and calling them directly from the driver code would be an > easy workaround. Since no one has repsonded to this querry, I will be un-staticizing these so they will be available to drivers. -- -- David(obr...@nuxi.com -or- obr...@freebsd.org) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
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-7700&SubCode=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]"
[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: fixing flex definitions?
On Mon, Mar 05, 2001 at 02:55:22PM -0800, John Baldwin wrote: > I'm guessing YY_PROTO is like __P() so it can be "compilable with a K&R Old > Testament compiler." Yes. And in this case, the output of lex *must* be portable to K&R. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
doFS.sh newfs parameters for install floppy
Does anyone know of *any* problems with committing this diff?
It changes the % free space from the 8% default to 0.
Index: doFS.sh
===
RCS file: /home/ncvs/src/release/scripts/doFS.sh,v
retrieving revision 1.24.2.3
diff -u -r1.24.2.3 doFS.sh
--- doFS.sh 2001/01/14 08:24:48 1.24.2.3
+++ doFS.sh 2001/03/09 00:23:53
@@ -55,7 +58,7 @@
vnconfig -s labels -c /dev/r${VNDEVICE} ${FSIMG}
disklabel -Brw /dev/r${VNDEVICE} ${FSLABEL}
- newfs -i ${FSINODE} -T ${FSLABEL} -o space /dev/r${VNDEVICE}c
+ newfs -i ${FSINODE} -T ${FSLABEL} -o space -m 0 /dev/r${VNDEVICE}c
mount /dev/${VNDEVICE}c ${MNT}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Thu, Mar 08, 2001 at 06:13:07PM -0800, Alex Zepeda wrote: > However, there *ARE* some of us who aren't intimate with your fxp > problems. The problem does exist. I have a board that the `fxp' driver splits this out for: fxp0: warning: unsupported PHY, type = 17, addr = 2 fxp1: warning: unsupported PHY, type = 17, addr = 2 > You've got a valid problem. Go away. "You've got a valid problem, go away." huh?? His points are very valid about maintenance of the `fxp' driver. His views on how to make something happen are what is a little out of touch. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Sat, Mar 10, 2001 at 10:30:08AM -0600, Peter Seebach wrote: > For that matter, is the fxp still the most-recommended driver on Alpha? It *never* has been the recommended driver on FreeBSD/Alpha. The fxp driver has had issues on Alpha for a long time. Andrew will fix something with it, then it breaks again for some, etc... DG has an Alpha, but I don't think he has ever turned it on. He certainly has never done and Alpha-specific fxp fixes that I am aware of. The `guaranteed to work on Alpha driver' is anything supported by the `de' driver, as that is what the built-in NIC is on older Alpha's so OS's have no choice but deal with them. After that, I would say any of the `xl' 3Com cards. Bill Paul tested his just about all his drivers on an Alpha when developing them. The really nice thing about the `xl' 3Com cards is they don't have the alignment requirements of most of the other NICs in existence. Thus you can get really good performance on the Alpha. Behind the `xl' 3Com cards, would be any DEC 21143 based NIC which is supported by Bill Paul's `dc' driver. The nice thing about `de' and `dc' cards is SRM recognizes them. > I got the impression there were some alignment issues that > might be cheaper to solve on i386 than Alpha. Both `xl' and `fxp' cards do not have strict alignment issues (which makes them very nice and reduces a memory copy). The problems with the `fxp' cards is simply how its driver works on the Alpha. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution: Sendmail 8.11.3 on FreeBSD 4.2
On Tue, Mar 13, 2001 at 06:26:29PM +0300, Zaitsev Serg wrote: > I have upgrade the Sendmail 8.11.3 on FreeBSD 4.2. > But on FreeBSD 4.2 I got trouble with /usr/libexec/mail.local . > Filling up /var/spool/mqueue a lot of files. > /var/mail/user was empty. > Mail stopped. > > chmod u+s /usr/libexec/mail.local > > Now mail works again. Perhaps you should read the documentation we supplied on this issue. bash$ cat /usr/src/UPDATING Updating Information for FreeBSD STABLE users This file is maintained by [EMAIL PROTECTED] Please send new entries directly to him. See end of file for further details. A reverse chronology since 4.0 was released is included, followed by the common items quick how-tos, followed by entries for versions of -current prior to 4.0 Release. ..snip.. 20001020: ** WARNING ** Sendmail has been updated. ** WARNING ** o mail.local(8) is no longer installed as a set-user-id binary. ..snip.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Mon, Mar 12, 2001 at 10:34:32PM -0800, Gordon Tetlow wrote: > On Mon, 12 Mar 2001, Dan Phoenix wrote: > > > CC="gcc -O6 -fomit-frame-pointer" OPTIM="-O2 -DBUFFERED_LOGS" > > > > could some c guru tell me if this would be bad to use to an apache > > optimization? I need to compile apache on my own not with ports > > looking at makefile > > in apache13 in ports collection i see these optimization flags. > > along with --mmap-static module. > > > > > > can you use both -06 and -02 for optmization at the same time? > > -fomit-frame-pointer as well? > > -O6 and -O2 do seem a bit contradictory. I'm guessing it just uses -O6. > -fomit-frame-pointer is not enabled per the -O flags so that does do > something, but it does make it rather difficult to track down problems > without a frame pointer. _ _ __/\_____ (_) __ _ | |__ __/\__ \/ / __| | | / _` | | '_ \\/ /_ _\ \__ \ | | | (_| | | | | | /_ _\ \/ |___/ |_| \__, | |_| |_| \/ |___/ Where did you even get the idea "-O6" did *_ANYTHING_*?? Don't people ever read the documentation anymore. 1. The highest -O setting GCC accepts is "-O3". 2. The base, system C compiler is known to produce bad code with -O2. We have been proclaiming this since as long as I have been with the Project. > I probably qualify for the latter Optimizations are good and all, but > I look at it this way: It's a mission critical webserver, I don't want it > crashing. As a result, we compile ours with nothing higher that -O2 and no > unusual optimizations. Sure, it might be a bit slower than it could have > been, Do people ever actually test this? Or is there just the assumption that the more "optimizations" on the `cc' command line is a Great Thing(tm)? People do realize that for some code, -O2 is much worse than -O? Also for much code there is no difference in performance. Rather than do what you "think" will give the best results, why not actually benchmark it? > but we don't have to worry about chasing down compiler bugs that > interact strangly with the webserver code. Also, I think anything higher > than -O2 actually produces a larger binary (it inlines functions whenever > possible). 1. You need to use -O if you don't want to chase bugs 2. It is -O2 and above (ie, _includes_ -O2) that produces a larger binary. See -Os if you want smaller. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Tue, Mar 13, 2001 at 10:08:00AM -0800, Gordon Tetlow wrote: > Actually, we did. Of course, our production stuff is still compiled with > gcc 2.7.2.1. I think. Whatever the standard system compiler for > FreeBSD-3.2 is. And that was at a time when the world was still compiled > with -O2, wasn't it? The world has _NEVER_ been compiled at -O2 by default, nor has it ever been officially recommended. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution: Sendmail 8.11.3 on FreeBSD 4.2
On Wed, Mar 14, 2001 at 11:57:51AM +1000, Greg Black wrote: > $ uname -rs > FreeBSD 4.2-RELEASE > $ cat /usr/src/UPDATING > cat: /usr/src/UPDATING: No such file or directory > > Perhaps the documentation should be installed more thoroughly. If one is building and installing a new [latest] sendmail, they have /usr/src populated. Or was the new Sendmail compiled manually and installed using sources downloaded manually from ftp.sendmail.org? If so, then this whole discussion should be on a sendmail.org list, not FreeBSD one. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Solution: Sendmail 8.11.3 on FreeBSD 4.2
On Wed, Mar 14, 2001 at 12:27:02PM +1000, Greg Black wrote: > This is the point where we disagree. The information in this > file is in fact of interest to somebody who does a fresh install > from CD as the simple way to upgrade from an earlier release. Huh??? If you do a fresh install from CD, you will get a sendmail+sendmail.cf+mail.local that are all in sync and setup properly. This thread (unless I majorly misunderstood it), is about someone taking a 4.x-RELEASE system and upgrading the sendmail to the latest 4-STABLE version. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Wed, Mar 14, 2001 at 01:19:31AM -0800, Alex Zepeda wrote: > However, even the pgcc web page describes -O2 as safe. I won't even to there... > Yes, scanning thru the ML leads me to believe some of these optimizations > are pretty much untested. Which is kinda funny, since the ia32 bits are > the most used ones or so it seems. Not untested -- but you should go grab a graduate text on compiler optimizations and familiarize yourself with the complexity of the problem. If hello_world.c showed a problem with an optimization, I guarantee it would be fixed. The current test case of holding up the entire FreeBSD kernel as showing an optimization problem doesn't cut it. If you care to trim it down to a single module showing the problem -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 09:09:15AM -0800, Alfred Perlstein wrote: > how many times does windows crash because of poorly written drivers > rather than flaws in the core OS? (*) ALL the time. Microsoft has given the UC-Davis security and formal verification lab a multi-year grant to look at this problem. (the approach being researched is "model checking") -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 11:37:34AM -0800, Alfred Perlstein wrote: > > ALL the time. Microsoft has given the UC-Davis security and formal > > verification lab a multi-year grant to look at this problem. > > (the approach being researched is "model checking") > > How does one get the forms for these sort of grants? :) Write white paper, submit to M$. Or network at conference, have M$ friend tell you a proposal would be meet open arms. The typical University/research way of getting [commercial] grants. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 02:41:53PM -0800, Kent Stewart wrote: > With 2000 and above, your system will check for non-digitally signed > dll's and etc. Being signed has nothing to do with correctly working. The project I was speaking about wanted to be able to do something about you buying that wonderful new video card, or ATA-100 card -- receving the vendor's device driver and finding it decreases the stability of your system. Windows has a specification and convention of how drivers should be written. How do you know some driver actually follows it? That is the basic problem this grant is researching. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 04:51:14PM -0500, Dennis wrote: > Why would they need to do that? Every time you load a program it updates > the libraries, breaking older programs. Its a philosophical problem. You > dont need a grant to figure it out. You JUST DON'T GET IT [academic research]. And any attempt to explain it to you will obviously be wasted time. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Wed, Mar 14, 2001 at 03:12:41PM -0800, Alex Zepeda wrote: > > Not untested -- but you should go grab a graduate text on compiler > > optimizations and familiarize yourself with the complexity of the problem. > > Care to recommend any starting places. You've piqued my interest. http://www.amazon.com/exec/obidos/ASIN/1558603204/ref=sim_books/107-1570516-8126104 Advanced Compiler Design and Implementation by Steven S. Muchnick (typical graduate text cost of $93.00!) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /bin/ps thing
On Fri, Mar 16, 2001 at 11:04:43AM +, Jordan DeLong wrote: > It seemed that send-pr was just for reporting issues, not for fixing > them also Nope. At the bottom of the send-pr form, is a "How to fix" section. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Sat, Mar 17, 2001 at 10:46:42AM -0800, Alfred Perlstein wrote: > > GCC 2.95.3 was just released. I did notice that there are some bug fixes ... > > in the optimizer, and some various other fixes etc. Considering the > > recent discussion about incorrect code generation due to -O2 and above, I really, really don't think these fixes will help -O2. I need to do more testing with GCC 3.0, but I do have [some] hope. > > are there any plans to import this new release into the FreeBSD source ... > some bugs in the optimizer". David will sync our compiler with > the latest version when he feels that it's ready for FreeBSD. I was going to do it Friday, but the distribution file had yet to make it to any of the mirror sites. It probably has by now. So I'll do it Monday. GCC 2.95.3 will hi 4-STABLE after April 1st. Heck, April 1st might actually be the best day to do it. So if RELENG_4 is unfrozen by then, that's when I'll MFC it. ;) -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Mon, Mar 19, 2001 at 02:54:52PM +0100, Titus von Boxberg wrote: > Since at least aug. 2000 (according to the mailing list > archives) the exception handling in base system g++ is broken > (at least for multithreaded programs) I am not aware of exception handling being broken (more so than in 4.x). Can you point me to a PR, or send me a _small_ sample program? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc and exceptions and frame.c
On Mon, Mar 19, 2001 at 04:32:36PM -0500, Alexander N. Kabaev wrote: > It there any particular reason why you are using gcc295 from ports > instead of FreeBSD stock compiler? I would assume because he has a 3.4 box: $ g++295 -v specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd3.4/2.95.2/specs and the stock compiler there is 2.7.2.3. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Mon, Mar 19, 2001 at 08:12:18PM -0500, Alexander N. Kabaev wrote: > The fix has been posted on the gcc-devel mailing list and Berndt > Schmidt even included it into some of GCC 2.95.3-testXX release. And > that time I decided that my job is done, but apparently Berndt managed > to revert (most likely, by mistake) before release. I think my > relative unrelated changes have been killed as part of the bigger sjlj > exceptions rewrite by Mike Henderson :( From: Bernd Schmidt <[EMAIL PROTECTED]> Subject: 2.95.4 plans Date: Fri, 16 Mar 2001 16:18:03 + (GMT) To: <[EMAIL PROTECTED]> Now that 2.95.3 is out, I'll again accept suggestions what to include in 2.95.4, so please send candidate patches and bug reports. One major item that needs fixing is the sjlj eh problem; the fix for this had to be taken out of the 2.95.3 release since it introduced too many other problems. I would bring up the issue again with Bernd. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Tue, Mar 20, 2001 at 04:31:06PM -0500, Alexander N. Kabaev wrote: > I certainly do not see that happening in FreeBSD 4-STABLE any time > soon. It never will. > FreeBSD-CURRENT might switch to DWARF2 some day, David O'Brien is > the right person to ask about that. It will happen right after I MFC GCC 2.95.3. DWARF2 is required by the IA-64 psABI, and is supported better on the Alpha. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Wed, Mar 21, 2001 at 06:39:47PM +0600, Max Khon wrote:
> Btw, do you have patches that fix sjlj exceptions for 2.95.3?
Can you try these?
Index: except.c
===
RCS file: /cvs/gcc/egcs/gcc/except.c,v
retrieving revision 1.82.4.3
retrieving revision 1.82.4.2
diff -u -r1.82.4.3 -r1.82.4.2
--- except.c2001/02/19 14:01:59 1.82.4.3
+++ except.c2000/12/29 16:18:54 1.82.4.2
@@ -723,21 +723,41 @@
receive_exception_label (handler_label)
rtx handler_label;
{
+ rtx around_label = NULL_RTX;
+
+ if (! flag_new_exceptions || exceptions_via_longjmp)
+{
+ around_label = gen_label_rtx ();
+ emit_jump (around_label);
+ emit_barrier ();
+}
+
emit_label (handler_label);
-#ifdef HAVE_exception_receiver
if (! exceptions_via_longjmp)
-if (HAVE_exception_receiver)
- emit_insn (gen_exception_receiver ());
+{
+#ifdef HAVE_exception_receiver
+ if (HAVE_exception_receiver)
+ emit_insn (gen_exception_receiver ());
+ else
#endif
-
#ifdef HAVE_nonlocal_goto_receiver
- if (! exceptions_via_longjmp)
-if (HAVE_nonlocal_goto_receiver)
- emit_insn (gen_nonlocal_goto_receiver ());
+ if (HAVE_nonlocal_goto_receiver)
+ emit_insn (gen_nonlocal_goto_receiver ());
+ else
#endif
-}
+ { /* Nothing */ }
+}
+ else
+{
+#ifndef DONT_USE_BUILTIN_SETJMP
+ expand_builtin_setjmp_receiver (handler_label);
+#endif
+}
+ if (around_label)
+emit_label (around_label);
+}
struct func_eh_entry
{
@@ -1320,7 +1340,7 @@
start_dynamic_handler ()
{
rtx dhc, dcc;
- rtx x, arg, buf;
+ rtx arg, buf;
int size;
#ifndef DONT_USE_BUILTIN_SETJMP
@@ -1362,18 +1382,17 @@
buf = plus_constant (XEXP (arg, 0), GET_MODE_SIZE (Pmode)*2);
#ifdef DONT_USE_BUILTIN_SETJMP
- x = emit_library_call_value (setjmp_libfunc, NULL_RTX, 1, SImode, 1,
- buf, Pmode);
- /* If we come back here for a catch, transfer control to the handler. */
- jumpif_rtx (x, ehstack.top->entry->exception_handler_label);
-#else
{
-/* A label to continue execution for the no exception case. */
-rtx noex = gen_label_rtx();
-x = expand_builtin_setjmp (buf, NULL_RTX, noex,
- ehstack.top->entry->exception_handler_label);
-emit_label (noex);
+rtx x;
+x = emit_library_call_value (setjmp_libfunc, NULL_RTX, LCT_CONST,
+TYPE_MODE (integer_type_node), 1,
+buf, Pmode);
+/* If we come back here for a catch, transfer control to the handler. */
+jumpif_rtx (x, ehstack.top->entry->exception_handler_label);
}
+#else
+ expand_builtin_setjmp_setup (buf,
+ ehstack.top->entry->exception_handler_label);
#endif
/* We are committed to this, so update the handler chain. */
Index: expr.c
===
RCS file: /cvs/gcc/egcs/gcc/expr.c,v
retrieving revision 1.144.4.9
retrieving revision 1.144.4.8
diff -u -r1.144.4.9 -r1.144.4.8
--- expr.c 2001/02/19 14:02:00 1.144.4.9
+++ expr.c 2001/01/25 14:03:06 1.144.4.8
@@ -192,6 +192,7 @@
static int apply_args_size PROTO((void));
static int apply_result_size PROTO((void));
static rtx result_vector PROTO((int, rtx));
+static rtx expand_builtin_setjmp PROTO((tree, rtx));
static rtx expand_builtin_apply_args PROTO((void));
static rtx expand_builtin_applyPROTO((rtx, rtx, rtx));
static void expand_builtin_return PROTO((rtx));
@@ -8544,44 +8545,29 @@
return tem;
}
-/* __builtin_setjmp is passed a pointer to an array of five words (not
- all will be used on all machines). It operates similarly to the C
- library function of the same name, but is more efficient. Much of
- the code below (and for longjmp) is copied from the handling of
- non-local gotos.
-
- NOTE: This is intended for use by GNAT and the exception handling
- scheme in the compiler and will only work in the method used by
- them. */
+/* Construct the leading half of a __builtin_setjmp call. Control will
+ return to RECEIVER_LABEL. This is used directly by sjlj exception
+ handling code. */
-rtx
-expand_builtin_setjmp (buf_addr, target, first_label, next_label)
+void
+expand_builtin_setjmp_setup (buf_addr, receiver_label)
rtx buf_addr;
- rtx target;
- rtx first_label, next_label;
+ rtx receiver_label;
{
- rtx lab1 = gen_label_rtx ();
enum machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
- enum machine_mode value_mode;
rtx stack_save;
- value_mode = TYPE_MODE (integer_type_node);
-
#ifdef POINTERS_EXTEND_UNSIGNED
buf_addr = convert_memory_address (Pmode, buf_addr);
#endif
buf_addr = force_reg (Pmode, buf_addr);
- if (target == 0 || GET_CODE (target) != REG
- || REGNO (target) < FIRST_PSEUDO_REGISTER)
-target = gen_reg_rtx (val
Re: GCC Upgrade?
On Wed, Mar 21, 2001 at 01:35:30PM -0500, Alexander N. Kabaev wrote: > This patch will work. According to Berndt Schimidt, there are some problems > with it on HP/UX and that was the main reason why it was backed out. That I knew, but I never saw the details (I may have missed them in the GCC mailing lists). Nor why they couldn't add conditional code to do the old way on hpux, and fixed sjlj exceptions everywhere else. Since this bug greatly affects both FreeBSD and OpenBSD (Linux does not use sjlj), we BSD's are the greatest consumer of the sjlj code. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
First let me say to anyone reading the email I am replying to:
_ _ ___ __ _ _ _
| _ \ ___| \ | |/ _ \_ _|__| | ___ | |_| |__ (_)___
| | | |/ _ \ | \| | | | || | / _` |/ _ \ | __| '_ \| / __|
| |_| | (_) | | |\ | |_| || || (_| | (_) | | |_| | | | \__ \
|/ \___/ |_| \_|\___/ |_| \__,_|\___/ \__|_| |_|_|___/
On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote:
> # cd /usr/src
> # make buildkernel KERNEL=
> # cd /usr/src; make buildworld
> # make installworld
> # make installkernel
> # mergemaster
> # reboot
The order or "make buildworld" and "make buildkernel" are 100% totally
BACKWARDS.
Lets explain why: There are times when the kernel source is changed to
use constructs of newer compiler/assembler/linker tools. Thus the kernel
will not build with an older set of tools. The what "make buildkernel"
does is use the tools (ie, those built from the most up to date sources)
that are built during "make buildworld" to compile a new kernel. Thus
"make buildworld" must PROCEED "make buildkernel".
Second, the install order above is not the conservative, careful
approach. One should issue "make installkernel && reboot" after the
"make buildkernel" to ensure the new kernel works sufficiently well. If
not, one can always fall back to ``kernel.old''. Since there is no
``world.old''; after one does the "make installworld" backup tapes are
the only way of taking the system back to its previous state.
--
-- David ([EMAIL PROTECTED])
GNU is Not Unix / Linux Is Not UniX
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
On Thu, Mar 22, 2001 at 12:51:00PM -0700, Matt Simerson wrote: > Actually, they aren't backwards. You've gone and snipped the parts of my > original message that show that the commands are being executed at the same > time. I read you message twice and came away with the same idea. You should write more clearly. > Maybe I'm understanding you incorrectly here but according to what you just > said, a "make buildkernel" will fail unless you have a set of > compiler/assembler/linker tools in /usr/obj that were built from the make > buildworld process. This is inaccurate at best and I suspect it's just plain > wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make > buildkernel KERNEL=" and it will succeed and build a happy little > fully functionaly kernel. I've done this hundreds of times with success. The ability to do a `make buildkernel' with an empty /usr/obj is a new feature. But back to your misunderstanding. What part about "if the kernel source is changed to use language features not supported by the existing installed tools, you cannot build a kernel with them" do you not understand?? You obviously was not active when 4.x upgraded Binutils from 2.9.1 to 2.10.0 and the many of the asm bits were changed at the same time to remove work arounds and bogusness done to satisfy Binutils 2.9.1. > > Second, the install order above is not the conservative, careful > > approach. One should issue "make installkernel && reboot" after the > > "make buildkernel" to ensure the new kernel works > > sufficiently well. > > Maybe that's _YOUR_ method for installing but it's not necessarily the best > one. Kernel's are not guaranteed to be backwards compatible and I've > installed a shiny new kernel that worked just fine and allowed my machine to > come up single user but because of some rude change in /etc/rc, ipfw, or any > of a number of places the machine couldn't make it to multi-user and allow > me to get back in (via the network). That you're doing this remotely is your problem. Ask any of the developers living on -CURRENT where often one wants to back out of a newly compiled world. The method I gave is the most sure and careful way. That you don't have consoles on your machines so you could do this properly doesn't mean what I posted isn't the safest and should be followed unless has special needs. > Success at building and installing the kernel, world, AND running > mergemaster gives me a reasonably good chance that when I issue the reboot, > it'll come up nice and happy. I'm happy for you. But you have major flaws in your method where problems can bite you hard. As I said, I want users to know and use the safest method. I've seen enough email from users that were all confused about the right steps -- often getting confused from posts such as yours where you [hopefully] understand the consequences of your method and can deal with them. Many do not want to or cannot. > Second, if I'm going through the bother of compiling a buildworld it's > because I want the latest version of world on my system. Want != ability. I want a latest version of 5-CURRENT on my laptop, but CardBus is broken right now, so I am living with a Dec world. Such is life. > If there are some problems with the new kernel, I'm not going to revert > back to world.old. I'll fix whatever is screwed up with kernel and > proceed. Oh! Want a job as a kernel hacker then? I'd like to have my CardBus working again (in current). Also my AHA-2930u2 on a K6-2 machine... -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GCC Upgrade?
On Wed, Mar 21, 2001 at 01:35:30PM -0500, Alexander N. Kabaev wrote: > This patch will work. According to Berndt Schimidt, there are some problems > with it on HP/UX and that was the main reason why it was backed out. I never saw > any ill effects on i386 with this patch though, while good efects include: > > a) working sjlj exceptions > b) ability to compile QT2 with exceptions enabled and with -O2 flag without > consuming ~400M memory for abnormal call egdes in GCC flow optimization pass. It has been committed now and will be MFC'ed to stable after tax day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 06:31:44PM +0100, Luigi Rizzo wrote: > 2) even if you have hardware with an "fxp" on board, adding a second >supported card is cheap and easy -- nothing like having to put >in a second video card; Many, many U1-form-factor systems have two fxp on-board NICs. No room to add third (and fourth) supported NIC. K THNX. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Sat, Mar 24, 2001 at 03:11:54PM -0500, Dennis wrote: > Most drivers are written without full docs. Feh. *EVERY* wpaul written Ethernet driver was written _with_ having the full docs. wpaul will not write a driver otherwise. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problems with: /usr/src/lib/libc
On Sun, Mar 25, 2001 at 08:09:31PM +0200, Jochen Kaiser wrote: > why are all my .o files in /usr/obj/usr/src/lib/libc and not in > /usr/src/lib/libc ? Because that is how our make framework works w/in /usr/src See the readme in /usr/share/mk/ > I changed syscalls.master, created new syscall, made headers in > /usr/src/include and tried to make the libs via > make install in /usr/src/lib/libc. ... > How May I fix it? cd /usr/src/lib/libc make cleandir make cleandir # do NOT do a `make obj' make depend make make install If that does not work, then rm -rf /usr/obj/* and try again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vinum stripe size (was: tuning a VERY heavily (30.0) loaded server)
On Tue, Mar 27, 2001 at 05:16:53PM +0930, Greg Lehey wrote: > No, there's no requirement for it to be a prime number. The only > problem is that with 32 MB cylinder groups and a power of two stripe > size and subdisk count, you end up with all the superblocks on one > subdisk, The change I made to newfs to make "-c 22" the default, removes this power-of-two issue. Correct? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc 2.95.3 and STL
On Wed, Mar 28, 2001 at 10:26:56AM +0200, Arjan Knepper wrote: > What is preffered the build-in STL (/usr/include/g++) or STLport? The one bundled with (and matches) G++ of course. Unless you find your code just will not work with it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
