Re: Multiple hpet messages during boot
In message: 4c911214.7060...@freebsd.org Alexander Motin m...@freebsd.org writes: : Joel Dahl wrote: : I noticed this during boot (HEAD from yesterday): : : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : : Is it really necessary to print this 8 times? : : HPET at present chipsets may use up to 8 IRQs. Driver registers filter : interrupt handlers for them. Interrupt handling code prints this. : : If you boot with verbose, you may see that some network cards prints : alike things for the number of supported MSI/MSI-X interrupts. Is there any reason not to toss all FILTER messages behind bootverbose? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DHCP server in base
In message: 4c91100c.5060...@freebsd.org Doug Barton do...@freebsd.org writes: : Most of the code is there anyway, and it isn't evolving as fast as : BIND. : : That is actually a more rational argument, even if I don't agree with : it. FWIW, part of the reason that I don't agree with it is that at : some point, hopefully in the near future, we will want to include the : DHCPv6 client in the mix somewhere; and when we do the code base is : not going to be as stable as we have enjoyed so far with the v4 : dhclient. True, but that still won't change the dynamic that adding a dhcp server is easy give we have most of one already in the tree. Adding v6 support likely will mean a certain amount of code churn, I'll grant you that. But the code/api churn that's happening is within a single program, making it much easier to MFC as necessary to keep up. : This is analogous: we : have good opportunity to integrate into the system, and users benefit : from that integration. : : Given your perspective of wanting more of a complete system in the : base I can certainly see how you would be supportive of this : change. My intent was to make the argument in a general way that this : is the wrong direction to go, and that users would benefit *more* from : a robust modularized system. The fact that the v4 DHCPd might : accidentally be a good candidate for including in the base today : doesn't mean that doing so is the right strategy for the long term. I take a more nuanced view: we have to evaluate each proposed addition to the system on its merits. One of these criteria is long term viability, but others include how useful is it to the users; how much demand will there be; will including it make the project look good?; will not including it make the project look bad?; etc We'd all like to see a more modular base, but until that nut is cracked, we have a balancing act to perform. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Multiple hpet messages during boot
In message: 201009160828.35520@freebsd.org John Baldwin j...@freebsd.org writes: : On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: : I noticed this during boot (HEAD from yesterday): : : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : hpet0: [FILTER] : : Is it really necessary to print this 8 times? : : I'd actually like to remove the interrupt messages that say '[FILTER]' or : '[GIANT]', etc. I think in general they only add clutter. [GIANT] is just public shaming of drivers anyway. It has worked to get them all the major ones locked. Well, except for atkbd and psm... I'd be happy to toss them behind a bootverbose :) Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Multiple hpet messages during boot
In message: 20100917055953.gf1...@pluto.vnode.local
Joel Dahl j...@freebsd.org writes:
: On 16-09-2010 8:28, John Baldwin wrote:
: On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote:
: I noticed this during boot (HEAD from yesterday):
:
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
: hpet0: [FILTER]
:
: Is it really necessary to print this 8 times?
:
: I'd actually like to remove the interrupt messages that say '[FILTER]' or
: '[GIANT]', etc. I think in general they only add clutter.
:
: Definitely agreed. Go for it.
so is there support for the following:
Index: subr_bus.c
===
--- subr_bus.c (revision 212791)
+++ subr_bus.c (working copy)
@@ -3996,9 +3996,11 @@
arg, cookiep);
if (error != 0)
return (error);
+ if (bootverbose == 0)
+ return (0);
if (handler != NULL !(flags INTR_MPSAFE))
device_printf(dev, [GIANT-LOCKED]\n);
- if (bootverbose (flags INTR_MPSAFE))
+ if (flags INTR_MPSAFE)
device_printf(dev, [MPSAFE]\n);
if (filter != NULL) {
if (handler == NULL)
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DHCP server in base
In message: aanlktinkj182=gftdww_0oat6rforjpbxnzmyukce...@mail.gmail.com David DEMELIER demelier.da...@gmail.com writes: : 2010/9/11 Doug Barton do...@freebsd.org: : On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: : : Hi, : : another argument about hostapd :) if have access point we must have : way to assign IP for AP clients. : : To start with, your assumption is wrong. DHCPd is not *actually* a : requirement, although I admit that practically it is. : : Last spring I made firmware based on FreeBSD for router with only 4MB : NOR flash (D-Link DIR-320). : : In this category (micro-miniaturization) you're already in the significant : customization needed area, which means that general arguments about the : base don't apply. : : Since this device is router I must be : able to serve DHCP. And current implementation of dhcpclient, that we : have, is same isc-dhcp, and I replace system dhcpclient with ports : one+dhcpd but with small patch that put basic dhcp utils onto : libdhcp.so. : : Your argument is creative and well thought out, but I personally don't find : it persuasive. Counter arguments that come immediately to mind are: : 1. The DHCP server is not going to benefit any but a small minority of : FreeBSD users. : 2. The software is already available in the ports tree, and adding a : port/package of it really is not an overwhelming burden. : : More generally, the main reason I want to keep more stuff out of the base, : and remove some of the stuff that's in there now, is that it makes : maintenance difficult across FreeBSD branches. We have a general policy that : if we have a major version N of something in a release branch that we don't : upgrade that major version without a really good reason to avoid POLA : surprises for our users. Once again using BIND as an example, this has led : to a really old and past-EOL version of BIND in FreeBSD 6 which I've only : gotten away with because anyone doing serious DNS work nowadays has to : upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want : to repeat it. : : : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: {arch}/conf/DEFAULTS and uart
In message: 20100912170344.ga58...@freebsd.org Alexander Best arun...@freebsd.org writes: : also i noticed that after keywords like device there're two tabs, : whereas after the keyword options there's one space and a : tab. since i don't know, if this was done on purpose i didn't change : it. It is on purpose. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
In message: 4c6c1cfe.6060...@freebsd.org Gabor Kovesdan ga...@freebsd.org writes: : When reply, please remove core@ from CC, let's not bother them with : this, I just wanted to let them know that I'm not neglecting this : issue but if still demanded for a good reason, I'll switch back to : default GNU grep. So making it default turned out well in the end. Sure, there was pain involved (but this is current), but making it default exposed the pain that would otherwise have gone unnoticed. The big hue and cry, while excessive at times, did result in people actually running the profiling tools which pointed to the buffering as the number one thing to fix. That being fixed now, it looks like we can go to the next stage: benchmarking again. Thanks, Gabor and everybody else that contributed, for seeing this through. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
In message: 894c8953-7f2f-486f-8701-a3dff65d7...@kientzle.com Tim Kientzle t...@kientzle.com writes: : : On Aug 15, 2010, at 1:56 AM, Alban Hertroys wrote: : : On 15 Aug 2010, at 3:12, Doug Barton wrote: : : (And before anyone bothers to reply saying Use pkg_info -O for that : I'll save you the trouble. My version is from 10-20% faster. Not sure : why, don't really care.) :) : : : Congrats for beating the performance of a(nother) utility in base, but - regardless of whether you'd use it in that case - doesn't that just indicate that pkg_info could use some performance improvements as well? : : http://libpkg.googlecode.com/ : : This is David Forsyth's GSoC project to build a standard library : for managing the on-disk package database. : : His pkg_info implementation built on this library is in fact : a lot faster than what's currently in the tree. He's starting : to prototype pkg_delete and pkg_add on the new library : but there's still a lot of work to do. heh, maybe he needs to do work on an upgrader too. :) Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
In message: 4c66c0a4.3000...@freebsd.org Gabor Kovesdan ga...@freebsd.org writes: : Yes, I'm sorry for my slow reaction, I got a flu some time ago and : that prevented me from fixing the bugs earlier. I have several fixes : in my working copy, which are being discussed with my : mentor. Probably, today or tomorrow they will be committed. I don't see a huge issue with it being default for a while, so your slowness due to flu is OK, imho. This is -current after all, and bumps in the road are to be expected. Reverting to gnu-grep being default is likely good until you can resolve the issues that you've talked about in other posts. IMHO, it's unlikely additional testing and exposure will, at this time, give you any new information. Once things have been tuned up, problems fixed, etc, it would likely make sense to try this again (with special attention to the issues raised this time, since there's good reason to believe people will try them first thing if the switch is thrown back to default again). I hope you're leaving it in the tree as an option, however, since BSD grep is good enough for many users of grep. They have been using it for years and years without hassle as a port because their grep needs are simple, and performance requirements modest. For these folks, license is the deciding factor. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718210154.ga94...@laptop.levsha.me Mykola Dzham i...@levsha.me writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem Try setting both TARGET and TARGET_ARCH. TARGET_ARCH was depricated in favor of TARGET in FreeBSD 8.0. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718210154.ga94...@laptop.levsha.me Mykola Dzham i...@levsha.me writes: : Hi! : Attemt to make jail with different target arch on tinderbox (i386 jail : on amd64 host) exits with error: : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : Last lines from log: : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : install: freebsd.cf: No such file or directory : *** Error code 71 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : *** Error code 1 : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : Full build and distribution logs avaliable on : http://levsha.me/tmp/20100718/world.txt (20M) : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : Reverting r209510 fixes this problem It works for me. on an amd64 box: setenv TARGET=i386 make buildworld make installworld DESTDIR=/tmp/mumble make distribution DESTDIR=/tmp/mumble Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Can't make distribution TARGET_ARCH=... after r209510
In message: 20100718.171610.338707487962422543@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 20100718210154.ga94...@laptop.levsha.me : Mykola Dzham i...@levsha.me writes: : : Hi! : : Attemt to make jail with different target arch on tinderbox (i386 jail : : on amd64 host) exits with error: : : : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : : : Last lines from log: : : : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : : install: freebsd.cf: No such file or directory : : *** Error code 71 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : : *** Error code 1 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : : : Full build and distribution logs avaliable on : : http://levsha.me/tmp/20100718/world.txt (20M) : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : : : Reverting r209510 fixes this problem : : It works for me. : : on an amd64 box: : setenv TARGET=i386 : make buildworld : make installworld DESTDIR=/tmp/mumble : make distribution DESTDIR=/tmp/mumble To which I forgot to add: Please send me the exact sequence of commands that fails, as well as the uname of the host. I'd like to try to track this down... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: 86r5jqdz9w@ds4.des.no
Dag-Erling Smørgrav d...@des.no writes:
: M. Warner Losh i...@bsdimp.com writes:
: + /*
: +* Close the PID file, and all other open descriptors.
: +* Inherit std{in,out,err} only.
: +*/
: + cfg.close_pidfile();
: + ::closefrom(3);
:
: Actually, closefrom() is sufficient, since the only resource held by the
: pidfile that would persist across execve() is the file descriptor (and
: hence the lock).
I went ahead and used pidfile_close in this context because that's
what's recommended in the man page. I know it is likely redundant,
but I thought better safe than sorry...
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: 86mxuf7eli@ds4.des.no
Dag-Erling Smørgrav d...@des.no writes:
: M. Warner Losh i...@bsdimp.com writes:
: Why not fix pidfile_open to not return a file handle when the PID
: doesn't match?
:
: It doesn't. If it can't lock the file, or if fstat(2) fails after it
: has locked the file, it returns NULL.
Then we have a bug in the locking code. I've definitely seen things
fail to behave properly after killing devd. Let me trace out what I
think is going on:
From pidfile_open:
/*
* Open the PID file and obtain exclusive lock.
* We truncate PID file here only to remove old PID immediatelly,
* PID file will be truncated again in pidfile_write(), so
* pidfile_write() can be called multiple times.
*/
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode);
if (fd == -1) {
--- We take this path, fd == -1.
count = 0;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
if (errno == EWOULDBLOCK pidptr != NULL) {
again:
--- and this one, so errno is EWOULDBLOCK
errno = pidfile_read(pfh-pf_path, pidptr);
--- errno is 0 here, so
if (errno == 0)
errno = EEXIST;
--- We return NULL with errno set toEEXIST
else if (errno == EAGAIN) {
if (++count = 3) {
nanosleep(rqtp, 0);
goto again;
}
}
}
free(pfh);
return (NULL);
}
So what's going on?
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: 86iq537egy@ds4.des.no Dag-Erling Smørgrav d...@des.no writes: : M. Warner Losh i...@bsdimp.com writes: : Maybe the real problem is that devd locks the file, then dies. The : file remains locked, so the flopen is failing with EWOULDBLOCK. : : The lock is released when the process that holds it terminates. So which process is that? devd took it out, and is subsequently killed. When it restarts, it can't take out the lock. The same code works perfectly in 8.0-stable from April. The conclusion, I believe, is that somebody broke locking in current... grump Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktiki223vbybdeqlua6fjcbbeqcqfujoimp5ho...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh i...@bsdimp.com wrote:
: In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
: Garrett Cooper yanef...@gmail.com writes:
: : On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com
wrote:
: : On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: : Hi,
: :
: : Sometimes utilities that are started by devd require libraries outside
: : /usr/lib. One example is the webcamd utility which is started by devd
upon USB
: : device insertion. What do you think about the following patch:
: :
: : --- devd (revision 209463)
: : +++ devd (local)
: : @@ -4,7 +4,7 @@
: : #
: :
: : # PROVIDE: devd
: : -# REQUIRE: netif
: : +# REQUIRE: netif ldconfig
: : # BEFORE: NETWORKING mountcritremote
: : # KEYWORD: nojail shutdown
: :
: : Funny since I was just monkeying around with this. This doesn't appear
: : to be the only issue with devd:
: :
: : # devd
: : devd: devd already running, pid: 430
: : # pgrep 430; echo $?
: : 1
: : #
: :
: : Looks like /etc/rc.d/devd restart is broken :(...
: :
: : This seems to fix that.
: : Thanks,
: : -Garrett
: :
: : Index: devd.cc
: : ===
: : --- devd.cc (revision 209530)
: : +++ devd.cc (working copy)
: : @@ -739,6 +739,7 @@
: : static void
: : event_loop(void)
: : {
: : + bool warn_user_about_cleanup;
: : int rv;
: : int fd;
: : char buffer[DEVCTL_MAXBUF];
: : @@ -804,6 +805,17 @@
: : new_client(server_fd);
: : }
: : close(fd);
: : + close(server_fd);
: : +
: : + if (unlink(PIPE) == 0) {
: : + cfg.remove_pidfile();
: : + warn_user_about_cleanup = false;
: : + } else
: : + warn_user_about_cleanup = true;
: : +
: : + if (warn_user_about_cleanup == true)
: : + warn(cleanup failed);
: : +
: : }
: :
: : /*
:
: This patch is wrong. The problems with it:
:
: (1) You don't need to unlink the pipe. If you can't unlink it, then
: you won't remove the pid file.
: (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
: remain around, and devd will fail to start.
: (3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed.
:
: The following works around the bug in pidfile_open, and allows me to
: restart devd both in a nice shutdown mode, as well as preventing devd
: from running multiple times. I'm not 100% sure the error handling is
: right, I'm still tracing through that path. This seems to work.
:
: Warner
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209492)
: +++ devd.cc (working copy)
: @@ -376,11 +376,18 @@
: if (_pidfile == )
: return;
: pfh = pidfile_open(_pidfile.c_str(), 0600, otherpid);
: - if (pfh == NULL) {
: - if (errno == EEXIST)
: + if (pfh != NULL)
: + return;
: + if (errno == EEXIST) {
: + /*
: + * Work around a bug in libutil where it will return this
: + * condition when the other process does not, in fact,
: + * actually exist. Use kill(2) to see if it is there or
not.
: + */
: + if (kill(otherpid, 0) == 0)
: errx(1, devd already running, pid: %d,
(int)otherpid);
: + } else
: warn(cannot open pid file);
: - }
: }
:
: void
: @@ -804,6 +811,8 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: + cfg.remove_pidfile();
: }
:
: I see what you mean. pidfile_open obviously fails with this requirement:
:
: If a file can not be locked, a PID of an already running daemon is
returned
: in the pidptr argument (if it is not NULL). The function does not write
: process' PID into the file here, so it can be used before
: fork()ing and exit
: with a proper error message when needed. If the path argument is NULL,
: /var/run/progname.pid file will be used.
:
: The problem I think is that the flopen arguments are wrong -- it passes in
: O_TRUNC, instead of checking whether or not the file exists beforehand, and
: then attempt to read in the file (if it exists) to determine whether
: or not the PID is alive.
Apart from tidiness, my patch is bogus. The real problem is flock()
seems to be failing now. Tests of my 8.0-stable system from April
shows that it works there. Likewise, my -current system from Jan 21st
appears to work. Time to start the binary search.
Warner
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktimpbazy2gu8fsly6wqdyzvg7c0id-vzeh3a3...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: This patch is wrong. The problems with it:
:
: (1) You don't need to unlink the pipe. If you can't unlink it, then
: you won't remove the pid file.
:
: The reason why my previous patch deleted `PIPE' file was because it's
: not a true pipe, but instead a named file in the filesystem, as that
: never gets cleaned up otherwise (please see my latest post).
That's Ok. The problem is elsewhere. The PIPE should not be deleted,
since that introduces races with other programs wishing to listen to
the pipe.
: (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
: remain around, and devd will fail to start.
:
: Correct.
Not quite. The pid file doesn't prevent devd starting. The lock on
the pid file does.
Why is the pid file still locked? Is locking broken in current? (no,
it isn't: all relevant regression tests pass) What is the root cause
then?
For me, devd refused to start because it exec'd dhclient. dhclient
survived having devd die. devd didn't close the lock file fd, so
dhclient inherited it.
My first knee-jerk reaction was 'why isn't that close on exec?'
That's a good question, the short answer of which is 'because there
are times you don't want it to be.'
But even that's not the root cause. Why is devd using system(3) to
execute commands? Why isn't it taking more care to create a cleaner
environment for commands to execute in? why isn't it following the
advice in the pidfile_close man page? These are all good questions.
Also, why do the child processes get an fd to read the stream of
events from the kernel on? Isn't that an information leak?
So, I've copied system and added the proper calls to clean all this
up.
Sadly, this only addresses the complaint that Garrett brought up. It
doesn't address the legitimate concerns that Hans has about startup
sequence and races with mounting /usr/local. That's a very good
question, indeed. You want to defer some actions until other services
are available. In a launchd world, you fork and run the processes.
They use whatever resources they need, but block on resources that
haven't finished starting yet. That's one possible solution here, but
outside the scope of devd, I'm afraid...
Warner
Index: devd.hh
===
--- devd.hh (revision 209492)
+++ devd.hh (working copy)
@@ -153,6 +153,7 @@
void set_pidfile(const char *);
void reset();
void parse();
+ void close_pidfile();
void open_pidfile();
void write_pidfile();
void remove_pidfile();
Index: devd.cc
===
--- devd.cc (revision 209492)
+++ devd.cc (working copy)
@@ -41,6 +41,7 @@
#include sys/stat.h
#include sys/sysctl.h
#include sys/types.h
+#include sys/wait.h
#include sys/un.h
#include ctype.h
@@ -49,6 +50,7 @@
#include err.h
#include fcntl.h
#include libutil.h
+#include paths.h
#include regex.h
#include signal.h
#include stdlib.h
@@ -152,13 +154,67 @@
// nothing
}
+static int
+my_system(const char *command)
+{
+ pid_t pid, savedpid;
+ int pstat;
+ struct sigaction ign, intact, quitact;
+ sigset_t newsigblock, oldsigblock;
+
+ if (!command) /* just checking... */
+ return(1);
+
+ /*
+* Ignore SIGINT and SIGQUIT, block SIGCHLD. Remember to save
+* existing signal dispositions.
+*/
+ ign.sa_handler = SIG_IGN;
+ ::sigemptyset(ign.sa_mask);
+ ign.sa_flags = 0;
+ ::sigaction(SIGINT, ign, intact);
+ ::sigaction(SIGQUIT, ign, quitact);
+ ::sigemptyset(newsigblock);
+ ::sigaddset(newsigblock, SIGCHLD);
+ ::sigprocmask(SIG_BLOCK, newsigblock, oldsigblock);
+ switch(pid = ::fork()) {
+ case -1:/* error */
+ break;
+ case 0: /* child */
+ /*
+* Restore original signal dispositions and exec the command.
+*/
+ ::sigaction(SIGINT, intact, NULL);
+ ::sigaction(SIGQUIT, quitact, NULL);
+ ::sigprocmask(SIG_SETMASK, oldsigblock, NULL);
+ /*
+* Close the PID file, and all other open descriptors.
+* Inherit std{in,out,err} only.
+*/
+ cfg.close_pidfile();
+ ::closefrom(3);
+ ::execl(_PATH_BSHELL, sh, -c, command, (char *)NULL);
+ ::_exit(127);
+ default:/* parent */
+ savedpid = pid;
+ do {
+ pid = ::wait4(savedpid, pstat, 0, (struct rusage *)0);
+ } while (pid == -1 errno == EINTR);
+ break;
+ }
+
Fw: svn commit: r209554 - in head/usr.sbin/pc-sysinstall: . pc-sysinstall
If you updated after pc-sysinstall was committed, but before this commit, you'll have a stray /pc-sysinstall. It can and should be deleted. Warner ---BeginMessage--- Author: imp Date: Sun Jun 27 17:14:04 2010 New Revision: 209554 URL: http://svn.freebsd.org/changeset/base/209554 Log: Properly inherit variables from src/usr.sbin/Makefile.inc for subdirectories of pc-sysinstall. Back out explicit setting in pc-sysinstall/pc-sysinstall/Makefile. Added: head/usr.sbin/pc-sysinstall/Makefile.inc (contents, props changed) Modified: head/usr.sbin/pc-sysinstall/pc-sysinstall/Makefile Added: head/usr.sbin/pc-sysinstall/Makefile.inc == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/usr.sbin/pc-sysinstall/Makefile.incSun Jun 27 17:14:04 2010 (r209554) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +.include ../Makefile.inc Modified: head/usr.sbin/pc-sysinstall/pc-sysinstall/Makefile == --- head/usr.sbin/pc-sysinstall/pc-sysinstall/Makefile Sun Jun 27 17:04:03 2010(r209553) +++ head/usr.sbin/pc-sysinstall/pc-sysinstall/Makefile Sun Jun 27 17:14:04 2010(r209554) @@ -2,6 +2,5 @@ SCRIPTS=pc-sysinstall.sh MAN= pc-sysinstall.8 -BINDIR=/usr/sbin .include bsd.prog.mk ---End Message--- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com wrote:
: On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: Hi,
:
: Sometimes utilities that are started by devd require libraries outside
: /usr/lib. One example is the webcamd utility which is started by devd upon
USB
: device insertion. What do you think about the following patch:
:
: --- devd (revision 209463)
: +++ devd (local)
: @@ -4,7 +4,7 @@
: #
:
: # PROVIDE: devd
: -# REQUIRE: netif
: +# REQUIRE: netif ldconfig
: # BEFORE: NETWORKING mountcritremote
: # KEYWORD: nojail shutdown
:
: Funny since I was just monkeying around with this. This doesn't appear
: to be the only issue with devd:
:
: # devd
: devd: devd already running, pid: 430
: # pgrep 430; echo $?
: 1
: #
:
: Looks like /etc/rc.d/devd restart is broken :(...
:
: This seems to fix that.
: Thanks,
: -Garrett
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209530)
: +++ devd.cc (working copy)
: @@ -739,6 +739,7 @@
: static void
: event_loop(void)
: {
: + bool warn_user_about_cleanup;
: int rv;
: int fd;
: char buffer[DEVCTL_MAXBUF];
: @@ -804,6 +805,17 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: +
: + if (unlink(PIPE) == 0) {
: + cfg.remove_pidfile();
: + warn_user_about_cleanup = false;
: + } else
: + warn_user_about_cleanup = true;
: +
: + if (warn_user_about_cleanup == true)
: + warn(cleanup failed);
: +
Why not fix pidfile_open to not return a file handle when the PID
doesn't match? Seems like a bug to me in that routine as well.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com wrote:
: On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: Hi,
:
: Sometimes utilities that are started by devd require libraries outside
: /usr/lib. One example is the webcamd utility which is started by devd upon
USB
: device insertion. What do you think about the following patch:
:
: --- devd (revision 209463)
: +++ devd (local)
: @@ -4,7 +4,7 @@
: #
:
: # PROVIDE: devd
: -# REQUIRE: netif
: +# REQUIRE: netif ldconfig
: # BEFORE: NETWORKING mountcritremote
: # KEYWORD: nojail shutdown
:
: Funny since I was just monkeying around with this. This doesn't appear
: to be the only issue with devd:
:
: # devd
: devd: devd already running, pid: 430
: # pgrep 430; echo $?
: 1
: #
:
: Looks like /etc/rc.d/devd restart is broken :(...
:
: This seems to fix that.
: Thanks,
: -Garrett
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209530)
: +++ devd.cc (working copy)
: @@ -739,6 +739,7 @@
: static void
: event_loop(void)
: {
: + bool warn_user_about_cleanup;
: int rv;
: int fd;
: char buffer[DEVCTL_MAXBUF];
: @@ -804,6 +805,17 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: +
: + if (unlink(PIPE) == 0) {
: + cfg.remove_pidfile();
: + warn_user_about_cleanup = false;
: + } else
: + warn_user_about_cleanup = true;
: +
: + if (warn_user_about_cleanup == true)
: + warn(cleanup failed);
: +
: }
:
: /*
This patch is wrong. The problems with it:
(1) You don't need to unlink the pipe. If you can't unlink it, then
you won't remove the pid file.
(2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
remain around, and devd will fail to start.
(3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed.
The following works around the bug in pidfile_open, and allows me to
restart devd both in a nice shutdown mode, as well as preventing devd
from running multiple times. I'm not 100% sure the error handling is
right, I'm still tracing through that path. This seems to work.
Warner
Index: devd.cc
===
--- devd.cc (revision 209492)
+++ devd.cc (working copy)
@@ -376,11 +376,18 @@
if (_pidfile == )
return;
pfh = pidfile_open(_pidfile.c_str(), 0600, otherpid);
- if (pfh == NULL) {
- if (errno == EEXIST)
+ if (pfh != NULL)
+ return;
+ if (errno == EEXIST) {
+ /*
+* Work around a bug in libutil where it will return this
+* condition when the other process does not, in fact,
+* actually exist. Use kill(2) to see if it is there or not.
+*/
+ if (kill(otherpid, 0) == 0)
errx(1, devd already running, pid: %d, (int)otherpid);
+ } else
warn(cannot open pid file);
- }
}
void
@@ -804,6 +811,8 @@
new_client(server_fd);
}
close(fd);
+ close(server_fd);
+ cfg.remove_pidfile();
}
/*
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktiki223vbybdeqlua6fjcbbeqcqfujoimp5ho...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh i...@bsdimp.com wrote:
: In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
: Garrett Cooper yanef...@gmail.com writes:
: : On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com
wrote:
: : On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: : Hi,
: :
: : Sometimes utilities that are started by devd require libraries outside
: : /usr/lib. One example is the webcamd utility which is started by devd
upon USB
: : device insertion. What do you think about the following patch:
: :
: : --- devd (revision 209463)
: : +++ devd (local)
: : @@ -4,7 +4,7 @@
: : #
: :
: : # PROVIDE: devd
: : -# REQUIRE: netif
: : +# REQUIRE: netif ldconfig
: : # BEFORE: NETWORKING mountcritremote
: : # KEYWORD: nojail shutdown
: :
: : Funny since I was just monkeying around with this. This doesn't appear
: : to be the only issue with devd:
: :
: : # devd
: : devd: devd already running, pid: 430
: : # pgrep 430; echo $?
: : 1
: : #
: :
: : Looks like /etc/rc.d/devd restart is broken :(...
: :
: : This seems to fix that.
: : Thanks,
: : -Garrett
: :
: : Index: devd.cc
: : ===
: : --- devd.cc (revision 209530)
: : +++ devd.cc (working copy)
: : @@ -739,6 +739,7 @@
: : static void
: : event_loop(void)
: : {
: : + bool warn_user_about_cleanup;
: : int rv;
: : int fd;
: : char buffer[DEVCTL_MAXBUF];
: : @@ -804,6 +805,17 @@
: : new_client(server_fd);
: : }
: : close(fd);
: : + close(server_fd);
: : +
: : + if (unlink(PIPE) == 0) {
: : + cfg.remove_pidfile();
: : + warn_user_about_cleanup = false;
: : + } else
: : + warn_user_about_cleanup = true;
: : +
: : + if (warn_user_about_cleanup == true)
: : + warn(cleanup failed);
: : +
: : }
: :
: : /*
:
: This patch is wrong. The problems with it:
:
: (1) You don't need to unlink the pipe. If you can't unlink it, then
: you won't remove the pid file.
: (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
: remain around, and devd will fail to start.
: (3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed.
:
: The following works around the bug in pidfile_open, and allows me to
: restart devd both in a nice shutdown mode, as well as preventing devd
: from running multiple times. I'm not 100% sure the error handling is
: right, I'm still tracing through that path. This seems to work.
:
: Warner
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209492)
: +++ devd.cc (working copy)
: @@ -376,11 +376,18 @@
: if (_pidfile == )
: return;
: pfh = pidfile_open(_pidfile.c_str(), 0600, otherpid);
: - if (pfh == NULL) {
: - if (errno == EEXIST)
: + if (pfh != NULL)
: + return;
: + if (errno == EEXIST) {
: + /*
: + * Work around a bug in libutil where it will return this
: + * condition when the other process does not, in fact,
: + * actually exist. Use kill(2) to see if it is there or
not.
: + */
: + if (kill(otherpid, 0) == 0)
: errx(1, devd already running, pid: %d,
(int)otherpid);
: + } else
: warn(cannot open pid file);
: - }
: }
:
: void
: @@ -804,6 +811,8 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: + cfg.remove_pidfile();
: }
:
: I see what you mean. pidfile_open obviously fails with this requirement:
:
: If a file can not be locked, a PID of an already running daemon is
returned
: in the pidptr argument (if it is not NULL). The function does not write
: process' PID into the file here, so it can be used before
: fork()ing and exit
: with a proper error message when needed. If the path argument is NULL,
: /var/run/progname.pid file will be used.
:
: The problem I think is that the flopen arguments are wrong -- it passes in
: O_TRUNC, instead of checking whether or not the file exists beforehand, and
: then attempt to read in the file (if it exists) to determine whether
: or not the PID is alive.
O_TRUNC likely is OK. If you can obtain the lock, then truncation is
what you want...
Maybe the real problem is that devd locks the file, then dies. The
file remains locked, so the flopen is failing with EWOULDBLOCK. That
gets turned into an EEXIST return value, with the PID
HEADS-UP: object directory name change
I recently committed a change that changes the name of the object tree where things are built to if you are cross compiling. Rather than /usr/obj/$TARGET_ARCH, it is now /usr/obj/$TARGET.$TARGET_ARCH. The reason for the change is so that embedded platforms with multiple endians can compile into the same tree. This means that if you are cross building on a regular basis, you'll need to update your cross tools. If you are building kernels, then you'll need a make kernel-toolchain for things to work again. You'll also be able to reclaim the disk space used by the old tree. If you want, a simple mv will do the trick. In a few days mips and arm will change how endian is represented and you'll need two trees for each if you want to compile both endians (one for mips.mipsel and one for mips.mipseb). I'm still working out some snags with how make universe will cope with the kernels, so I've not pulled the trigger on that change yet. thank you for your patience... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: devd and/or ACPI not reporting a heat problem
In message: 4c187778.9060...@freebsd.org
Doug Barton do...@freebsd.org writes:
: Howdy,
:
: I thought my heat problems were over with this laptop thanks to all
: the great suggestions I've received about powerd, no stepping, etc. (I
: also propped up both the back and the front to make a nice big air
: pocket.) I've always been pretty religious about blowing the dust off
: the fans and heat sinks, but I guess it's been dustier than I thought
: lately because I finally caught my laptop doing what it's been doing
: for the last 2 weeks, which is (occasionally) powering down when it
: was unattended; and the problem was heat.
:
: Of course I've been running devd all along, and so I initially ruled
: out the heat problem due to this entry in devd.conf:
:
: # Notify all users before beginning emergency shutdown when we get
: # a _CRT or _HOT thermal event and we're going to power down the system
: # very soon.
: notify 10 {
: match system ACPI;
: match subsystem Thermal;
: match notify 0xcc;
: action logger -p kern.emerg 'WARNING: system temperature too high,
: shutting down soon!';
: };
:
: I'm not getting any of those notices in the logs, so I was looking
: other places. (I do get other ACPI-related activity from devd, such as
: the notice that it's going on and off AC power.)
:
: So, 2-part question, how can I make sure that devd gets the message,
: and how do I make sure that the notice comes _before_ the BIOS forces
: the system to power off. I.e., I'd like to have some sort of devd
: notice that comes in time to do a clean shutdown, or perhaps some
: other mitigation strategy prior to the BIOS taking over.
You may need a simple cron entry that checks the temperature and
report when it is getting close. acpi should be reporting thermal
events before then that aren't 0xcc, but if not, that's the fallback
that people use.
Sadly, at least for one of my laptops, I've seen sudden 10-20C spikes
which trigger this. I think this laptop is badly broken, and don't
use it any more.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 4c1315f9.6000...@freebsd.org Doug Barton do...@freebsd.org writes: : On 06/11/10 14:18, M. Warner Losh wrote: : This is building the proper set of tools for the target. It is easy : to do, and only a couple lines of Makefile foo in Makefile.inc1 : instead of in bsd.own.mk. It is a fairly natural consequence of the : tbemd stuff I have been working on and have started merging. : : The consequences today are that you build some extra tools that are : only needed to build clang when in fact you aren't really going to be : building clang. The cost is however long it takes to do this on the : platform you are building on. This can range from a minute or two to : tens of minutes depending on the power of your build system. : : Ok, obviously I'm dense because I didn't understand an answer to my : question anywhere in there. :) So let me try again. Why are we not : optimizing for the common case, where the world is built on the system : it's going to run on, which means that WITHOUT_CLANG can easily mean : exactly that? Because if we optimize for that case, we break the other cases. Broken trumps fast, so we always build the clang tools. The reason it is broke is that the default for clang varies between architectures, which makes the usual tests for MK_CLANG not work for the bootstrap tools phase. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 4c13f53f.3050...@freebsd.org
Doug Barton do...@freebsd.org writes:
: On 06/12/10 08:10, M. Warner Losh wrote:
: In message:4c1315f9.6000...@freebsd.org
: Doug Bartondo...@freebsd.org writes:
: : On 06/11/10 14:18, M. Warner Losh wrote:
: : This is building the proper set of tools for the target. It is
: easy
: : to do, and only a couple lines of Makefile foo in Makefile.inc1
: : instead of in bsd.own.mk. It is a fairly natural consequence of
: the
: : tbemd stuff I have been working on and have started merging.
: :
: : The consequences today are that you build some extra tools that are
: : only needed to build clang when in fact you aren't really going to
: be
: : building clang. The cost is however long it takes to do this on
: the
: : platform you are building on. This can range from a minute or two
: to
: : tens of minutes depending on the power of your build system.
: :
: : Ok, obviously I'm dense because I didn't understand an answer to my
: : question anywhere in there. :) So let me try again. Why are we not
: : optimizing for the common case, where the world is built on the
: system
: : it's going to run on, which means that WITHOUT_CLANG can easily mean
: : exactly that?
:
: Because if we optimize for that case, we break the other cases.
: Broken trumps fast, so we always build the clang tools.
:
: The reason it is broke is that the default for clang varies between
: architectures, which makes the usual tests for MK_CLANG not work for
: the bootstrap tools phase.
:
: Sorry, still dense here.
I explained it already, but I'll show the exact code...
: Can you point to code where simply testing
: for MK_CLANG won't work?
from Makefile.inc1
# XXX: There is no way to specify bootstrap tools depending on MK-flags
# with different per-architecture default values. Always build tblgen.
_clang_tblgen= \
lib/clang/libllvmsupport \
lib/clang/libllvmsystem \
usr.bin/clang/tblgen
coupled with:
from bsd.own.mk:
#
# Default behaviour of MK_CLANG depends on the architecture.
#
.if ${MACHINE_ARCH} == amd64 || ${MACHINE_ARCH} == i386 || \
${MACHINE_ARCH} == powerpc
_clang_yes=CLANG
_clang_no=
.else
_clang_yes=
_clang_no=CLANG
.endif
so, if you add the test of MK_CLANG above for setting _clang_tblgen,
you break the following case:
neither WITH_CLANG or WITHOUT_CLANG, we go with the default:
running on sparc64 (so MACHINE_ARCH=sparc64)
building for i386 (so TARGET_ARCH=i386)
o MK_CLANG will be 'no'
o so clang's tblgen won't be built (if we added the test above you suggest)
o during the build phase MACHINE_ARCH is set to i386, so clang fails
later because MK_CLANG will be 'yes'.
We would do extra work for the converse (building sparc64 on a i386
host), since MK_CLANG is yes so we build tblgen, but never use it.
Since we always build tblgen, we fix this by degrading to this case.
This also has no change from the typical case (amd64 or i386 built on
amd64 or i386).
I plan on fixing this problem, since it also applies to WITH_FDT. The
root cause is that WITH_foo/WITHOUT_foo works great for optional
components of the system that are basically the same everywhere
(sendmail, lpr, old toolchain), but it is horrible for communicating
intrinsic properties of the architecture (which is what is being done
here) since there's two sets of contexts where you have to ask the
question. One where TARGET_ARCH matters, and one where MACHINE_ARCH
matters. While the specific examples in this case might not be too
interesting, the problem it exposes is interesting to solve...
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 20100611185237.gl56...@hoeg.nl Ed Schouten e...@80386.nl writes: : Hello Andreas, : : * Andreas Tobler andreast-l...@fgznet.ch wrote: : I have a sparc64 machine which is quite slow. And for my purpose I : do not need CLANG etc. atm. : : Clang is not enabled on sparc64, so there is no need to disable : anything. If you do want to disable Clang on i386, amd64, pc98 or : powerpc, add WITHOUT_CLANG=yes to /etc/src.conf, as described in : src.conf(5). Except that clang isn't quite disabled when cross-building, due to the issue I pointed out when the commit went in wrt bsd.own.mk. MACHINE_ARCH is still amd64 until we start to build the sparc64 binaries, so anything in the bootstrapping part of the build will not be disabled. that's one of many reasons disabling things in bsd.own.mk based on architecture is going to fail. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 20100611.132052.271446115462387749@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 20100611185237.gl56...@hoeg.nl : Ed Schouten e...@80386.nl writes: : : Hello Andreas, : : : : * Andreas Tobler andreast-l...@fgznet.ch wrote: : : I have a sparc64 machine which is quite slow. And for my purpose I : : do not need CLANG etc. atm. : : : : Clang is not enabled on sparc64, so there is no need to disable : : anything. If you do want to disable Clang on i386, amd64, pc98 or : : powerpc, add WITHOUT_CLANG=yes to /etc/src.conf, as described in : : src.conf(5). : : Except that clang isn't quite disabled when cross-building, due to the : issue I pointed out when the commit went in wrt bsd.own.mk. : MACHINE_ARCH is still amd64 until we start to build the sparc64 : binaries, so anything in the bootstrapping part of the build will not : be disabled. that's one of many reasons disabling things in : bsd.own.mk based on architecture is going to fail. And even if you add WITHOUT_CLANG to your src.conf, we still always build some of the clang infrastructure in the bootstrap tools phase... But we have to do that to avoid getting not being able to build clang on an architecture that doesn't have it for an architecture that does. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 20100611203544.ga1...@hoeg.nl Ed Schouten e...@80386.nl writes: : It should be noted that tblgen is not the only tool that may get built : for nothing. Another example is aicasm, which is always built, even if : ahc is not placed in the kernel configuration file. That's another one I'd like to fix :) But it only takes seconds to build... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 4c129ece.8040...@freebsd.org Doug Barton do...@freebsd.org writes: : On 06/11/10 13:35, Ed Schouten wrote: : * M. Warner Loshi...@bsdimp.com wrote: : Except that clang isn't quite disabled when cross-building, due to the : issue I pointed out when the commit went in wrt bsd.own.mk. : MACHINE_ARCH is still amd64 until we start to build the sparc64 : binaries, so anything in the bootstrapping part of the build will not : be disabled. that's one of many reasons disabling things in : bsd.own.mk based on architecture is going to fail. : : Exactly. I already mentioned this problem on arch@ back in May. That's : why a small portion of LLVM, namely tblgen, is always built. Even : though : this will slightly increase the build time, it shouldn't be excessive. : If someone knows of a nice way to fix this, I am more than willing to : get it fixed. Ed: Sorry I missed it back in may on a...@. I'm usually pretty good about catching things like that... : What is this that needs to be fixed? Or, asked another way, why are : we not optimizing for the common case (building world on the machine : that it will be run on)? This is building the proper set of tools for the target. It is easy to do, and only a couple lines of Makefile foo in Makefile.inc1 instead of in bsd.own.mk. It is a fairly natural consequence of the tbemd stuff I have been working on and have started merging. The consequences today are that you build some extra tools that are only needed to build clang when in fact you aren't really going to be building clang. The cost is however long it takes to do this on the platform you are building on. This can range from a minute or two to tens of minutes depending on the power of your build system. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable CLANG co build in buildworld?
In message: 20100611225844.gc1...@hoeg.nl Ed Schouten e...@80386.nl writes: : Hi Warner, : : * M. Warner Losh i...@bsdimp.com wrote: : This is building the proper set of tools for the target. It is easy : to do, and only a couple lines of Makefile foo in Makefile.inc1 : instead of in bsd.own.mk. It is a fairly natural consequence of the : tbemd stuff I have been working on and have started merging. : : Would you be interested in fixing it for us, then? Let me know if there : is anything on our side that needs to be done. Yes. I'd planned on fixing this once I'd had a chance to merge tbemd branch to head. Sorry if I hadn't made it clear that I was both complaining and offering to help... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: New event timers infrastructure
In message: 4c0e5646.1060...@freebsd.org Alexander Motin m...@freebsd.org writes: : Brandon Gooch wrote: : Alexander, do you feel that the code is at a stage where meaningful : user testing can occur? : : I think yes. I've touched a lot of legacy code, so it would be nice to : know what I may have broken. For example, i8254 and RTC drivers now more : dependent on attaching to PnP/ACPI reported hardware. I am not sure if : there still any legacy system which not doing that. The oldest system I : have tested was P-III Celeron. Unluckily my small development SSD is too : large for my Pentium board's BIOS. :) The only issue I'm aware of is that on older systems PnP and ACPI can sometimes interfere. But I thought we'd fixed those issues... I can test on my older pentium too... Warner : There is still work planned, but I hope it won't require major changes : in already written code. : : -- : Alexander Motin : ___ : freebsd-current@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org : ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
In message: 20100531161713.ga60...@freebsd.org Roman Divacky rdiva...@freebsd.org writes: : On Mon, May 31, 2010 at 09:14:09AM -0700, Bakul Shah wrote: : On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: : : I would like to propose to integrate clang/LLVM into FreeBSD HEAD : in the near future (days, not weeks). : : clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly : replace gcc. It is BSDL-like licensed. The sources are ~45MB (the : svn checkout is 97MB). Clang/LLVM is written in C++. : : Clang can compile all of FreeBSD on i386/amd64 including world and booting : kernel. Other architectures that are close to working are MIPS, PowerPC : and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM : sources and the build infrastructure and this is what we aim to integrate : at first. : : The import of clang/LLVM was discussed at the toolchain summit May 10th : but I would like to hear your opinion. I got approval from core@ on : importing it. : : So please share your support or resistance to the idea of importing clang. : : Roman Divacky : : I already use clang for some things but I think the issue : here is not support/resistance but something else: : : * IMHO for a change of this nature the core needs to publish :a set of clear acceptance criteria for importing clang. :Can this be done? : : I asked core@ and they support the import They support the import, in the context of the larger plan, which you've not articulated. Let's be clear here. : * Since clang doesn't support all the archs, what is the plan :for unsupported archs? :a. Is FreeBSD going to have both compilers in the base? : : yes, this is what this import is about - importing clang, : nothing else changes There's more context here too. To improve the support of various architectures, we're planning on doing two things. First, we're updating binutils to the latest gplv2 version. This will solve many problems. There's some other plans in this area as well, but the summary is basically integrating some important vendor patches. Second, we're planning to have the ability to use an external, perhaps vendor supplied, tool chain. You can kludge this together today, but it is tedious and difficult. :b. Is the project drop these FreeBSD ports? or : : no, of course not : :c. Do people have to import gcc from ports to build these : FreeBSD ports? : : nothing is being changed, just one more application after : a buildworld/installworld appears (that being clang) : : * What about ports? The plan that was articulated at the toolchain summit was to install clang as clang, and gcc as cc, so that /usr/ports continue to work. There's a lot of work needed to make all the ports work with clang. There's a summer of code project to make it possible to select a default compiler to built ports. There's a missing piece of functionality that was agreed to in the clang tree right now. There needs to be support for 'WITH_CLANG_BOOTSTRAP' to build the system with the clang, but leave gcc as the default compiler for ports. There also needs to be support for WITH_CLANG_IS_CC which would also make clang the default. : * Basically the core needs to lay out a roadmap. There was supposed to be a summary of the roadmap posted, but that's not yet happened... Roman really should have waited to push ahead until this was posted because it does answer the bigger picture questions. : It is clear that not everyone has the same view of what the : acceptance criteria might be so publishing it would help : people understand what to expect. : : nothing changes for the ports, there's an ongoing project to enable : ports to be usable with clang (or some other compiler) but thats : orthogonal to this. Part of the problem with this thread is that the whole, agreed plan wasn't laid out at the first part of it, so people are freaking out about what the plans are for the future. They were discussed and first order agreement was reached at the tool chains summit. But part of the agreement was to post the whole agreement so people know and understand the various trade offs. I think that would go a long way towards answering the questions that are being raised and to quell the visceral reaction that I've seen in this thread Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
In message: aanlktikx-vnfgzuvh4-cevikdjslqqjrahjevdqd-...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mon, May 31, 2010 at 11:33 AM, M. Warner Losh i...@bsdimp.com wrote: : In message: 20100531161713.ga60...@freebsd.org : : [...] : : There's more context here too. To improve the support of various : architectures, we're planning on doing two things. First, we're : updating binutils to the latest gplv2 version. This will solve many : problems. There's some other plans in this area as well, but the : summary is basically integrating some important vendor patches. : Second, we're planning to have the ability to use an external, perhaps : vendor supplied, tool chain. You can kludge this together today, but : it is tedious and difficult. : : This in and of itself is an interesting prospect. Why would happen if : one could drop in icc for instance :) (I realize that it's basically : gcc-compatible, but can this be done today without a lot of rework and : effort)? This is more about dropping in different assemblers, linkers, etc, than picking icc. CC=xxx is relatively easy. It gets harder if you don't want to use the in-tree toolchain. Especially when cross building... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
In message: 20100429224938.gi90...@darkthrone.kvedulv.de Michael Moll kved...@kvedulv.de writes: : Hi, : : On Thu, Apr 29, 2010 at 11:30:06PM +0100, Bruce Cran wrote: : /boot/kernel/kernel. It looks like it thinks there's more data available : than there is. : : config/main.c gets the size of the configuration by running elfdump: : : elfdump -c /boot/kernel/kernel | grep -A 5 kern_conf | tail -2 | cut -d ' ' : -f 2 | paste - - - : : 100533682656 : : The first column is the offset, and the second is the number of bytes, but the : embedded configuration only has 2649 bytes. : : OK, that explains that with all the related commits backup out : (207265-206664) the resulting config-binary still fails. I don't have : time today to build the kernel with the different revisions to hunt the : problem down to one commit... : : imp@: The last commits to usr.sbin/config/* might have raised this : problem, could you have a look at it? Do you have a small, reproducible sequence of events that will recreate this problem? I've seen no problems at all in my testing. I assume this is in -current? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: config(8) dumps core
In message: 2010043016.ga90...@darkthrone.kvedulv.de Michael Moll kved...@kvedulv.de writes: : On Thu, Apr 29, 2010 at 05:07:00PM -0600, M. Warner Losh wrote: : Do you have a small, reproducible sequence of events that will : recreate this problem? I've seen no problems at all in my testing. : I assume this is in -current? : : Yes, -CURRENT. Compile a kernel on sparc64 (didn't try this yet on other : archs) and run config -x on the resulting file. Can you please enclose the exact config file that you are using? Thanks. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switchover to CAM ATA?
I've read most of this thread. I think this is cool technology. However, before we move forward with this, we need to have a plan for the various issues that have come up. The plan needs to be specific, have owners for key items, warnings about ownerless == obsoleted, and target dates. I think this is one of the cases where we should record the plan of record on a wiki. It worked well for other times we've had big, disruptive changes. My opinion for the path forward: (1) Send a big heads up about the future of ataraid(5). It will be shot in the head soon, to be replaced be a bunch of geom classes for each different container format. At least that seems to be the rough consensus I've seen so far. We need worker bees to do many of these classes, although much can be mined from the ataraid code today. (2) Send another big heads up strongly recommending people go to glabel based fstabs. Maybe the right option here is to provide a simple script walk people through the conversion. This will render the carnage of ad - ada (or da) a mostly non-event, and also protect people from 'oops' of rebooting with that thumb drive in the system. (3) Create a wiki to record all the new geom classes needed. Find people to own each one, or note it is unowned, and support will be dropped if no owner can be found. (4) sysinstall should default to creating label systems, if it doesn't already. (5) Issues with glabel and ataraid(5) need an owner, and need to be resolved, since the device names here are likely to change. (6) Someone needs to write-up a detailed description of how to do this for UPDATING. Maybe we can reuse text from #2. (7) We need a target time line for these things to happen. We can't just break ataraid(5) by default with little or no warning. Realistically, this will be for 9.0 and later systems, so we have some time before the branch to give warning, as well as pull the switch and have adequate testing time. (8) Fill in all the parts that I've missed :) Comments? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Switchover to CAM ATA?
In message: 20100426181209.gb3...@garage.freebsd.pl Pawel Jakub Dawidek p...@freebsd.org writes: : On Mon, Apr 26, 2010 at 10:33:27AM -0600, M. Warner Losh wrote: : I've read most of this thread. I think this is cool technology. : However, before we move forward with this, we need to have a plan for : the various issues that have come up. The plan needs to be specific, : have owners for key items, warnings about ownerless == obsoleted, and : target dates. : : I think this is one of the cases where we should record the plan of : record on a wiki. It worked well for other times we've had big, : disruptive changes. : : My opinion for the path forward: : (1) Send a big heads up about the future of ataraid(5). It will be : shot in the head soon, to be replaced be a bunch of geom classes : for each different container format. At least that seems to be : the rough consensus I've seen so far. We need worker bees to do : many of these classes, although much can be mined from the ataraid : code today. : : This shouldn't be a bunch of GEOM classes. This should one class which : recognize multiple formats, just like the LABEL class. : I don't think it is feasible to reuse gmirror for that, it wasn't : designed in something like this in mind. OK. Maybe I got the consensus wrong... My key point is that we need a plan moving forward, we need to identify what's actively being worked on vs somebody else[tm] should do tihs and when it needs to be done or else. : (2) Send another big heads up strongly recommending people go to : glabel based fstabs. Maybe the right option here is to provide a : simple script walk people through the conversion. This will : render the carnage of ad - ada (or da) a mostly non-event, and : also protect people from 'oops' of rebooting with that thumb drive : in the system. : (3) Create a wiki to record all the new geom classes needed. Find : people to own each one, or note it is unowned, and support will be : dropped if no owner can be found. : (4) sysinstall should default to creating label systems, if it doesn't : already. : (5) Issues with glabel and ataraid(5) need an owner, and need to be : resolved, since the device names here are likely to change. : : What are the issues? ataraid doesn't remove the underlying ad* devices, so glabel often picks those up instead of the ataraid device, and you only get 1 disk's worth of raid device... So no mirroring or only 1/2 a striped volume. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Increasing MAXPHYS
In message: d9d66012-16fd-4fb6-ab6a-9a8d17727...@samsco.org Scott Long sco...@samsco.org writes: : I'd like to go in the opposite direction. The queue-dispatch-queue : model of GEOM is elegant and easy to extend, but very wasteful for : the simple case, where the simple case is one or two simple : partition transforms (mbr, bsdlabel) and/or a simple stripe/mirror : transform. None of these need a dedicated dispatch context in order : to operate. What I'd like to explore is compiling the GEOM stack at : creation time into a linear array of operations that happen without : a g_down/g_up context switch. As providers and consumers taste each : other and build a stack, that stack gets compiled into a graph, and : that graph gets executed directly from the calling context, both : from the dev_strategy() side on the top and the bio_done() on the : bottom. GEOM classes that need a detached context can mark : themselves as such, doing so will prevent a graph from being : created, and the current dispatch model will be retained. I have a few things to say on this. First, I've done similar things at past companies for systems that are similar to geom's queueing environment. It is possible to convert the queueing nodes in the graph to filtering nodes in the graph. Another way to look at this is to say you're implementing direct dispatch into geom's stack. This can be both good and bad, but should reduce latency a lot. One problem that I see is that you are calling into the driver from a different set of contexts. The queueing stuff was there to protect the driver from LoRs due to its routines being called from many different contexts, sometimes with other locks held (fact of life often in the kernel). So this certainly is something worth exploring, especially if we have optimized paths for up/down for certain geom classes while still allowing the current robust, but slow, paths for the more complicated nodes in the tree. It remains to be see if there's going to be issues around locking order, but we've hit that with both geom and ifnet in the past, so caution (eg, running with WITNESS turned on early and often) is advised. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
In message: 20100322185331.ga88...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Fri, Mar 12, 2010 at 12:50:32PM -0700, M. Warner Losh wrote: : : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: : So the issue isn't as cut and dried as you might think. There's : multiple different conventions used here in addition to your simple : example. : : I guess we'd have to take a poll to find out. Seems pretty cut and dried : to me. COMPAT_FREEBSDn has an established context that does not match : this new usage. That is - same bit'ness, compatibility with an older : FreeBSD API for the same architecture. All the other COMPAT_* are for : foreign ABI compatibility. COMPAT_LINUX32 possibly should have been : COMPAT_LINUX_X86_64. (or is it MI and is usable as-is for PowerPC : and MIPS? I haven't looked that deeply at the code.) no, COMPAT_LINUX32 is the right name. While we don't have PowerPC or MIPS linux emulation bits in the kernel, the code if for dealing with running 32-bit binaries on 64-bit machines. There may be a little leakage of x86 specific goo here, but not a lot. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
P.S. I think that there's much traction to the idea of moving from COMPAT_FREEBSDx to some other variable called, for example, COMPAT_FREEBSD_BACK_TO=x, which will give compatibility for binaries as old as FreeBSD x.0, and have all the other magic handled behind the scenes. This would render the inconsistency with COMPAT_FREEBSDx part of the debate completely moot. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] newvers.sh
In message: 20100315142806.ga5...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote: : In message: 20100312171206.ga31...@dragon.nuxi.org : David O'Brien obr...@freebsd.org writes: : : * Simplify SRCDIR calculation by directly finding the kernel sources : : based directly on one of them. : : Reviewed by: dhw : : This change does not increase the kernel build time. It also continues : : to restrict the revision to just the kernel sources, and not the whole : : tree. : : Timing tests by: dhw : : patch omitted : : I have a better simplification, I think, that works for me for each of : the tests that I've done (both traditional and buildkernel builds). : : I also have other simplifications. But want to do this in stages, : least there be some corner case or misunderstanding by someone. Normally this is a sensible process. However, my patches change how we guess where sys is, and as such, I think we should go directly there and work out the corner cases and such there. : Can you confirm this works for you and also comment on the change : itself? It is a bigger change, but results in a simpler (I think) : newvers.sh. : Comments? : : I would prefer to do this in stages so things aren't misunderstood. : This patch is one of the key parts that shows I am not making the : 'svnversion' run take longer, and that it does not cover more of : the tree than before. That's exactly what my patch does by passing in SYSDIR directly. Why guess and then replace it with a different guess. Why not go directly to the best guess immediately? We know it is always right, because we know it is what the kernel is using to build itself. And we know that's the directory we want to use for the svn command. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] newvers.sh
In message: 20100316002939.ga36...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Mon, Mar 15, 2010 at 08:44:26AM -0600, M. Warner Losh wrote: : In message: 20100315142806.ga5...@dragon.nuxi.org : David O'Brien obr...@freebsd.org writes: : : On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote: : : In message: 20100312171206.ga31...@dragon.nuxi.org : : David O'Brien obr...@freebsd.org writes: : : : * Simplify SRCDIR calculation by directly finding the kernel sources : : : based directly on one of them. : : : Reviewed by: dhw : : : This change does not increase the kernel build time. It also continues : : : to restrict the revision to just the kernel sources, and not the whole : : : tree. : : : Timing tests by: dhw : : : : patch omitted : : : : I have a better simplification, I think, that works for me for each of : : the tests that I've done (both traditional and buildkernel builds). : : : : I also have other simplifications. But want to do this in stages, : : least there be some corner case or misunderstanding by someone. : : Normally this is a sensible process. However, my patches change how : we guess where sys is, and as such, I think we should go directly : there and work out the corner cases and such there. : : Well that's what I was trying to do with the patch I sent you in : Message-ID: 20100308010125.ga6...@dragon.nuxi.org on 7-March-2010. : There you didn't care for that approach and would not give details : as to the claims you made. I saw your patch and thought this one would be better and simplify newvers.sh. I saw nothing wrong, per se, with the patch. Instead, I saw an opportunity to refine it and make the resulting newvers.sh simpler by using values already computed by the build system. : I will reply in another email the issues with your patch. I welcome constructive criticism of the patch. : : I would prefer to do this in stages so things aren't misunderstood. : : This patch is one of the key parts that shows I am not making the : : 'svnversion' run take longer, and that it does not cover more of : : the tree than before. : : That's exactly what my patch does by passing in SYSDIR directly. Why : guess and then replace it with a different guess. : : Guess??? 'newvers.sh' is not going to be within the kernel sources : tree?? Are you allowing for the person that did a 'mv sys/conf/newvers.sh' : to elsewhere? Considering you have sh $S/conf/newvers.sh, I don't see : where you are. Is $0 confusing you? The kernel source tree is inferred from $0, yes. My method passes it in directly, and makes newvers.sh shell variable usage more uniform with the rest of the kernel. It also eliminated a number of lines from newvers.sh by using the value the kernel build process already had cached. The elimination of duplicated computation is why I think this is a better approach. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] newvers.sh
David
In message: 20100316004117.gb36...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Sat, Mar 13, 2010 at 09:13:03PM -0700, M. Warner Losh wrote:
: The Makefile already knows where the kernel src is located. Let's use
: that knowledge to make things a little simpler. This also uses the
: Makefile variable SYSDIR. It should also work with non-standard sys
: directories.
: ..
: Index: conf/kern.post.mk
: vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
: - MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
: + MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
:
: I'd rather not introduce yet more special things that have to be done
: before invoking newvers.sh. (MAKE=${MAKE} sh is not an issue as the
: script works if MAKE is not passed in given it has ${MAKE:-make}).
:
: The script can be more self contained than this, and I think that is
: technically better.
OK. I think that passing the info in isn't that big a deal and makes
the dependency more explicit.
: Index: conf/newvers.sh
: ===
: --- conf/newvers.sh (revision 204938)
: +++ conf/newvers.sh (working copy)
: @@ -44,7 +44,7 @@
: ${PARAMFILE})
: else
: RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
: - $(dirname $0)/../sys/param.h)
: + ${SYSDIR}/sys/param.h)
:
: I don't think we should depend on having SYSDIR defined before invoking
: newvers.sh. Its worse than requiring that as a parameter. We don't set
: KERN_IDENT=$KERN_IDENT before invoking newvers.sh.
:
: Either
: MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT} $S
: or
: MAKE=${MAKE} SYSDIR=$S KERN_IDENT=$KERN_IDENT sh $S/conf/newvers.sh
:
: for regularity. But I really feel we can trust 'newvers.sh' to be within
: the kernel sources directory - thus $(dirname $0)/.. is a
: self-contained method to determining what the kernel directory is.
: No guessing. This can be optimized to ${0%/*}/...
You are trading one dependency for another here. Either you pass it
in by typing the path to newvers.sh, or you pass it in directly from
the kernel build. But it would be cleaner if it were passed in as the
first parameter.
: -v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
: +v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
:
: Unfortunately, [snipped] [[ ${d} is used later, and silent succeeds
: with the wrong results with your patch ]]
$d is used later. Gotcha. I missed that.
: -case $d in
: -*/sys/*)
: ..
: +for dir in /bin /usr/bin /usr/local/bin; do
: + if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
: + svnversion=${dir}/svnversion
: ..
: - for dir in /bin /usr/bin /usr/local/bin; do
: - if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
:
: Are you implicitly depending on there not being a '.svn/' in the root
: directory?
Assuming that you violated the precondition of passing SYSDIR in, then
yes. However, I don't think that's a big deal.
: The invocation of 'newvers.sh' elsewhere in the tree will not
: have 'SYSDIR' (of your patch) set, so the test will be (last iteration):
:
: if [ -d /.svn -a -x $/usr/local/bin/svnversion ] ; then
:
: I'd rather not limit the user to not having '/.svn' that is used to
: track configuration files, etc...
:
: This patch is the end version I was working to (thru a series of
: changes):
:
: * Simplify SRCDIR calculation by directly finding the kernel sources
: based directly on one of them.
: * Rename SRCDIR to KERN_TOPDIR to be more clear which sources these are,
: and at what level
: * git isn't in the base system and being GPL'ed, likely never will.
: * Revisit r196435 - rather than guess if 'newvers.sh' is being
: invoked as part of the kernel build or not based on a path (proven
: to be fragile), key off of having a KERN_IDENT.
Comments below...
: Index: newvers.sh
: ===
: --- newvers.sh(revision 204939)
: +++ newvers.sh(working copy)
: @@ -39,12 +39,13 @@ fi
: RELEASE=${REVISION}-${BRANCH}
: VERSION=${TYPE} ${RELEASE}
:
: +KERN_TOPDIR=${0%/*}/..
I'd have selected SYSDIR, which is used elsewhere in the build system
to indicate the top of the kernel tree.
: if [ X${PARAMFILE} != X ]; then
: RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
: ${PARAMFILE})
: else
: RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
: - $(dirname $0)/../sys/param.h)
: + ${KERN_TOPDIR}/sys/param.h)
: fi
:
If we move this grep into include/Makefile, then we can eliminate
this entire conditional, leaving only the else part of it.
: @@ -87,27 +88,22 @@ touch version
: v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
: i=`${MAKE:-make} -V
Re: [PATCH] newvers.sh
In message: 4b9edb05.4020...@freebsd.org Doug Barton do...@freebsd.org writes: : On 03/15/10 17:41, David O'Brien wrote: : I'd rather not introduce yet more special things that have to be done : before invoking newvers.sh. : : David, : : Trying to understand what you're getting at here. What's your use case : for invoking newvers.sh from the command line? AFAIK it's only every : used as part of the build process. Once by the kernel build and once for : library related stuff (IIRC). It is used in the kernel build (in a couple of different places) and in include/Makefile to generate osreldate.h. I believe the latter can be simplified to not require it. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] newvers.sh
In message: 4b9ee1ad.9080...@freebsd.org Doug Barton do...@freebsd.org writes: : I believe the latter can be simplified to not require it. : : When I last looked at it I vaguely recall thinking that not needing : newvers.sh for that purpose was a good goal, but ENOTIME. Right now it is required to set COPYRIGHT and RELDATE. The former isn't necessary (I don't believe this file could be copyrighted) and the latter could be replaced with a simple grep. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] newvers.sh
In message: 20100312171206.ga31...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: * Simplify SRCDIR calculation by directly finding the kernel sources
: based directly on one of them.
:
: Reviewed by: dhw
:
: This change does not increase the kernel build time. It also continues
: to restrict the revision to just the kernel sources, and not the whole
: tree.
:
: Timing tests by: dhw
patch omitted
David,
I have a better simplification, I think, that works for me for each of
the tests that I've done (both traditional and buildkernel builds).
The Makefile already knows where the kernel src is located. Let's use
that knowledge to make things a little simpler. This also uses the
Makefile variable SYSDIR. It should also work with non-standard sys
directories.
There's one divergence between svn and git tagging: svn does src/sys,
while git does src. This is how the previous code was before, and I
don't think I've changed that.
Can you confirm this works for you and also comment on the change
itself? It is a bigger change, but results in a simpler (I think)
newvers.sh.
Comments?
Warner
Index: conf/kern.post.mk
===
--- conf/kern.post.mk (revision 204938)
+++ conf/kern.post.mk (working copy)
@@ -244,7 +244,7 @@
${NORMAL_LINT}
vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
- MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
+ MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
vnode_if.c: $S/tools/vnode_if.awk $S/kern/vnode_if.src
${AWK} -f $S/tools/vnode_if.awk $S/kern/vnode_if.src -c
Index: conf/newvers.sh
===
--- conf/newvers.sh (revision 204938)
+++ conf/newvers.sh (working copy)
@@ -44,7 +44,7 @@
${PARAMFILE})
else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
- $(dirname $0)/../sys/param.h)
+ ${SYSDIR}/sys/param.h)
fi
@@ -84,54 +84,46 @@
fi
touch version
-v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
+v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
i=`${MAKE:-make} -V KERN_IDENT`
-case $d in
-*/sys/*)
- SRCDIR=${d##*obj}
- if [ -n $MACHINE ]; then
- SRCDIR=${SRCDIR##/$MACHINE}
+for dir in /bin /usr/bin /usr/local/bin; do
+ if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
+ svnversion=${dir}/svnversion
+ break
fi
- SRCDIR=${SRCDIR%%/sys/*}
+ if [ -d ${SYSDIR}/../.git -a -x ${dir}/git ] ; then
+ git_cmd=${dir}/git --git-dir=${SYSDIR}/../.git
+ break
+ fi
+done
- for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
- svnversion=${dir}/svnversion
- break
- fi
- if [ -d ${SRCDIR}/.git -a -x ${dir}/git ] ; then
- git_cmd=${dir}/git --git-dir=${SRCDIR}/.git
- break
- fi
- done
+if [ -n $svnversion ] ; then
+echo $svnversion
+ svn= r`cd ${SYSDIR} $svnversion`
+fi
- if [ -n $svnversion ] ; then
- svn= r`cd ${SRCDIR}/sys $svnversion`
- fi
- if [ -n $git_cmd ] ; then
- git=`$git_cmd rev-parse --verify --short HEAD 2/dev/null`
- svn=`$git_cmd svn find-rev $git 2/dev/null`
- if [ -n $svn ] ; then
+if [ -n $git_cmd ] ; then
+ git=`$git_cmd rev-parse --verify --short HEAD 2/dev/null`
+ svn=`$git_cmd svn find-rev $git 2/dev/null`
+ if [ -n $svn ] ; then
+ svn= r${svn}
+ git==${git}
+ else
+ svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
+sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
+ if [ -n $svn ] ; then
svn= r${svn}
- git==${git}
+ git=+${git}
else
- svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
-sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
- if [ -n $svn ] ; then
- svn= r${svn}
- git=+${git}
- else
- git= ${git}
- fi
+ git= ${git}
fi
- if $git_cmd --work-tree=${SRCDIR} diff-index \
- --name-only HEAD | read dummy; then
- git=${git}-dirty
- fi
fi
- ;;
-esac
+ if $git_cmd --work-tree=${SYSDIR}/.. diff-index \
+ --name-only HEAD | read dummy; then
+ git=${git}-dirty
+ fi
+fi
cat EOF vers.c
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
In message: 20100312171758.gb31...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Thu, Mar 11, 2010 at 07:24:23PM -0700, M. Warner Losh wrote: : In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com : Garrett Cooper yanef...@gmail.com writes: : : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : : mike.jaku...@intertainservices.com wrote: : : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : : As a result of importing 32-bit compatibility support for non-x86 : : 64-bit platforms, the kernel options COMPAT_IA32 has been renamed : : COMPAT_FREEBSD32 in revision 205014, so all kernel configurations : : including this option must be modified accordingly. : : : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : : : Agreed. Is it possible to change the name again because it really : : hasn't gotten much traction yet? : : What does the name matter, really? : : Yes names matter. Otherwise we would have made it DEF8931. #define : names are chosen to be self-documenting. I'd maintain that this name is self-documenting as well. Obviously you can take the what does the name matter to an extreme. However, for names that meet a minimum threshold of conformity, there reaches a point where arguing over them is counter productive. I believe that this name meets those minimum requirements. : $ grep COMPAT_FREEBSD conf/* : conf/NOTES:# Note that as a general rule, COMPAT_FREEBSDn depends on : conf/NOTES:# COMPAT_FREEBSDn+1, COMPAT_FREEBSDn+2, etc. : conf/NOTES:options COMPAT_FREEBSD4 : conf/NOTES:options COMPAT_FREEBSD5 : conf/NOTES:options COMPAT_FREEBSD6 : conf/NOTES:options COMPAT_FREEBSD7 : conf/options:COMPAT_FREEBSD4opt_compat.h : conf/options:COMPAT_FREEBSD5opt_compat.h : conf/options:COMPAT_FREEBSD6opt_compat.h : conf/options:COMPAT_FREEBSD7opt_compat.h : : COMPAT_FREEBSD32 is not the same as any of the other well established : COMPAT_FREEBSD macros. So I do see where this could lead to confusion : to users. This is where we disagree. Any confusion can be solved by documentation. See for example these other compat options: COMPAT_LINUX brings in the files in sys/compat/linux COMPAT_SVR4 brings in the files in sys/compat/svr4 and COMPAT_LINUX32 compiles the 32-bit linux support on 64-bit hosts. So the issue isn't as cut and dried as you might think. There's multiple different conventions used here in addition to your simple example. Users of 64-bit systems that will be using COMPAT_FREEBSD32 are likely to find this a natural extension of the COMPAT_LINUX32 that they are likely already using. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
In message: 7d6fde3d1003111720g7dccf93w1f51db88758a5...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Thu, Mar 11, 2010 at 5:14 PM, Scot Hetzel swhet...@gmail.com wrote: : On Thu, Mar 11, 2010 at 10:36 AM, Mike Jakubik : mike.jaku...@intertainservices.com wrote: : On 3/11/2010 9:50 AM, Nathan Whitehorn wrote: : : As a result of importing 32-bit compatibility support for non-x86 64-bit : platforms, the kernel options COMPAT_IA32 has been renamed COMPAT_FREEBSD32 : in revision 205014, so all kernel configurations including this option must : be modified accordingly. : : : That sounds a bit confusing, compatibility with FreeBSD 3.2? : : I agree that the name COMPAT_FREEBSD32 is confusing, does it mean : compatiblity with FreeBSD 3.2, FreeBSD 32 or 32-bit ARCH's. : : A better name would have been COMPAT_ARCH32 or COMPAT_32BIT_ARCH. : : Agreed. Is it possible to change the name again because it really : hasn't gotten much traction yet? What does the name matter, really? This will be documented, and mirrors the kernel source compat/freebsd32. Put another way: if everybody that's going to comment on the name would instead fix one bug from the PR database with the time they spend commenting on it, would FreeBSD be better or worse off than spending dozens of hours arguing over COMPAT_X32 vs COMPAT_Y32 vs COMPAT_FLYING_MONKEYS? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100307052949.gb70...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: : FWIW, NetBSD's charter has been to run their OS on a number of : architectures, not just a primary set of architectures; OpenBSD's : charter differs -- if we all were NetBSD or OpenBSD, then we'd all be : using the same thing. But we aren't and that's probably not going to : change anytime soon [at least not without community backing and a : : We aren't? At this point it seems any architecture an be brought into : FreeBSD without regard to critical mass or ability to support it to the : standards of our past. I do believe FreeBSD's character does not include : chasing every embedded platform where there is energy and talent for the : initial port. FreeBSD's charter includes whatever people have the time and energy to support. This means a lot more embedded platforms that I ever thought possible because FreeBSD is getting easier to move to new embedded platforms. This is a good thing, as it brings more people and energy to the project and makes the base support for those platforms better. We don't have quite as many problems as the NetBSD/OpenBSD crowd in this respect. They tend to define a new MACHIINE more often then we have (or will). The need for sys/arch is less severe here than there because we don't have 40 different MACHINEs. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
In message: 261c29701003040928h7aa70b3fm37611f974e0b9...@mail.gmail.com Miki miki@gmail.com writes: : Rising FIRMWARE_MAX from 30 to 60 did the trick ! thanks ! : Are there any reasons to have such a low default value ? I thought I'd committed this change already :) Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100307054423.ge70...@dragon.nuxi.org David O'Brien obr...@freebsd.org writes: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: : On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: : In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org, Robert : Watso n writes: : Doing that kind of rearrangement [...] would be a nightmare for anyone : with large [...] patches, so I'd say we could pretty much rule that out : outright. : : I would say that we should do it occasionally, to encourage these FreeBSD : users to contribute as many of their local changes back to the project, as : possible :-) : : Absolutely -- and rearranging a tree is a good way to invalidate all those : patches as well :-). : : No, not it isn't. Provide a script to convert path's in the diff. : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. You are joking, right? This would be a nightmare for people that integrate early and often. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 20100308000203.ga70...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: In message: 20100307054423.ge70...@dragon.nuxi.org
: David O'Brien obr...@freebsd.org writes:
: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: : On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: : In message alpine.bsf.2.00.1003050912340.5...@fledge.watson.org,
Robert
: : Watso n writes:
: : Doing that kind of rearrangement [...] would be a nightmare for
anyone
: : with large [...] patches, so I'd say we could pretty much rule that
out
: : outright.
: :
: : I would say that we should do it occasionally, to encourage these
: : FreeBSD users to contribute as many of their local changes back to
: : the project, as possible :-)
: :
: : Absolutely -- and rearranging a tree is a good way to invalidate
: : all those patches as well :-).
: :
: : No, not it isn't. Provide a script to convert path's in the diff.
: : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
:
: You are joking, right? This would be a nightmare for people that
: integrate early and often.
:
:
: No I am not joking. I was responding to the point that a large patch
: (that is a the output of running '$SCM diff') can be easily modified to
: match a new directory layout. Thus patches in GNATS aren't useless.
It seems like it would be a nightmare for anybody tracking the system
on a regular basis.
: I'm not sure what operation you are specifically speaking to . But, if
: FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
: do:
:
: cd sys
: mkdir arch
: svn add arch
: svn mv {list of dirs} arch
: svn ci
:
: and be done with it. Branches would merge that change - get a trivial
: tree conflict, resolve it - and move on with life.
And everybody who was tracking FreeBSD with their own changes would
have to scramble. It wouldn't be trivial by any stretch of the
imagination. The project is much larger than svn, and svn doesn't
lend itself well to having external agents track it.
: I would expect folks working in project branches to do the same.
:
: For merging changes from FreeBSD HEAD to FreeBSD stable - that is
: trivial:
:
: cd sys
: svn merge -c $GRN ^/head/sys/arch/amd64 amd64
: svn ci
:
: Subversion makes this a lot easier than CVS did.
Just because the task is doable with svn, where it was impossible with
CVS doesn't mean there wouldn't be a significant amount of pain to the
folks using FreeBSD. It is cool that Juniper kinda has it worked out,
but even there I'm skeptical about your claims. Especially since
Juniper imports source rarely, where as other firms do it more often,
and there'd be more pain for them.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: newfs failure on -current
In message: 98a59be81003040504x6e97fbaeqeb10f8ea7bedb...@mail.gmail.com
C. Jayachandran c.jayachand...@gmail.com writes:
: I'm testing this on the mips platform, but I think there is an issue
: with change that made sectorsize int64_t, because the ioctl
: DIOCGSECTORSIZE used to read sector size seems to take u_int. This
: quick change fixes it for me (sample patch - may be whitespace
: damaged).
:
: Index: sbin/newfs/newfs.c
: ===
: --- sbin/newfs/newfs.c (revision 204687)
: +++ sbin/newfs/newfs.c (working copy)
: @@ -327,9 +327,11 @@
: mediasize = st.st_size;
: /* set fssize from the partition */
: } else {
: + u_int tsize;
: if (sectorsize == 0)
: - if (ioctl(disk.d_fd, DIOCGSECTORSIZE, sectorsize) == -1)
: + if (ioctl(disk.d_fd, DIOCGSECTORSIZE, tsize) == -1)
: sectorsize = 0; /* back out on error for safety */
: + sectorsize = tsize;
: if (sectorsize ioctl(disk.d_fd, DIOCGMEDIASIZE,
: mediasize) != -1)
: getfssize(fssize, special, mediasize / sectorsize, reserved);
: }
:
Maybe the right change is to back out the DIOCGSECTORSIZE change due
to silent breakage like this?
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: propose: all arch move into a separate dir
In message: 401095.35021...@web59107.mail.re1.yahoo.com
paradox ddkp...@yahoo.com writes:
: iam propose all the architecture move in a separate directory
: as is done in openbsd and netbsd
:
: ie
: #mkdir /usr/src/sys/arch
: #mv -R
/usr/src/sys/{amd64,arm,i386,ia64,mips,pc98,powerpc,sparc64,sun4v,xen,x86)
/usr/src/sys/arch/
:
: Would it ever done in freebsd?
No. That ship sailed in 1995.
Besides, it would be the mother of all bikesheds. Do we want to have
a sys/cpu/{mips,x86,arm,etc} for CPU support and a sys/arch/$MACHINE
for support for machines that use that, how does that interact with
source doe that assumes certain things in machine/foo.h. Or do we
want to have better organized sub-ports. Do we want to reorg config
while we're at it, and what about modules. And sys/dev is too
crowded, let's fix that too while we're at it.
The end result: gridlock and nothing will happen.
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on mips/mips
Maybe a forgotten svn add for mipsfbsd-nat.c? Warner In message: 201002210405.o1l45ggx008...@freebsd-current.sentex.ca FreeBSD Tinderbox tinder...@freebsd.org writes: : TB --- 2010-02-21 03:38:18 - tinderbox 2.6 running on freebsd-current.sentex.ca : TB --- 2010-02-21 03:38:18 - starting HEAD tinderbox run for mips/mips : TB --- 2010-02-21 03:38:18 - cleaning the object tree : TB --- 2010-02-21 03:38:26 - cvsupping the source tree : TB --- 2010-02-21 03:38:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile : TB --- 2010-02-21 03:38:53 - building world : TB --- 2010-02-21 03:38:53 - MAKEOBJDIRPREFIX=/obj : TB --- 2010-02-21 03:38:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin : TB --- 2010-02-21 03:38:53 - TARGET=mips : TB --- 2010-02-21 03:38:53 - TARGET_ARCH=mips : TB --- 2010-02-21 03:38:53 - TZ=UTC : TB --- 2010-02-21 03:38:53 - __MAKE_CONF=/dev/null : TB --- 2010-02-21 03:38:53 - cd /src : TB --- 2010-02-21 03:38:53 - /usr/bin/make -B buildworld : World build started on Sun Feb 21 03:38:54 UTC 2010 : Rebuilding the temporary build tree : stage 1.1: legacy release compatibility shims : stage 1.2: bootstrap tools : stage 2.1: cleaning up the object tree : stage 2.2: rebuilding the object tree : stage 2.3: build tools : stage 3: cross tools : stage 4.1: building includes : stage 4.2: building libraries : stage 4.3: make dependencies : [...] : Hunk #2 succeeded at 51. : done : yacc -d -o jv-exp.c /src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/jv-exp.y : yacc -d -o m2-exp.c /src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/m2-exp.y : yacc -d -o objc-exp.c /src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/objc-exp.y : yacc: 5 shift/reduce conflicts : yacc -d -o p-exp.c /src/gnu/usr.bin/gdb/libgdb/../../../../contrib/gdb/gdb/p-exp.y : make: don't know how to make mipsfbsd-nat.c. Stop : *** Error code 2 : : Stop in /src/gnu/usr.bin/gdb. : *** Error code 1 : : Stop in /src/gnu/usr.bin. : *** Error code 1 : : Stop in /src/gnu. : *** Error code 1 : : Stop in /src. : *** Error code 1 : : Stop in /src. : *** Error code 1 : : Stop in /src. : TB --- 2010-02-21 04:05:42 - WARNING: /usr/bin/make returned exit code 1 : TB --- 2010-02-21 04:05:42 - ERROR: failed to build world : TB --- 2010-02-21 04:05:42 - 1108.92 user 295.22 system 1643.80 real : : : http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full : ___ : freebsd-m...@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-mips : To unsubscribe, send any mail to freebsd-mips-unsubscr...@freebsd.org : : ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ATA_CAM-ed mvsata(4) on OpenRD-client
In message: 4b7ef63c.7030...@freebsd.org Alexander Motin m...@freebsd.org writes: : Hi. : : Norikatsu Shigemura wrote: : I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to : make mvsata(4) ATA_CAM, like following: : : But I got following panic, my I help you? : In this time, I attached no devices to SATA/eSATA port. : - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : sata0: Marvell Integrated SATA Controller at mem 0xf108-0xf1085fff irq 21 on mbus0 : sata0: [MPSAFE] : sata0: [ITHREAD] : ata0: Marvell Integrated SATA Channel on sata0 : ata0: [MPSAFE] : ata0: [ITHREAD] : ata1: Marvell Integrated SATA Channel on sata0 : ata1: [MPSAFE] : ata1: [ITHREAD] : spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long : panic: spin lock held too long : KDB: enter: panic : [ thread pid 0 tid 10 ] : Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror r15]! : db : : A bit unexpected. : : - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : : So I tried to get following information: : - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10 : scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c) : rsp=0xc0d62d14 rfp=0xc0d62d3c : r10=0xc0d62d70 r9=0xc09039a8 : r8=0x r7=0x0851 r6=0xc0b47100 r5=0x : r4=0xc35dd974 : _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10 : scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c) : rsp=0xc0d62d40 rfp=0xc0d62d68 : r8=0xc0bde8f0 r7=0xc090d4a4 : r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240 : xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c : scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238) : rsp=0xc0d62d6c rfp=0xc0d62d88 : r10=0xc0bde904 r9=0xc0b47100 : r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x : r4=0x0001 : xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218 : scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0) : rsp=0xc0d62d8c rfp=0xc0d62e34 : xpt_register_async() at 0xc0905880 = xpt_register_async+0x10 : scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198) : rsp=0xc0d62e38 rfp=0xc0d62e44 : r10=0x r9=0x : r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0 : r4=0x001c : : Even more unexpected. I've searched all sources for xpt_sim_opened() : call and found only one place - in atapi-cam.c, which shouldn't be used : in your case. You are using different sources, or there is a garbage in : stack? IIRC, I got better stack traces when I used the kernel.tramp kernel... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
In message: 20100219031200.gy43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: : On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: : On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: :On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: :[55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core :GNU gdb 6.1.1 [FreeBSD] :Copyright 2004 Free Software Foundation, Inc. :GDB is free software, covered by the GNU General Public License, and you are :welcome to change it and/or distribute copies of it under certain conditions. :Type show copying to see the conditions. :There is absolutely no warranty for GDB. Type show warranty for details. :This GDB was configured as arm-marcel-freebsd...(no debugging symbols found)... :Core was generated by `named'. :Program terminated with signal 5, Trace/breakpoint trap. :Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. :Loaded symbols for /lib/libcrypto.so.6 :Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. :Loaded symbols for /lib/libthr.so.3 :Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. :Loaded symbols for /lib/libc.so.7 :Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. :Loaded symbols for /libexec/ld-elf.so.1 :#0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 :[New Thread 20804280 (LWP 100062)] :[New Thread 20804140 (LWP 100052)] :(gdb) bt :#0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 :#1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 :#2 0x20349da4 in pthread_create () from /lib/libthr.so.3 :#3 0x00164cb8 in ?? () :(gdb) : :Do we have a general threading problem on ARM? : : I see two different type a crashes. : Both have in common that one or more threads are in _umtx_op. : Unfortunately I don't know enough details about those things to isolate : any more. : : the one from above: : #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 : [New Thread 20804280 (LWP 100062)] : [New Thread 20804140 (LWP 100052)] : (gdb) bt : #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 : #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 : #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 : #3 0x00164cb8 in ?? () : (gdb) thread 1 : [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 : #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 : #5 0x00164cb8 in ?? () : : And another, which is what I get most of the time: : (gdb) thread 1 : [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 : (gdb) bt : #0 0x20435f28 in kevent () from /lib/libc.so.7 : #1 0x0014f2dc in ?? () : (gdb) thread 2 : [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 : #4 0x in ?? () : (gdb) thread 3 : [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 : #4 0x2092d008 in ?? () : (gdb) thread 4 : [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () : (gdb) bt : #0 0x0015755c in ?? () : : Compile and install ld-elf.so, libc and libthr with debugging symbols: : (cd libexec/rtld-elf make all install DEBUG_FLAGS=-g) : (cd lib/libc make all install DEBUG_FLAGS=-g) : (cd lib/libthr make all install DEBUG_FLAGS=-g) : : Then repeat the crash and try to see where in code does it happen. : : Currently I can only get this type. : I've started the unstripped named to get all the function names. : : (gdb) thread 1 : [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435308 in kevent () at kevent.S:3 : 3 RSYSCALL(kevent) : Current language: auto; currently asm : (gdb) bt : #0 0x20435308 in kevent () at kevent.S:3 : #1 0x0014f2dc
Re: bind fails with sig11 on start / pthread failure on ARM?
In message: 20100219033000.gz43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Warner - it names you in the copyright, so very likely you know this code. : I will build a debug version of bind, but as usual it will take some : time... Make sure that the code matches our current atomics code... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lang/perl5.10 broken
In message: 20100217152557.gw43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Not sure if this is ARM related or not. ... : *** Signal 11 Silly question: do you have enough swap space enabled? Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
In message: 20100216123646.fc741643.s...@freebsd.org Stanislav Sedov s...@freebsd.org writes: : On Tue, 16 Feb 2010 19:39:51 +0100 : Bernd Walter ti...@cicely7.cicely.de mentioned: : : : Do we have a general threading problem on ARM? : : : I don't think so. I used a lot of threaded applications on arm, and they : worked fine. However, this might be some obscure bug. I know that 6.x ARM worked with threads no problem. We had dozens of threads in our control programs. The one caveat is that I've found bugs in the atomic routines in the past, and have had people submit fixes as well. All of those should be in the tree, but since some arrived when I was crazy busy for Cisco, they might have fallen on the floor. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Rudolf Cejka [EMAIL PROTECTED] writes: : : Hello, : I'm trying to boot 5.2-BETA with aac, which panics as has been : reported here and I can confirm panics too. I would like to try : boot with aac disabled for now, but it does not work for me. : There is suggested in device.hints(5), that I can do : set hint.driver.unit.disabled=1 : however it does not work for me - neither in loader prompt, nor : in /boot/device.hints. : : Exactly, I'm trying : hint.aac.0.disabled=1 : in /boot/device.hints or : set hint.aac.0.disabled=1 : in loader prompt. You can't disable pci devices. You lose. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4 - 5 Problem
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : On Tue, Dec 02, 2003 at 04:33:42PM -, Lawrence Farr wrote: : : I've just tried this again, and noticed an error message that I'd : missed: : : install -p -m 555 -o root -g wheel kernel /boot/kernel : *** Signal 12 : : This usually means you've tried to update something out of the correct : order. Signal 12 means thaqt you didn't upgrade your kernel first. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : However, having a general mechanism for disabling newbus devices would be : really nice. Agreed. But today and 5.2 you lose. However, it isn't easy. What does disabled mean? Don't attach? Don't even probe? If you don't probe, then how do you know that the device is aac.0? If you do probe, then you get ISA probe routines called that can be 'destructive'. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Wilko Bulte [EMAIL PROTECTED] writes: : On Tue, Dec 02, 2003 at 11:11:48AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Scott Long [EMAIL PROTECTED] writes: : : However, having a general mechanism for disabling newbus devices would be : : really nice. : : Agreed. But today and 5.2 you lose. However, it isn't easy. What : does disabled mean? Don't attach? Don't even probe? If you don't : : You could disable the driver altogether. Assuming that is what : is desired. That would be the next best thing. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCMCIA CDROM drives
In message: [EMAIL PROTECTED] Justin Smith [EMAIL PROTECTED] writes: : Does the generic kernel have drivers for these. I got such a cdrom drive : for my Portege 3500 tablet PC and it appeared to be able to boot the 5.2 : beta mini-install CD. I wasn't ready to proceed with a complete : install, so I shut it off at this point. Yes and no. 5.2 current likely will work. 5.2-beta won't because there were some issues with ata's pccard attachment. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA and related ports issues
In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : I have a better idea, then we perhaps need something like a : wrapper script that is part of the FreeBSD basic system under /etc/rc.d : that checks for the start script under $LOCALBASE/etc/rc.d : and starts it very early. Only if $LOCALBASE is acutally mounted, which can be a problem depending on when 'very early' is. :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAJOR number
In message: [EMAIL PROTECTED] John-Mark Gurney [EMAIL PROTECTED] writes: : There are still major numbers for a few devices that may are standard : (such as zero/null), but not common... I've already assigned him one. : I've read that FreeBSD doesn't use them any more. : But we may need it to not interfere with other device : drivers in previous releases of FreeBSD. : : so, you are planning do do 4.x and earlier releases of your driver? Yes. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anybody using gp driver?
In message: [EMAIL PROTECTED] Gerrit Kühn [EMAIL PROTECTED] writes: : but it certainly won't be based on this driver! : : Oops, is it /that/ bad? I can't convince myself that it would have any chance of working. That's why I asked. : The questions here are only 'does this driver work?' and 'is anybody : able to use it?' : : Well, as I said above: I'm not using it so far, but given some time I may be : able to find out if it's still working. Please let me know if you succeed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
In message: [EMAIL PROTECTED] Andre Oppermann [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Andre Oppermann [EMAIL PROTECTED] writes: : : Please try the attached patch which should fix it. : : I've been having crashes all the time since the hostcache went into : the tree. I've been running a few hours with this patch (in which : time I should have had a crash). I think it makes it better. : : Thank you for testing. I've sent the patch to re@ for approval. I was able to run overnight. First time since the hostcache code went in, so it definitely helps things! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : What are people doing to make buildworld so slow? using gcc 3 :-) Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Anybody using gp driver?
I'm wondering if anybody is using, or even able to use, the gpib driver. It uses the old ISA shims, and is one of the drivers that no one has acked working in when I ask about the old isa shim drivers. So, I'm wondering if anybody is actually using the gp driver on a current machine (or even a 4.x stable machine) at all. It has been a long time since we've received reports of its working. I'd like to remove it from the tree if it isn't working at all or if no one is uing it. I'd also like to say that I'd love to see a good, and proper gpib framework in the tree, but it certainly won't be based on this driver! The questions here are only 'does this driver work?' and 'is anybody able to use it?' Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: requesting vinum help
In message: [EMAIL PROTECTED]
Terry Lambert [EMAIL PROTECTED] writes:
: There is no such thing as bit rot; there is only code that
: is unmaintained by the people who change interfaces out from
: under it.
Actually, there is such a thing as code rot. Over time the
fundamental assumptions that a piece of code makes are tested as the
interfaces and subsystems it depends on evolve and change. These
assumptions can be very subtle sometimes, and difficult to find and
test.
Vinum is hard to test because it requires multiple disks to test
with. In addition, many problems with vinum are shown only under
heavy work load, which may be difficult to simulate.
Put in historical terms, the following code used to work:
void foo(char *c)
{
*c = 'F';
}
int
main(int argc, char **argv)
{
foo(fred);
}
but subtle changes in compiler technology over the years have made
this code fail now.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fix for 5.2-BETA lockup problems
In message: [EMAIL PROTECTED] Andre Oppermann [EMAIL PROTECTED] writes: : Please try the attached patch which should fix it. I've been having crashes all the time since the hostcache went into the tree. I've been running a few hours with this patch (in which time I should have had a crash). I think it makes it better. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic inserting CF card.
In message: [EMAIL PROTECTED] Don Lewis [EMAIL PROTECTED] writes: : Offhand I'd guess that adp-heads and/or adp-sectors is zero. If : you've got a core file, try backtracking from there with gdb, otherwise : sprinkle some printf's around. Either this calculation is new, or some : recent change is causing the heads and sectors to be initialized to : zero. I have patches in my tree that prevent the panic. However, they prevent the panic by not dividing by zero, rather than fixing the underlying problem. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : time make -j 4 buildworld Hmmm, more jobs. : They were on a single CPU Athlon 500 with 320MB of RAM. 320MB is not enough RAM not to swap. I did some preliminary testing last night (which I lost due to a crash) that showed that a simple 'make buildworld' slowed down 1-2% depending on how many times I ran them. However, make -s buildworld (with or without -j 4 on my dual athlon) was faster than a normal buildworld, but the dynamic /bin/sh was more like 5-7% slower. The difference here is that there are fewer context switches (and I guess less chance for parallelization). In all make buildworld, the number of page faults was 10x for the dynamic case than for the static case. However, having said that, I think everybody realizes the following: 1) Dynamic linking is slower. 2) Speed improvements in this area are possible, as demonstrated by other projects. 3) PIC code is slower than non-PIC code, in general, and also gcc runs about 5-10% slower depending on if you are running out of a shared library or a static one. shared libraries must use PIC code (at this time). 4) People like to complain. Warner P.S. One interesting note: /bin/sh when linked statically with libedit and libncurses but dynamically with libc runs about 10% slower for my /usr/bin/true/true tests than when all three are dynamically linked. So it seems that not all dynamic linking is bad for performance. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Announcing 5.2-BETA
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : Please help us make 5.2 the best FreeBSD release ever! Well Done! Thanks for all your (both personally and the whole re@ team) efforts in making this happen! Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Peter Jeremy [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote: : H, It looks like the hit is less than 10% in the fork intensive : test I just wrote: : : #!/bin/sh : for i in 0 1 2 3 4 5 6 7 8 9; do : for j in 0 1 2 3 4 5 6 7 8 9; do : for k in 0 1 2 3 4 5 6 7 8 9; do : for l in 0 1 2 3 4 5 6 7 8 9; do : for m in 0 1 2 3 4 5 6 7 8 9; do : for n in 0 1 2 3 4 5 6 7 8 9; do : true; : done; done; done; done; done; done; : : Unless you've done something wierd to your /bin/sh, true is a : builtin. This test just to measures the ongoing runtime overhead : of a dynamic executable (ie PIC code). Drew's test was measuring : the startup overhead. True. However, I get very similar numbers of I change it to /usr/bin/true (12% slower). /bin/sh usually fork+exec things other /bin/sh. : Clearly dynamic is slower, but it is more like 11% slower (10.67%) on : the average than 40% slower. I think this would be a more typical : usage pattern. : : You have measured different things. Drew's test shows that a dynamic : /bin/sh tahes about 40% longer to start. Your test shows that once : started, it runs about 11% slower. And the 11% slower is _very_ : worrying since it is probably more widely applicable than just /bin/sh. Dynamically linked prorgrams tend to be a few percent slower than their static counterparts due to PIC code typically being slower than non-PIC code. There's nothing new here. Clearly there are problems to look into, but it isn't the end of the world. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] boyd, rounin [EMAIL PROTECTED] writes: : i see that there some doubt about whether running lots of : shell scripts ever happens. what happens when you : use make? lots of shells get run and they run small : (one line?) scripts. make buildworld slows down 1% when you switch from static /bin/sh to dynamic. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
In message: [EMAIL PROTECTED] walt [EMAIL PROTECTED] writes: : ...Because changes are applied that will allow smooth upgrades : when the kernel is built after the new system is built, but before it is : installed, make world is increasingly unlikely to work... : : The recent statfs changes demonstrated why the 'makeworld' 'makekernel' : sequence sometimes fails :-( ? We recommend make buildworld make buildkernel make installkernel reboot -s - single user make installworld In the build man page, as well as UPDATING. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA
In message: [EMAIL PROTECTED] Larry Rosenman [EMAIL PROTECTED] writes: : sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0 : sio2: type 16550A : sio2: unable to activate interrupt in fast mode - using normal mode : The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this : from on 4.8. : : What debug/help do y'all need to fix it? Hmm, sounds like an interrupt storm. What kind of pccard bridge do you have? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Michael Edenfield [EMAIL PROTECTED] writes: : * M. Warner Losh [EMAIL PROTECTED] [031125 12:07]: : In message: [EMAIL PROTECTED] : boyd, rounin [EMAIL PROTECTED] writes: : : i see that there some doubt about whether running lots of : : shell scripts ever happens. what happens when you : : use make? lots of shells get run and they run small : : (one line?) scripts. : : make buildworld slows down 1% when you switch from static /bin/sh to : dynamic. : : I'm all for dynamic / and dynamic /bin/sh, but this doesn't even come : close to what I observed on my systems. I see anywhere from 15% to 20% : slowdown in buildworld, depending on how bad my hardware already is. I : posted my most recent numbers earlier. My dual athlon make -j 4 buildworld differed by about 16-20 seconds on a 36 minute buildworld. : It's difficult to get lots of these numbers, unfortunately, because it : takes a good 6-8 hours just to complete one build. But the numbers are : fairly consistant across the different degrees of old crappy hardware I : have. So you are seeing a about an hour slowdown (16% slowdown on 6 hours is 1 hour) from before/after? Or are you seeing an hour slowdown from 4.x - 5.2-beta? Also, so we can characterize where the suckage happens, how much RAM/CPU does your system have? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB 1.0 IDE to ATAPI drive enclosure failure
In message: [EMAIL PROTECTED] Barney Wolff [EMAIL PROTECTED] writes: : Why hasn't anything been committed? Code freeze? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Dan Nelson [EMAIL PROTECTED] writes: : In the last episode (Nov 25), Daniel O'Connor said: : On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: : So.. forking a dynamic sh is roughly 40% more expensive than : forking a static copy of sh. This is embarrassing. : : I propose that we at least make /bin/sh static. (and not add a : /sbin/sh; if we must have a dynamic sh, import pdksh, or put a : dynamically linked sh in /usr/bin/sh). : : I'd greatly prefer that the the dynamic root default be backed out : until a substantial amount of this performance can be recovered. : : What _REAL WORLD_ task does this slow down? : : Try timing cd /usr/ports/www/mozilla-devel ; make clean with static : and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. Maybe you could try it with both and tell us the actual difference in wall time? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : : M. Warner Losh writes: : In message: [EMAIL PROTECTED] : Andrew Gallatin [EMAIL PROTECTED] writes: : : I'll bet a larger percentage of our users build ports than need nss or : : ldap. : : I'll bet a larger percentage of the people are ignoring this thread : than reading it since it has been so devoid of concrete numbers. : : Aside from $SUBJECT.. I'm just saying that most of the developers I'm talking to on IRC say this tread is insane, has no content and they are blowing it off because of that. A concrete, real benchmark will go a long way towards changing that. Until then, you are as good as kill filed. I don't say this to be mean or nasty. I'm just saying that people are sick to death of the arguing without any real facts. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : What qualifies as a concrete, real benchmark? I take it you don't : think Drew's qualifies. No. forkbomds are realworld. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : 1) Microbenchmark:40% worse : 2) Bootstone(*): 25% worse : 3) Ports: 16% worse Thanks for the real numbers. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
And I just did a make clean run in /usr/ports/archivers (by manually mv'ing a static and dynamic sh to /bin in turn): static: 96.63 real53.45 user39.27 sys dynamic: 112.42 real55.51 user51.62 sys The wall clock is bad (16% worse) and the system time is worse (31%). So all the worstness is in system time, or nealy all. However, you rant this test only once. : : So.. : : 1) Microbenchmark: 40% worse : 2) Bootstone(*):25% worse : 3) Ports: 16% worse H, It looks like the hit is less than 10% in the fork intensive test I just wrote: #!/bin/sh for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do for k in 0 1 2 3 4 5 6 7 8 9; do for l in 0 1 2 3 4 5 6 7 8 9; do for m in 0 1 2 3 4 5 6 7 8 9; do for n in 0 1 2 3 4 5 6 7 8 9; do true; done; done; done; done; done; done; Here's the numbers I got: x sh-s static sh + sh-d dynamic sh +--+ |x x + | |x x + + | |x x x x + + + | |x x x x + + + + + +| |x x x x x + + + + + + + +| ||___A__M_||A__M| | +--+ N Min MaxMedian AvgStddev x 20 1.27 1.31 1.31.2925 0.012085224 + 20 1.4 1.47 1.44 1.431 0.023597502 Difference at 95.0% confidence 0.1385 +/- 0.0119989 10.7157% +/- 0.928346% (Student's t, pooled s = 0.0187469) As you can see, I ran each of the tests 10 times. I timed it using a the tcsh time built-in. I ran each command once before I started timing the commands to reduce cache effects. Clearly dynamic is slower, but it is more like 11% slower (10.67%) on the average than 40% slower. I think this would be a more typical usage pattern. So things are a little bad, but it isn't the end of the world, especially for a 5.2-beta that's going out. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce M Simpson [EMAIL PROTECTED] writes: : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: : * /rescue/vi is currently unusable if /usr is missing because : the termcap database is in /usr. One possibility : would be to build a couple of default termcap entries : into ncurses or into vi. : : My suggested candidates are vt100 and cons25. The comconsole port installs : an /etc/ttys entry using vt100. This is also the default terminal type for : most dialup entries. Timing Solutions uses the following minimal termcap for its embedded applications. It has a number of terminals that it supports, while still being tiny. it is 3.5k in size, which was the goal ( 4k block size we were using). One could SED this down by another 140 bytes or so. Removing the comments and the verbose names would net another 300 odd bytes. The terminals supported are vt220, vt102, vt100, xterm, xterms, cons25w, cons25 and ansi. This seems a reasonable number: neither too few, nor too many. It lets people connect 'normal' terminals to the serial port (most PCs have vt100/vt220 emulation), as well as PC to PC connection on the console or xterm. I'd be happy to commit this as /etc/termcap.tiny. vi could then look for both termcap and termcap.tiny and things would just work. Comments? Warner vt200|vt220|vt220am|vt200am|dec-vt220|dec-vt200|dec vt200 series with jump scroll:\ :@7=\E[4~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kh=\E[1~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:\ :F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:tc=vt102: vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ :do=2\E[B:co#80:li#24:cl=50\E[H\E[J:sf=2*\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :if=/usr/share/tabset/vt100:nw=2\EE:ho=\E[H:\ :as=2\E(0:ae=2\E(B:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:ks=\E[?1h\E=:ke=\E[?1l\E:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:\ :k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOt:\ :k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:k;=\EOx:@8=\EOM:\ :K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:pt:sr=2*\EM:vt#3:xn:\ :sc=2\E7:rc=2\E8:cs=5\E[%i%d;%dr:UP=2\E[%dA:DO=2\E[%dB:RI=2\E[%dC:\ :LE=2\E[%dD:ct=2\E[3g:st=2\EH:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:\ :RA=\E[?7l:SA=\E[?7h: vt102|dec-vt102-am|vt102am|vt100 w/adv. video:\ :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\ :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:tc=vt100-np: vt100-np|dec-vt100-np|vt100 with no padding (for psl games):\ :do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:\ :cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:\ :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:\ :LE=\E[%dD:ct=\E[3g:st=\EH:tc=vt100-am: xterm|vs100|xterm terminal emulator (X window system):\ :li#65:\ :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\ :rs=\E\E[?1;3;4;5l\E[?7;8h:\ :tc=vt220: xterms|vs100s|xterm terminal emulator (small)(X window system):\ :is=\E\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :li#24:tc=xterm: # for syscons # common entry without semigraphics cons25w|ansiw|ansi80x25-raw:\ :al=\E[L:am:bs:NP:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:\ :dc=\E[P:dl=\E[M:do=\E[B:bt=\E[Z:ho=\E[H:ic=\E[@:li#25:cb=\E[1K:\ :ms:nd=\E[C:pt:rs=\E[x\E[m\Ec:so=\E[7m:se=\E[m:up=\E[A:\ :pa#64:Co#8:AF=\E[3%dm:AB=\E[4%dm:op=\E[x:sc=\E7:rc=\E8:\ :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:k6=\E[R:k7=\E[S:k8=\E[T:\ :k9=\E[U:k;=\E[V:F1=\E[W:F2=\E[X:K2=\E[E:nw=\E[E:ec=\E[%dX:\ :kb=^H:kh=\E[H:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:le=^H:eo:sf=\E[S:sr=\E[T:\ :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ :IC=\E[%d@:DC=\E[%dP:SF=\E[%dS:SR=\E[%dT:AL=\E[%dL:DL=\E[%dM:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:cv=\E[%i%dd:ch=\E[%i%d`:bw:\ :mb=\E[5m:md=\E[1m:mh=\E[30;1m:mr=\E[7m:me=\E[m:bl=^G:ut:it#8:km: cons25|ansis|ansi80x25:\ :ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263n\305`^Da\260f\370g\361~\371.^Y-^Xh\261I^U0\333y\363z\362:\ :tc=cons25w: dosansi|ANSI.SYS standard crt:\ :am:bs:ce=\E[K:cl=\E[2J:cm=\E[%i%d;%dH:co#80:\ :do=\E[B:li#25:mi:nd=\E[C:\ :se=\E[m:so=\E[7m:up=\E[A:us=\E[4m:ue=\E[m:\ :md=\E[1m:mh=\E[m:mb=\E[5m:me=\E[m:\ :kh=\EG:kb=^h:ku=\EH:kd=\EP:kl=\EK:kr=\EM:\ :k1=\E;:k2=\E:k3=\E=:k4=\E:k5=\E?:\
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : On Sat, 22 Nov 2003, M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Bruce M Simpson [EMAIL PROTECTED] writes: : : On Thu, Nov 20, 2003 at 04:31:10PM -0800, Tim Kientzle wrote: : : * /rescue/vi is currently unusable if /usr is missing because : : the termcap database is in /usr. One possibility : : would be to build a couple of default termcap entries : : into ncurses or into vi. : : : : My suggested candidates are vt100 and cons25. The comconsole port installs : : an /etc/ttys entry using vt100. This is also the default terminal type for : : most dialup entries. : : Timing Solutions uses the following minimal termcap for its embedded : applications. It has a number of terminals that it supports, while : still being tiny. it is 3.5k in size, which was the goal ( 4k block : size we were using). One could SED this down by another 140 bytes or : so. Removing the comments and the verbose names would net another 300 : odd bytes. : : What's wrong with FreeBSD's /usr/src/etc/termcap.small, except it is : twice as large and has a weird selection of entries (zillions of : variants of cons25, dosansi and pc3). Mine is better because it has a more representative slice of currently used terminal types. Maybe we should replace termcap.small with mine (maybe with the copyright notice). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Bruce Evans [EMAIL PROTECTED] writes: : Mine is better because it has a more representative slice of currently : used terminal types. Maybe we should replace termcap.small with mine : (maybe with the copyright notice). : : I agree. termcap.small is amazingly uncurrent. However, perhaps some : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : vi only needs a few capabilities. I think we mostly use copies of large : termcap entries because copying the whole things is easier. You have a good point. My termcap was done so that we could run a number of applications... Grepping seems unsatisfying to find out which keys are used. Do you have a list? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
In message: [EMAIL PROTECTED] Richard Coleman [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : : I agree. termcap.small is amazingly uncurrent. However, perhaps some : : merging and reducing is in order. Why is a full cons25 or vt2xx needed? : : vi only needs a few capabilities. I think we mostly use copies of large : : termcap entries because copying the whole things is easier. : : You have a good point. My termcap was done so that we could run a : number of applications... : : Grepping seems unsatisfying to find out which keys are used. Do you : have a list? : : Warner : : Is the extra maintenance worth it to save a few hundred bytes? Generating them automatically can be kind of difficult. termcap doesn't change that often. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAJOR number
In message: [EMAIL PROTECTED] Roman Kurakin [EMAIL PROTECTED] writes: : ??? ce Cronyx Tau-32 E1 adapter I've checked -stable and -current. You may have: 185 ce Cronyx Tau-32 E1 adapeter [EMAIL PROTECTED] for your adapter. Sorry for the hassles in getting it. I'll be checking in this shortly, but we're in a freeze right now so it may take a little while. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message: [EMAIL PROTECTED] boyd, rounin [EMAIL PROTECTED] writes: : Yes, working fine here. What should the problem be? : : the day /lib gets smashed. /rescue/sh Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : It really doesn't make sense to arbitrarily cut-off a : discussion especially when a decision might be incorrect. I'd say that good technical discussion about why this is wrong would be good. However, emotional ones should be left behind. Except for John's message, most of the earlier messages have been more emotional than technical. John, do you have any good set of benchmarks that people can run to illustrate your point? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recovery? recent make world rendered system unusable (64 bit change)
In message: [EMAIL PROTECTED] Chris Shenton [EMAIL PROTECTED] writes: : I'm looking for recommendations on how to recover, hopefully without : trashing my critical system files like /etc/passwd. Ideally, I guess : I'd like a way to replace all the broken binaries and any related : libraries without overwriting other files. Grab a recent snapshot. Boot off of that with the fixit functionality. Fix things. Chances are good that you'll be able to build a new kernel with the kernel that you booted... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
In message: [EMAIL PROTECTED] Garance A Drosihn [EMAIL PROTECTED] writes: : At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote: : Of course, there was a development resource limitation, : but the decision (discussion) was made approx 6months ago? : (Enough time to solve the problem without a GLOBAL : performance hit.) : : Well, yes, perhaps. But there is that issue of development : resource limitation. Back when we did debate this publicly, : no one stepped forward and said I have the time to implement : a better solution. Thus, we went with this solution. And it still isn't too late for someone to step forward with a better solution. Or to develop one. The main reason we went with dynamic / was to be able to get dynamic libary/loading support for newer authentication and user technologies. The size advantage is one minor added benefit. : Speaking as to what we can do right now, I would not want to : delay the 5.x-stable branch by adding some project right now : to start writing an alternate PAM/NSS solution. If someone : wants to write one for 6.0, that would be good. There is : nothing in this solution which would cause problems for : some later solution. Disk space will only get cheaper. I tend to agree. If there's a performance regression with the dynamic change, then the right solution isn't to yell 'back it out', but rather to build a better mouse trap. FreeBSD gets better through these tentions and people scratching an itch. FreeBSD doesn't get better by stagnating and never changing anything. With all things it is a balance. Sometimes it tips a little this way or that. As our user base changes, the balance point changes. If FreeBSD isn't willing to adapt to the new balance point, it runs the risk of losing relevance. Finally, I'll just observe that most of our users care most about apache, which has been dynamically linked for a long time. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help getting Realtek 8129-based NIC recognized?
Have you tried re? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CF cards / ATAng / interrupt code still broken
I've also had problems with CF cards and ATAng :-( Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
