Re: UMA lock
In message [EMAIL PROTECTED], Peter Wemm writes: As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory condition which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Peter Wemm wrote: I think _sleeping_ is a problem, but allocation with M_WAITOK shouldn't be, given it's strange definition of waiting. This is one of those hacks that John Baldwin was talking about earlier... As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory condition which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. M_WAIT became M_WAITOK. Unless M_SLEEPOK becomes M_SLEEP, I don't think it really matters: it's not going to wait indefinitely, like you'd want it to, so eventually, it's going to time out. You might get some big latencies along with some kernel printf's about inverted locks, but it shouldn't end up being fatal, like a real blocking wait would be, right? Or has M_WAITOK gone back to meaning M_WAIT, instead of M_WAIT_IF_YOU_FEEL_LIKE_IT_OTHERWISE_MAKE_ME_CHECK_FOR_NULL again? Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? -- Terry Never solve a vast problem in a half-vast way To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory condition which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... I'm with Poul on this one, Peter: M_WAITOK doesn't mean what you think it means: it's doesn't mean tsleep may be called, and M_NOWAIT doesn't mean tsleep() _won't_ be called, in practice. It's either incredibly badly named, or it's incredibly badly implemented -- I would argue the latter, actually, since even if it's completely orthogonal, you're screwed because it means you have two call conversion systems, without a WITNESS intersection to detect deadly embraces. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildworld failure
Hello, I have trouble building world: -- stage 2: cleaning up the object tree -- cd /opt/freebsd/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 OBJFORMAT_PATH=/usr/obj/opt/freebsd/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/opt/freebsd/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/opt/freebsd/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/opt/freebsd/src/i386/usr/share/tmac DESTDIR=/usr/obj/opt/freebsd/src/i386 INSTALL=sh /opt/freebsd/src/tools/install.sh PATH=/usr/obj/opt/freebsd/src/i386/usr/sbin:/usr/obj/opt/freebsd/src/i386/usr/bin:/usr/obj/opt/freebsd/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 par-cleandir === share/info === include === include/arpa cd: getcwd() failed: No such file or directory *** Error code 2 Then I have done this: rm -fr /usr/src/* cvsup -L 2 -g /etc/current-supfile after downloading over 300 Mbs of sources I got same error :-( If I repeat make buildworld then it fails with same error in different directory. -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /etc/periodic is hopefully perl-free [was: Perl script rewrites]
On 2002-05-19 12:20, Mark Murray wrote: What I've done so far (and only slightly tested) is available at http://www.FreeBSD.org/~keramida/diff/periodic.diff Untested, but seemingly complete, the patch is available for review at the address mentioned above. I am thinking a nice way to test this would be: This looks excellent! For my miniscule data set and manual test, things seem OK. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory conditio n which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... No, this is a bug in UMA. In certain circumstances, it calls itself with M_WAITOK even when it itself was called with M_NOWAIT. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: preemption across processors
On Tue, 28 May 2002 14:56:04 -0400 (EDT),
John Baldwin [EMAIL PROTECTED] said:
The prototype patch is at:
http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
And the p4 depot
//depot/user/tanimura/ippreempt/...
The patch is for only i386 at the moment.
The following is the brief description of the patch:
jhb I would prefer that this was hung off the preemption stuff I've already done
jhb rather than reinventing it. I would also prefer that we get a preemptive
jhb kernel w/o this done stable before adding extra complication.
Or I can integrate your work in //depot/user/jhb/preemption/... into
//depot/user/tanimura/ippreempt/... .
Miscellaneous stuff:
If a thread spins for an adaptive mutex, propagate its priority to the
owner thread of the mutex. This prevents preemption of the owner
thread by a thread with the priority in between the owner thread and
the spinning thread.
jhb Ewww, I'd rather avoid this if possible. This is just an optimization,
jhb but it would depend on how complicated this makes the mutex code to see
jhb if it's worth it or not.
The owner thread of an adaptive mutex never lowers its priority until
it releases the mutex. We should thus bump the priority of the owner
thread not during but just before spinning. However, it is difficult
to know if the current thread can spin prior to calling
_obtain_lock().
In addition, I would say that spinning can be done even more
efficiently. At the moment, we try an atomic test-and-set
instruction in each spin. As another thread holds the mutex, we are
likely to execute an expensive test-and-set instruction quite a lot of
times.
Maybe we can solve both of the issues above by roughly checking if a
thread can keep spinning without acquiring any locks, in the similar
way as we do for a spin mutex. First, test the following conditions:
- The owner of the mutex has not changed.
- The owner is on a processor.
If both of the conditions satisfy, keep spinning. Otherwise, try
test-and-set. The pseudo-code would look like this:
while (!_obtain_lock(m, td)) {
mtx_lock_spin(sched_lock);
if (unowned(m)) {
mutex_unlock_spin(sched_lock);
continue;
}
owner = mtx_owner(m);
if (oncpu(owner)) {
bump_priority(owner, td);
/* Spin without holding sched_lock. */
critical_enter();
mtx_unlock_spin(sched_lock);
while (owner == mtx_owner(m) oncpu(owner)) {
/* Handle interrupts. */
critical_exit();
/* Spin. */
critical_enter();
}
critical_exit();
continue;
}
sleep(td);
mutex_unlock_spin(sched_lock);
}
The code above does not use any test-and-set instructions, nor does it
keep bumping the priority of the owner during spinning.
--
Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gdb52 patch for your .gdbinit files
As you can see, the patch is trivial, so I have no clue why this wasn't left alone when they modified symfile.c. If I can be bothered I'll submit it to them. Hmm. Looking at this patch, it seems it's complaining about being handed a hex value where it's looking for an address. I'd guess that this is in the wrong place. Where does it happen in the macros? Have a look at the gdb sources in FreeBSD-CURRENT and notice the fact that they removed the call to parse_and_eval_address and rolled their own. An address like $file-address+0xabcdef should be possible, but isn't in the distribution of 5.2. After the patch it is. i've filed the patch with an already open bug report on this on GNU gdb 5.2 Nick Greg # diff -wu gdb-5.2/gdb/symfile.c~ gdb-5.2/gdb/symfile.c --- gdb-5.2/gdb/symfile.c~ Tue May 28 15:51:37 2002 +++ gdb-5.2/gdb/symfile.c Tue May 28 15:51:06 2002 @@ -1546,11 +1546,15 @@ char *val = sect_opts[i].value; char *sec = sect_opts[i].name; +#ifdef 0 val = sect_opts[i].value; if (val[0] == '0' val[1] == 'x') addr = strtoul (val+2, NULL, 16); else addr = strtoul (val, NULL, 10); +#else + addr = parse_and_eval_address(val); +#endif /* Here we store the section offsets in the order they were entered on the command line. */ -- See complete headers for address and phone numbers -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Terry Lambert wrote: Peter Wemm wrote: I think _sleeping_ is a problem, but allocation with M_WAITOK shouldn't be, given it's strange definition of waiting. This is one of those hacks that John Baldwin was talking about earlier... As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory conditi on which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. M_WAIT became M_WAITOK. Unless M_SLEEPOK becomes M_SLEEP, I don't think it really matters: it's not going to wait indefinitely, like you'd want it to, so eventually, it's going to time out. You might get some big latencies along with some kernel printf's about inverted locks, but it shouldn't end up being fatal, like a real blocking wait would be, right? Or has M_WAITOK gone back to meaning M_WAIT, instead of M_WAIT_IF_YOU_FEEL_LIKE_IT_OTHERWISE_MAKE_ME_CHECK_FOR_NULL again? Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? Umm, Terry, have you looked at the code? We *only* have two wait states - M_NOWAIT and M_WAITOK. I dont care what it was ages ago, but in recent history we have a single flag boolean flag. M_WAITOK = 0x00, M_NOWAIT = 0x01. In spite of having two names, it is really a single bit where M_WAITOK != M_NOWAIT. M_WAIT for mbufs (not malloc) was an alias for M_WAITOK, and M_DONTWAIT (also just for mbufs) was an alias for M_NOWAIT. You call things and either permit them to tsleep() or you do not. M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means you must not tsleep!. M_WAITOK conversely means that tsleep should be called as needed. Things like malloc still can return NULL even with M_WAITOK for non-recoverable scenarios. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Terry Lambert wrote: Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Peter Wemm writes: As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if you like. ie: it is a time bomb waiting for the right low memory condit ion which will then explode with a 100% authentic crash or lock up. Pretend it said M_SLEEPOK instead of M_WAITOK. Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... I'm with Poul on this one, Peter: M_WAITOK doesn't mean what you think it means: it's doesn't mean tsleep may be called, and M_NOWAIT doesn't mean tsleep() _won't_ be called, in practice. No, it is exactly what it means, eg: if (!(flags M_NOWAIT)) KASSERT(curthread-td_intr_nesting_level == 0, (malloc(M_WAITOK) in interrupt context)); tsleep() in interrupt context is the kiss-of-death. M_NOWAIT means you must not call tsleep!, which is what I have been saying all along. There is a known bug in UMA where it recurses and calls itself with with M_WAITOK even if it was explicitly called with M_NOWAIT set. The bug is real and would cause a panic if we actually ran low on memory at that point. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure
Igor Roboul wrote: Hello, I have trouble building world: -- stage 2: cleaning up the object tree -- cd /opt/freebsd/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i3 86 OBJFORMAT_PATH=/usr/obj/opt/freebsd/src/i386/usr/libexec GROFF_BIN_PAT H=/usr/obj/opt/freebsd/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/opt/freeb sd/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/opt/freebsd/src/ i386/usr/share/tmac DESTDIR=/usr/obj/opt/freebsd/src/i386 INSTALL=sh /op t/freebsd/src/tools/install.sh PATH=/usr/obj/opt/freebsd/src/i386/usr/sbi n:/usr/obj/opt/freebsd/src/i386/usr/bin:/usr/obj/opt/freebsd/src/i386/usr/g ames:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 par-cleandir === share/info === include === include/arpa cd: getcwd() failed: No such file or directory *** Error code 2 Then I have done this: rm -fr /usr/src/* cvsup -L 2 -g /etc/current-supfile after downloading over 300 Mbs of sources I got same error :-( If I repeat make buildworld then it fails with same error in different directory. There is a bug in /bin/sh. You might like to try something like this: rm -rf /usr/obj/* cd /usr/src/bin/sh make clean make obj make depend make make install As long as your /usr/src is up to date, that should save you. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: preemption across processors
On Wed, 29 May 2002 16:13:13 +0900, Seigo Tanimura [EMAIL PROTECTED] said: tanimura Maybe we can solve both of the issues above by roughly checking if a tanimura thread can keep spinning without acquiring any locks, in the similar tanimura way as we do for a spin mutex. First, test the following conditions: tanimura - The owner of the mutex has not changed. tanimura - The owner is on a processor. - The priority of the curent thread has not changed. If some other thread spins for a mutex held by the current thread, we may have to propagate the priority of the other thread. -- Seigo Tanimura [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Alcatel Speed Touch PC
Hi, I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL PCI card) I think there are some linuxdrivers but what could be needed for FreeBSD support? Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of the page). -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED]fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Release Building - failing at usr/share/doc/usd/13.viref
Howdy, I'm trying to build a FreeBSD-current snapshot release with a -current install as of 28/05/02 1400 GMT and the CVS tree updated to the same date. I've noticed that when -current is installed into the sandbox, groff isn't installed, nor is it built prior to building the usr/share/doc/usd files. The build then fails in usr/share/doc/usd/13.viref. I'm assuming groff isn't built due to c++ issues with the newer gcc import. Is this correct? Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Alcatel Speed Touch PC
I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL PCI card) I think there are some linuxdrivers but what could be needed for FreeBSD support? Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of the page). That's the Speedtouch USB, not the PCI card. Given Alcatel's refusal to provide info on the Speedtouch USB, I wouldn't be too optimistic. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld is broken(src/bin/sh)
On Mon, May 27, 2002 at 08:34:18PM +0900, MOCHIZUKI Akihide/??? wrote: #define TENDCASE 9 #define TENDBQUOTE : #define TREDIR ; #define TWORD #define TIF = I think that there are problem with awk's printing of numbers. ':' is just '9'+1 so awk tries print numbers from 10 to 15 same way as it prints numbers from 0 to 9 (by adding ascii code of '0') -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: buildworld failure
On Wed, May 29, 2002 at 12:50:15AM -0700, Peter Wemm wrote: make obj make depend make make install As long as your /usr/src is up to date, that should save you. Thank you. But now it fails on building of libncurses, with many: lib_gen.c:504: `a0' undeclared (first use in this function) lib_gen.c:504: syntax error before numeric constant lib_gen.c:504: syntax error before numeric constant lib_gen.c: In function `mvwgetnstr': lib_gen.c:511: `a0' undeclared (first use in this function) lib_gen.c:511: syntax error before numeric constant -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make buildworld fails
cvsup'ed about 1 hour ago in /etc/make.conf MAKEOBJDIRPREFIX?=/r+d/obj and with setnev MAKEOBJDIRPREFIX /r+d/obj make buildworld ... FATAL: can't create /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/cp-demangle .o: Permission denied how can i fix this? danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Release Building - failing at usr/share/doc/usd/13.viref
Howdy, Disconnecting usr/share/doc/usd/13.viref and usr/share/doc/papers/sysperf from the build process allowed me to build a -current snapshot. I found the reference in the CVS logs (2002/05/15 09:29:45 PDT) that c++ isn't being built. This explains the lack of groff and tbl. There must be some Makefile magic in bsd.doc.mk that allows all the other usd and papers directories to continue, as specific targets are defined in these two offenders. The sysperf target that fails is paper.tmp (not able to find tbl) and the 13.viref target is index.so (unable to find groff). Anyone know the ETA for c++ to be reconnected to the release build? Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Tue, 28 May 2002, Peter Wemm wrote: Richard Wenninger wrote: /usr/src/sys/vm/uma_core.c:1324: could sleep with UMA lock locked from /usr/src/sys/vm/uma-core.c:1157 Should I be concerned? Excessively concerned: no. But these are all *real* problems that must be fixed. Specifically, they are holding locks while calling a function that *might* tsleep() if memory is low at the time. If it does tsleep, it will panic or otherwise lead to a deadlock or corruption. The fact that they've gone largely unnoticed until now means that it is not an urgent problem (which is why it is a warning), but if you run really low of memory you will find out just how serious it is. I had checks for calling malloc() with M_WAITOK at a nonzero ipl and found too many problems to notice, so I usually kept the checks turned off. (I still have the checks, but they are no-ops in -current). Most of the problems seem to involve booting and networking code. The socket locking changes in -current seem to have addressed a few of these. The bug is that things are calling things like malloc with M_WAITOK when waiting is explicitly not allowed. There are other functions that can tsleep as well that we have not added checks for yet, so this is likely just the tip of the iceberg. :-( In -current, msleep() could easily check whether it is called with a lock except the expected one (Giant or mtx). Similar ipl-based checks are impossible because it is almost mandatory to sleep it a nonzero ipl to prevent races: s = splfoo(); while ((foo_p-state FOO_READY) == 0) tsleep(...); // code that depends on foo being ready splx(s); Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Wed, 29 May 2002, Peter Wemm wrote: Poul-Henning Kamp wrote: Uhm, I'm actually seeing the opposite behaviour as well: after I changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc sleeping... No, this is a bug in UMA. In certain circumstances, it calls itself with M_WAITOK even when it itself was called with M_NOWAIT. Or it could be malloc/zalloc sleeping in another process. malloc(M_NOWAIT) may block and then wait a long time for other processes to release resources. This may involved the other processes sleeping, perhaps even with M_WAITOK malloc()'s. Buggy other processes may take arbitrary long to release their resources. The important points are: - the process that called malloc(M_NOWAIT) holds all the locks that it needs to protect its data structures - the process doesn't sleep itself (since sleeping might involve releasing critical lock(s), e.g., Giant) - all this locking and sleeping doesn't cause deadlock. Sleeping without releasing all locks would be a good way to tempt deadlock, and having malloc(M_NOWAIT) sleep despite being told not to would be a good way to sleep with some locks held. Leaf routines like malloc() can barely know which locks are held, and cannot reasonably know which locks are safe to release. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On Wed, 29 May 2002, Peter Wemm wrote: M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means you must not tsleep!. M_WAITOK conversely means that tsleep should be called as needed. Things like malloc still can return NULL even with M_WAITOK for non-recoverable scenarios. malloc() itself can't do this, unless malloc(M_WAITOK) has been broken. Thousands of callers depend on malloc(M_WAITOK) not returning NULL, and malloc.9 still documents this behaviour. You may be thinking of mbuf allocation. It is confusingly different, starting with the no-wait flag being spelled differently (M_NOWAIT). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On 29-May-2002 Peter Wemm wrote: M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means you must not tsleep!. M_WAITOK conversely means that tsleep should be called as needed. Things like malloc still can return NULL even with M_WAITOK for non-recoverable scenarios. No, M_WAITOK won't return NULL, it will panic first. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: preemption across processors
On 29-May-2002 Seigo Tanimura wrote:
And the p4 depot
//depot/user/tanimura/ippreempt/...
The patch is for only i386 at the moment.
The following is the brief description of the patch:
jhb I would prefer that this was hung off the preemption stuff I've already done
jhb rather than reinventing it. I would also prefer that we get a preemptive
jhb kernel w/o this done stable before adding extra complication.
Or I can integrate your work in //depot/user/jhb/preemption/... into
//depot/user/tanimura/ippreempt/... .
I think we should do the more cautious step first.
Miscellaneous stuff:
If a thread spins for an adaptive mutex, propagate its priority to the
owner thread of the mutex. This prevents preemption of the owner
thread by a thread with the priority in between the owner thread and
the spinning thread.
jhb Ewww, I'd rather avoid this if possible. This is just an optimization,
jhb but it would depend on how complicated this makes the mutex code to see
jhb if it's worth it or not.
The owner thread of an adaptive mutex never lowers its priority until
it releases the mutex. We should thus bump the priority of the owner
thread not during but just before spinning. However, it is difficult
to know if the current thread can spin prior to calling
_obtain_lock().
In addition, I would say that spinning can be done even more
efficiently. At the moment, we try an atomic test-and-set
instruction in each spin. As another thread holds the mutex, we are
likely to execute an expensive test-and-set instruction quite a lot of
times.
Maybe we can solve both of the issues above by roughly checking if a
thread can keep spinning without acquiring any locks, in the similar
way as we do for a spin mutex. First, test the following conditions:
- The owner of the mutex has not changed.
- The owner is on a processor.
If both of the conditions satisfy, keep spinning. Otherwise, try
test-and-set. The pseudo-code would look like this:
while (!_obtain_lock(m, td)) {
mtx_lock_spin(sched_lock);
if (unowned(m)) {
mutex_unlock_spin(sched_lock);
continue;
}
owner = mtx_owner(m);
if (oncpu(owner)) {
You can not treat owner as valid unless you hold sched_lock() and
MTX_CONTESTED is set in m-mtx_lock. Thus, the value can go stale
and you could potentially be dereferencing an invalid pointer below.
/* Spin without holding sched_lock. */
critical_enter();
mtx_unlock_spin(sched_lock);
The critical section here would not be necessary I think, but you can't
read owner's value and know it is not stale if you don't hold sched_lock.
(Eventually to be replaced with a turnstile chain lock.)
One thing we might be able to do better is to change the code in the
adaptive spinning test to wait for mtx_lock to change before trying the
test-and-set again, this is a fairly simple change that isn't very hard
to do.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote: Hi Martin, /usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:3620: undefined reference to `__gxx_personality_v0' I've seen this problem too. I don't know if it has been solved, but -CURRENT's C++ compiler has been broken for a while. The workaround has been to install the gcc31 port and use it, e.g make CXX=/usr/local/bin/g++31 Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg38932/pgp0.pgp Description: PGP signature
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
Hi, I've seen this problem too. I don't know if it has been solved, but -CURRENT's C++ compiler has been broken for a while. The workaround has been to install the gcc31 port and use it, e.g make CXX=/usr/local/bin/g++31 And this doesn't work anymore. I see this with a fresh 3.1 port too now. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, 29 May 2002 18:06:10 +0200 Miguel Mendez [EMAIL PROTECTED] wrote: I've seen this problem too. I don't know if it has been solved, but -CURRENT's C++ compiler has been broken for a while. The workaround has been to install the gcc31 port and use it, e.g make CXX=/usr/local/bin/g++31 Cheers, Martin is using GCC 3.1 from ports. It sounds like GCC tries to use some library left over from the previous version of GCC, which does not provide this symbol. g++13 -v should tell you what parameters GCC passes to the linker and what libraries it tries to link. This should be enough to track down what older library shadows the new one. The usual suspects are libgcc and libstdc++. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, May 29, 2002 at 06:08:58PM +0200, Martin Blapp wrote: Hi, And this doesn't work anymore. I see this with a fresh 3.1 port too now. Martin, I don't doubt about your answer, but, can you verify you are indeed using the ports g++ compiler? I can't reproduce the bug here. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg38935/pgp0.pgp Description: PGP signature
Making newcard and oldcard moduler.
Hi, I managed to make pccard device driver into loadable module. http://people.freebsd.org/~takawata/cardmodule.diff To use this, 1. Apply following patch.(diff from HEAD) 2. Remove 'pccard','pcic','pccbb','cardbus', 'card' line from configuration file. 3. Add following line to configuration file. (Should it be standard?) == device cardcom == 4. Rebuild your kernel. 5. Move /sys/modules/ and build oldcard, pccbb, pccard, cardbus, pcic module and install them. 6 Reboot. 7 If you want to use oldcard, type as follows in loader(8). == load oldcard boot == Or if you want to use newcard with CardBus controller, type as follows. == load pccbb boot == CAVEATS Unloading newcard may cause page fault. Loading both of them cause something bad. I don't check whether all pccard driver works well. Have fun. Takanori Watanabe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, May 29, 2002 at 12:12:02PM -0400, Alexander Kabaev wrote: Hi, Martin is using GCC 3.1 from ports. It sounds like GCC tries to use some library left over from the previous version of GCC, which does not provide this symbol. g++13 -v should tell you what parameters GCC passes to the linker and what libraries it tries to link. This should be enough to track down what older library shadows the new one. The usual suspects are libgcc and libstdc++. Don't quote me on this, but I'm almost sure David made sure that the port's installed gcc compiler used it's own libgcc and libstd++. At least I can recall some comment about it in the port's Makefile. ยบ Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg38937/pgp0.pgp Description: PGP signature
RE: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
I'm new to the list, so please excuse my question If it has already been asked before. Being that -CURRENT's C++ compiler is b0rked, how long will it be until it's problems have been resolved? I've seen many problems with it lately, and it kinda made me worried, almost to the point where I thought a re-install from the 4.5 release would be appropriate. Anyway, keep up the good work. It'll work out. -dt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Miguel Mendez Sent: Wednesday, May 29, 2002 9:06 AM To: Martin Blapp Cc: [EMAIL PROTECTED]; Alexander Kabaev; [EMAIL PROTECTED] Subject: Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0' On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote: Hi Martin, /usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:36 20: undefined reference to `__gxx_personality_v0' I've seen this problem too. I don't know if it has been solved, but -CURRENT's C++ compiler has been broken for a while. The workaround has been to install the gcc31 port and use it, e.g make CXX=/usr/local/bin/g++31 Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Seeking OK to commit KSE MIII
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the moment) it shuold act the
same as now. Hopefully, changes are restricted to instruction flows that
would only occur in KSE processes.
I would like to commit this in the next couple of days to give it enough
time to settle BEFORE USENIX.
Ok, here are the random comments I've come up with:
1) Why gratuitous rename of p_stat to p_state?
2) I object to removing cred_free_thread(). It isn't getting in your
way and some of us like to test things.
3) Why did you not make the linux process in linux_machdep.c runnable
before you did a setrunqueue()? You do know we create it
stopped at first and then make it runnable after doing fixups
after fork1(), right?
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
5) The comment by thread_unsuspend() in procfs_ctl.c seems gratuitous,
that is what one would expect from such a function.
6) In cpu_set_retval() you have:
+void
+cpu_set_retval(struct thread *td, int retval, int aux, int success)
+{
+ struct trapframe *frame;
+
+ frame = td-td_frame;
+ frame-tf_eax = retval; /* Child returns zero */
+ frame-tf_edx = aux;/* I dunno */
You could always ask about that instead of having a I dunno comment. :)
I think that we no longer use 2 return values from syscalls for FreeBSD
syscalls (I know we did for fork1() at one point, possibly still do
so that 4.x libc works ok on 5.x kernel). Linux does depend on edx being
preserved across a syscall though IIRC.
7) Please follow the established convention for names of members in
pcb_ext and call 'refcount' 'ext_refccount'.
8) It would be nice if the CURSIG() - cursig() change were committed
separately to avoid obfuscating the other diffs.
9) More gratuitous braces as well as gratuituos ()'s and white space
changes in ithread_schedule() obfuscate the functional diffs.
10) In kern_sig.c, prototypes are declared on one line and near the
beginning of the file, not in the middle of code (tdsignal).
11) Why is there a whole chunk of code #if 0'd out in kern_sig.c?
12) You lock p_pptr twice (can't do that) before psignal(). Looks
like you added an extra one along with gratuitous braces and a
whitespace change.
13) Could you call readjustrunqueue() runq_readjust() to follow the
other namespaces already in kern_switch.c? Also, I find it easier
to read personally.
14) Hmm, I'm not sure why you need TDF_INMSLEEP if a KSE always has
a spare thread that is replenished first thing when the spare
thread prepares to do an upcall.
15) The 'um... dunno' comment in abortsleep() is a bit unsettling, do
you think you could clarify / run some tests to figure out exactly
what is going on there?
16) I don't think we need the P_SPARE's.
17) I think SINGLE_WAIT/EXIT is slightly more readable than
SNGLE_WAIT/EXIT. :)
18) I still don't see what's so hard about LIST_FOREACH() with
allproc.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
I have no doubt of the progress that's being made. Anyway, thanks for the help. Again, keep up the good work. -dt -Original Message- From: Sheldon Hearn [mailto:[EMAIL PROTECTED]] On Behalf Of Sheldon Hearn Sent: Wednesday, May 29, 2002 9:49 AM To: Dan Trainor Cc: [EMAIL PROTECTED] Subject: Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0' On Wed, 29 May 2002 09:27:50 MST, Dan Trainor wrote: Being that -CURRENT's C++ compiler is b0rked, how long will it be until it's problems have been resolved? I've seen many problems with it lately, and it kinda made me worried, almost to the point where I thought a re-install from the 4.5 release would be appropriate. It probably won't be too long, because at least one very clueful individual is working on the problem. In the meantime, though, either compile ports with CXX=/usr/local/bin/g++31 or use a stable, end-user oriented version of FreeBSD (like 4.6-SOMETHING). Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, May 29, 2002 at 09:27:50AM -0700, Dan Trainor wrote: Hi, Being that -CURRENT's C++ compiler is b0rked, how long will it be until it's problems have been resolved? I've seen many problems with it lately, and it kinda made me worried, almost to the point where I thought a re-install from the 4.5 release would be appropriate. Short answer, when it's ready. Long answer: David is making a very good job with the update of gcc and related tools, give him the time needed. IMHO, the stuff David is dealing with is total PITA, so be grateful he is doing it, I can't think of a better person to do it right now. -CURRENT is not for the weak, if you run it be ready to find broken stuff, from minor things in buildworld to total breakage, but the handbook already warns you about that, right? :-) FWIW, I've found last weekend's -CURRENT to be perfectly usable, but, as always, YMMV. My 0.02EUR is, if it's not a production box, and you want to play with new stuff and don't mind the (lack of) stability and think you can (possibly) help with debugging, go for -CURRENT, the more people who test it, the better, else keep running -STABLE. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://www.energyhq.tk FreeBSD - The power to serve! msg38941/pgp0.pgp Description: PGP signature
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, 29 May 2002 09:27:50 MST, Dan Trainor wrote: Being that -CURRENT's C++ compiler is b0rked, how long will it be until it's problems have been resolved? I've seen many problems with it lately, and it kinda made me worried, almost to the point where I thought a re-install from the 4.5 release would be appropriate. It probably won't be too long, because at least one very clueful individual is working on the problem. In the meantime, though, either compile ports with CXX=/usr/local/bin/g++31 or use a stable, end-user oriented version of FreeBSD (like 4.6-SOMETHING). Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
Martin Blapp wrote:
Hi all,
I see this configure failure when using the system gcc3.1 or a newer one from
ports. A version from march works.
configure:3602: checking for XOpenDisplay in -lX11
configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
conftest.C -lX11 15
/var/tmp//ccask2mP.o: In function `main':
/usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:3620:
undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
configure: failed program was:
#line 3610 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern C
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char XOpenDisplay();
int main() {
XOpenDisplay()
; return 0; }
Martin
Have you done a 'make world' in the last 24 hours or so? What does this show:
ls -l /usr/bin/c++ /usr/lib/libstdc++.so.4 /usr/include/g++/bits/c++config.h
They should all exist and be roughly the same time/date.
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
In message [EMAIL PROTECTED], John Baldwin writes: + frame = td-td_frame; + frame-tf_eax = retval; /* Child returns zero */ + frame-tf_edx = aux;/* I dunno */ You could always ask about that instead of having a I dunno comment. :) I think that we no longer use 2 return values from syscalls for FreeBSD syscalls (I know we did for fork1() at one point, possibly still do so that 4.x libc works ok on 5.x kernel). Linux does depend on edx being preserved across a syscall though IIRC. We do for 64bit returns like lseek(2) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
Hi all, Have you done a 'make world' in the last 24 hours or so? What does this show: No. And I have tested it now in STABLE to with the gcc32 and gcc31 ports. Result is the same. gcc295 in stable, and a march gcc31 port are fine. All other gcc3.x versions are failing. ls -l /usr/bin/c++ /usr/lib/libstdc++.so.4 /usr/include/g++/bits/c++config.h They should all exist and be roughly the same time/date. mb@fuchur:~$ ls -l /usr/bin/c++ /usr/lib/libstdc++.so.4 /usr/include/g++/bits/c++config.h ls: /usr/include/g++/bits/c++config.h: No such file or directory ls: /usr/lib/libstdc++.so.4: No such file or directory -r-xr-xr-x 3 root wheel 76524 May 25 23:17 /usr/bin/c++ I'll make now a world and see if something changes. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re:why change: from proc to thread?
kthreads are not threads, but, rather, kernel processes.. they have a separate 'proc' structure. (they are badly named..) On Wed, 29 May 2002, kai ouyang wrote: Thank you! I know a little more. From the kthread_create() function, I find Both 4.x and 5.0 are implemented by fork1(). I am puzzled about the structure thread and the structure proc only are different terms. How or what part source code can I find the difference thread realization between 4.x and 5.0? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Alcatel Speed Touch PC
I would like to know as well cause right now I have made it work under linux using the driver from sourceforge and a patched pppd supporting PPPoATM and I would say it works pretty stable under 2.4.18. Maybe it would get to work under Linux emulation but I have never tried so I would like to know if anyone here has. George -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Black holes are the result when God devides by zero.. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Taavi Talvik Sent: Tuesday, May 28, 2002 10:51 PM To: John Angelmo Cc: [EMAIL PROTECTED] Subject: Re: Alcatel Speed Touch PC On Tue, 28 May 2002, John Angelmo wrote: Hello I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL PCI card) I think there are some linuxdrivers but what could be needed for FreeBSD support? Legimate way to get Alcatel firmware. It can be extracted from various windows drivers but thats not very clean way. And of course driver for whatever ATM SAR chip Alcatel uses (most SARs are documented). best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Seeking OK to commit KSE MIII
On Wed, 29 May 2002, John Baldwin wrote:
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the moment) it shuold act the
same as now. Hopefully, changes are restricted to instruction flows that
would only occur in KSE processes.
I would like to commit this in the next couple of days to give it enough
time to settle BEFORE USENIX.
Ok, here are the random comments I've come up with:
1) Why gratuitous rename of p_stat to p_state?
to catch places in 3rd party code that may have the old completely
different one.. it matches td_state and kse_state..
2) I object to removing cred_free_thread(). It isn't getting in your
way and some of us like to test things.
that doesn't test anything.. it just complicates the code, and worse,
it changes the way that the code behaves in debug mode from the way it
behaves in normal mode..
We've had this argument so many times before..
I didn't remove it.. I never put it back...It was gone from the KSE code
long before the fight in -current.. One reason I removed it from
current was diff-reduction to KSE :-)..
feel free to add it back to KSE, pointless though it is..
3) Why did you not make the linux process in linux_machdep.c runnable
before you did a setrunqueue()? You do know we create it
stopped at first and then make it runnable after doing fixups
after fork1(), right?
Because in a threaded world, setrunqueue() also makes it
runnable (see later for reason). that's why I removed ALL the setting of
threads to runnable..
It's part of the atomic operation (under locks) of adding it ot the run
queue. I never have a state in a thread that does not correctly reflect
its queued state.. (at least that is my aim.). If the flags/state say it
is runnable and on the run queue (TDS_RUNQ) then it IS on the run queue,
not soon to be on the run queue. This allows me to accuratly control
the queues by BELIEVING what the state says. The same queue entry is used
for other queues so by making hte state accuratly reflect what queue it
is on I can know how to handle it without having to know information
that is outside my scope.
If it is actually running it is NOT in state TDS_RUNQ but in
state BTDS_RUNNING.
etc. etc.. i.e. the function that puts it on the run queue (setrunqueue())
alse sets the state saying what queue it is on. Until that moment it is
not on the run queue so the state is not altered.. (It is probably in
state TDS_UNQUEUED). If there were a function to put it on the sleep
queue, then that is where the state would be set to TDS_SLEEP, but that
code is not so clean and it happens in more than one place (sleep +
condvars etc.). My eventual aim is that there be methods to put the thread
into each state, similar to setrunqueue(), and that each method both
queues the thread, AND sets the state. setrunqueue() is just the first.
Why?
Remember that in a threaded world, threads state changes are more
complicated as they may or may not result in changes to procs and KSEs
as well, thus it makes more sense to hide thread state changes behind
opaque methods, so that they can be changed and debugged
easier.
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
hmm ok probably I had changes there that were backed out at some stage.
(like debugging printfs or something..)
5) The comment by thread_unsuspend() in procfs_ctl.c seems gratuitous,
that is what one would expect from such a function.
I'll go take a look in a minute..
6) In cpu_set_retval() you have:
+void
+cpu_set_retval(struct thread *td, int retval, int aux, int success)
+{
+ struct trapframe *frame;
+
+ frame = td-td_frame;
+ frame-tf_eax = retval; /* Child returns zero */
+ frame-tf_edx = aux;/* I dunno */
You could always ask about that instead of having a I dunno comment. :)
I think that we no longer use 2 return values from syscalls for FreeBSD
syscalls (I know we did for fork1() at one point, possibly still do
so that 4.x libc works ok on 5.x kernel). Linux does depend on edx being
preserved across a syscall though IIRC.
AH so you dunno either :-)
7) Please follow the established convention for names of members in
pcb_ext and call 'refcount' 'ext_refccount'.
ok, actually I think it can be removed.. I'll have to check..
8) It would be nice if the CURSIG() - cursig() change were committed
separately to avoid obfuscating the other diffs.
yeah that is a mini thing :-)
9) More gratuitous braces as well as gratuituos ()'s and white space
changes in ithread_schedule() obfuscate the functional diffs.
I guess so though it made it a hell of a lot more
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote: configure:3602: checking for XOpenDisplay in -lX11 configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib conftest.C -lX11 15 /var/tmp//ccask2mP.o: In function `main': /usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:3620: undefined reference to `__gxx_personality_v0' Please add -v to CFLAGS somehow. Then let me see this error again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote: 9) More gratuitous braces as well as gratuituos ()'s and white space changes in ithread_schedule() obfuscate the functional diffs. I guess so though it made it a hell of a lot more readable to me. That isn't the issue. You have posted a diff that you plan to commit in an implied one-shot event. If you really have(want) to make these style changes, please commit them, and them alone right now. That will remove them from this patch and make jhb an Co'.s life easier. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
On 2002-05-29 00:24 -0700, Peter Wemm wrote: There is a known bug in UMA where it recurses and calls itself with with M_WAITOK even if it was explicitly called with M_NOWAIT set. The bug is real and would cause a panic if we actually ran low on memory at that point. Just in case anyone more knowledgeable than me knows that to do about this, here's something that seems to look like this. A trace that I got when I ran my kernel with WITNESS for a day or so, was the following. Note the lines marked with an asterisk that clearly show (unless I am terribly wrong) that UMA is entered twice, and the WITNESS check fails the second time. Debugger(witness_sleep) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 db trace Debugger(c02d6500) at Debugger+0x45 witness_sleep(1,0,c02eb711,52c) at witness_sleep+0xf8 * uma_zalloc_arg(c082a640,0,0) at uma_zalloc_arg+0x3e vm_map_entry_create(c0822000,c5b55150,c69a2000,c0822000,c6424bd4) at vm_map_entry_create+0x2b _vm_map_clip_end(c0822000,c5b55150,c69a4000) at _vm_map_clip_end+0x4b vm_map_delete(c0822000,c69a2000,c69a4000,c69a2000,4) at vm_map_delete+0x94 vm_map_remove(c0822000,c69a2000,c69a4000,c0321140,1) at vm_map_remove+0x5b kmem_free(c0822000,c69a2000,2000,c6424c60,c02818a0) at kmem_free+0x3c page_free(c69a2000,2000,4) at page_free+0x44 zone_drain(c24f3780) at zone_drain+0x302 zone_foreach(c028159e,c6424d0c,c027f22c,c0321140,1) at zone_foreach+0x2e * uma_reclaim(c0321140,1,c02eb4c2,286,c0321140) at uma_reclaim+0x12 vm_pageout_scan(0,c027fcaa,c6424d34,c01a0eaa,0) at vm_pageout_scan+0x30 vm_pageout(0,c6424d48,c6380a3c,c027fcaa,0) at vm_pageout+0x22d fork_exit(c027fcaa,0,c6424d48) at fork_exit+0x88 fork_trampoline() at fork_trampoline+0x37 db c -- Giorgos Keramidas| FreeBSD: The Power to Serve [EMAIL PROTECTED] | http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMA lock
Bosko Milekic wrote: On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote: Can we get rid of the NULL tests we had to put in when M_WAIT turned into M_WAITOK? No. What you see as a bad thing others (including me) see as a good thing. I _want_ to be able to say: okay, try sleeping; but I realize that sleeping for longer than some reasonable time if I'm not getting anything to begin with will probably not get me anything at any point so tell me the allocation really failed and give me the opportunity to clean up before *I* decide what I want to do. Up the operating system's wazoo! *We* are the programmers. *We* know better than *it* whether it's OK to sleep indefinitely or not. If *we* want the allocation to fail after *some reasonable time*, then *we will damn well set a timer to some reasonable time* to indicate that fact to the OS. If *we* do *not* damn well set a timer, then *we* damn well do not want it to fail, *we* want it to hang either *until it succeeds* or *until hell freezes over* or *until we manually enter the kernel debugger to find out why it is hanging*. All these people are bitching about kludging around something by changing M_WAITOK to M_NOWAIT. The kludge is *already there* in M_WAITOK, whether you want it or not. So bitching about this kluge is meaningless: changing it back to M_WAITOK won't make the little F'er go away, it will just *hide* the kludge from people to lazy to read the code all the way down, and know *why* they have to check for a NULL return from a call that's *supposed to wait* until it's return will *not* be NULL. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote: : : 9) More gratuitous braces as well as gratuituos ()'s and white space : changes in ithread_schedule() obfuscate the functional diffs. : : I guess so though it made it a hell of a lot more readable to me. : :That isn't the issue. You have posted a diff that you plan to commit in :an implied one-shot event. If you really have(want) to make these style :changes, please commit them, and them alone right now. That will remove :them from this patch and make jhb an Co'.s life easier. No hold on a minute. Some of us believe that adding those extra braces and parenthesis makes the code a whole lot more readable. they are NOT gratuitous in the least, certainly not from my point of view! Furthermore, it is an extreme and inappropriate imposition on Julian to require that he extract all the alleged 'gratuitous braces and ()'s)' into a separate commit. Those changes were made by Julian as part of his on going work to enable him to work more efficiently on the code. Unless you have a *SPECIFIC* reason related to patching and updating code in CVS that requires Julian to commit these separately all you are doing is creating hash on the lists and making Julian's job more difficult, unnecessarily. I will say quite bluntly that in the vast majority of cases on these lists where I've seen someone ask for whitespace fixes to be comitted separately, I have yet to see any significant (or any at all!) developers take advantage of the separate commits when incorporating the work into their own development trees. I agree that as a general rule of thumb it makes sense to commit whitespace/paren/brace changes separately, but that is ALL it is. A rule of thumb. It should not be followed blindly, on principle, if it has an adverse effect on the developer tring to do the work, and it certainly should not be made a prerequisit for having good work comitted. I see no benefit to the project or the developer community. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
*****All In One Unit!*****
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00B0_33B54E8A.C0266E75
Re: Seeking OK to commit KSE MIII
In message [EMAIL PROTECTED], Matthew Dillon w rites: I agree that as a general rule of thumb it makes sense to commit whitespace/paren/brace changes separately, but that is ALL it is. A rule of thumb. It should not be followed blindly, on principle, if it has an adverse effect on the developer tring to do the work, and it certainly should not be made a prerequisit for having good work comitted. I see no benefit to the project or the developer community. For complex patches, which should get good and thorough reviews before they are committed, avoiding unsubstantial style/whitespace changes from cluttering the patch should be mandatory. Julians patch clearly belongs in this category. Consequently, it is in Julians own interest to get the whitespace/style changes into the tree first (they don't need a review, if he does them right) since that makes the patch people have to read through correspondingly smaller. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-----get every cable channel-----
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00A4_81E07D7A.A0001C56
Re: Seeking OK to commit KSE MIII
On Wed, May 29, 2002 at 01:07:01PM -0700, Matthew Dillon wrote: :On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote: : : 9) More gratuitous braces as well as gratuituos ()'s and white space : changes in ithread_schedule() obfuscate the functional diffs. : : I guess so though it made it a hell of a lot more readable to me. : :That isn't the issue. You have posted a diff that you plan to commit in :an implied one-shot event. If you really have(want) to make these style :changes, please commit them, and them alone right now. That will remove :them from this patch and make jhb an Co'.s life easier. No hold on a minute. Some of us believe that adding those extra braces and parenthesis makes the code a whole lot more readable. they are NOT gratuitous in the least, certainly not from my point of view! Uh... Matt where did I say they were. I requested that they be committed separately from functionality. And if they were going to be committed, for it to happen now. That is all I said -- nothing more. I held me tongue on the gratuitous issue and the fact that Julian has a long history of breaking existing style in his commits. Furthermore, it is an extreme and inappropriate imposition on Julian to require that he extract all the alleged 'gratuitous braces and ()'s)' into a separate commit. Uh, no it isn't. That is the rules we operate under. This type of request comes up _daily_, and is generally agreed upon by most committers. Sorry, but the work involved is just part of making commits. I will say quite bluntly that in the vast majority of cases on these lists where I've seen someone ask for whitespace fixes to be committed separately, I have yet to see any significant (or any at all!) developers take advantage of the separate commits when incorporating the work into their own development trees. I personally do look at diffs using -r before_commit -r with_WS_only followed by -r with_WS_only -r with_functionality_only Should I start sending an email to -current every time I do so that you will know that someone does? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
repeated -CURRENT build failures
Hello guys,
I've update May 25 my notebook with a fresh -CURRENT cvsup
source and now when I want to build a new -current on my notebook
I've got repeated build failures.
I've got a lot of time this type of error Illegal instruction - core dumped
with or without -j in buildworld in the second stage in various
places (binaries, perl, docs, ...)
Does anybody notice the same things ?
Thanks
Notebook infos:
FreeBSD bushmills.intra.thorm.net 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Sat May 25
22:59:29 CEST 2002
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/bushmills i386
Model: Inspiron 8200
RAM: 512MB
Processor : Intel P4
--
Sebastien Gioria gioria@{FreeBSD,FreeBSD-FR}.ORG
French FreeBSD User Group http://www.FreeBSD-FR.ORG
YM!: eagle_4242 IRC: eagle42[_]? ICQ:110946002
...and on the eighth day God created FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
On Wed, 29 May 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon w rites: I agree that as a general rule of thumb it makes sense to commit whitespace/paren/brace changes separately, but that is ALL it is. A rule of thumb. It should not be followed blindly, on principle, if it has an adverse effect on the developer tring to do the work, and it certainly should not be made a prerequisit for having good work comitted. I see no benefit to the project or the developer community. For complex patches, which should get good and thorough reviews before they are committed, avoiding unsubstantial style/whitespace changes from cluttering the patch should be mandatory. Julians patch clearly belongs in this category. Consequently, it is in Julians own interest to get the whitespace/style changes into the tree first (they don't need a review, if he does them right) since that makes the patch people have to read through correspondingly smaller. Generally I agree with this statement.. in the case of the braces in question, they are part of an if statement that got rewritten so I'm slightly surprised that they are considered unrelated to the patch. I'm happy to commit it separatly right nowe though, as it's another 6 line less of diff :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
On Wed, 29 May 2002, Matthew Dillon wrote:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed blindly, on principle,
if it has an adverse effect on the developer tring to do the work,
and it certainly should not be made a prerequisit for having good
work comitted. I see no benefit to the project or the developer
community.
Thanks for the support Matt, though in this case I don't really mind. I've
been away for the code for a while, and I am looking for things to
clean-up though it to help me get back into it :-) so I don't mind doing
a few separate commits here and there..
having said that,
In this case the braces in question in ithread_schedule are:
- } else
+ } else {
curthread-td_kse-ke_flags |= KEF_NEEDRESCHED;
+ }
I tend to always put braces on the else clause if the 'then' clause
has braces.. it just helps me find the end of the if statement.
The if statement in question was rewritten as part of KSE
so Adding the braces on the else clause doesn't seem 'out of scope'
to me.. It's not a tremendous obfuscation, because the clause
in question needs to be considered to understand the change..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
: : Furthermore, it is an extreme and inappropriate imposition on Julian : to require that he extract all the alleged 'gratuitous braces and : ()'s)' into a separate commit. : :Uh, no it isn't. That is the rules we operate under. This type of :request comes up _daily_, and is generally agreed upon by most :committers. Sorry, but the work involved is just part of making commits. I see the request come up a lot. Most of the requests and most of the justification appears to come from people who are acting in the role of net-police rather then for any reason actually related to development work. If you read the diffs separately in the midst of a review, then good for you! You are an exception to the rule. I find it a waste of time myself. I just diff the whole damn thing when I review the code so I can see everything context and do a single pass over it. It takes less time. Consider the amount of time Julian would have to waste to locate, separate, and commit the pieces, verses the amount of time the few (three?) developers likely to review his patches will waste going through the crud. In your case that amount of time wasted will be near 0 since you say you are looking at the crud along with the meat. Then consider which of the following actions is more appropriate: * Hey J, please separate out the whitespace/braces changes and make two separate commits before doing anything else. * Hey J, the patches look good but I sure would appreciate it if, the next time, you would get the whitespace/bracing changes committed and out of the way first. Don't worry about it this time. In regards to developer relationships and keeping things civil and less stressful on the lists, #(2) is the far better solution and, frankly, I think we should *CODIFY* that in the rules certain people seem to enjoy quoting so much. And that, David, is why the whitespace rules should be a 'rules of thumb' rather then a 'you will do this or else' rule. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
:having said that,
:In this case the braces in question in ithread_schedule are:
:- } else
:+ } else {
:curthread-td_kse-ke_flags |= KEF_NEEDRESCHED;
:+ }
:
:I tend to always put braces on the else clause if the 'then' clause
:has braces.. it just helps me find the end of the if statement.
:The if statement in question was rewritten as part of KSE
:so Adding the braces on the else clause doesn't seem 'out of scope'
:to me.. It's not a tremendous obfuscation, because the clause
:in question needs to be considered to understand the change..
I do this too. My rule for if() statements 'if (exp) stmt1 else stmt2'
in the FreeBSD codebase is:
* If stmt1 or stmt2 is multi-line, or exp is multi-line, then
braces are used around both statements, period.
Multi-line means: multiple lines inclusive of any comments, not just
the pure C part of it.
This is wrong:
if (fubar)
/*
* yada yada
*/
stmt;
else {
stmt;
stmt;
}
if (fubar)
stmt;
else {
stmt;
stmt;
}
This is right:
if (fubar) {
/*
* yada yada
*/
stmt;
} else {
stmt;
stmt;
}
if (fubar) {
stmt;
} else {
stmt;
stmt;
}
Same goes with for(), while(), etc.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
Ok I just committed that one on it's own now back to the real points that jhb raised.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Making newcard and oldcard moduler.
In message: [EMAIL PROTECTED] Takanori Watanabe [EMAIL PROTECTED] writes: : 3. Add following line to configuration file. (Should it be standard?) : == : device cardcom They should be standard. I have a patch that does this for all the _if* files in the system, with a bloatage of a few hundred bytes. It makes loadable drivers much less painful to do if we have them in the base kernel always. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
* From Matthew Dillon [EMAIL PROTECTED] No hold on a minute. Some of us believe that adding those extra braces and parenthesis makes the code a whole lot more readable. they are NOT gratuitous in the least, certainly not from my point of view! When you make the code more readable, you introduce further diffs, and you leave no reference against the original code of where the functional changes are. Either make the base code cleaned up by committing non-functional changes first, or commit against the base code your functional changes, and then clean it up. Otherwise, it's a pain in the ass to sort things out. And for what it's worth, I'm all for readability improvements in our code, I just also like to go and view diffs sometimes and try to figure out what's changed. But I think you're also right on the rule of thumb thing, if someone does not want to do this favor to everyone who might want to read diffs or annotate changes to the code and get something meaningful, that's fine. I've done it plenty of times myself. However, I tend to do that locally first, and then commit the harmless things as I go. If you ever look through one of my WIP repos (~jmallett/cvs on Freefall currently holds one, my sccs repo, as I did and do believe others should have easy access to it), I tend to piggyback a lot of stylistic nits, etc. as I go... But I don't think it's fair to do the merge like you're saying... But back to where this started, it's just a rule of thumb. Furthermore, it'd be nice if as people made stylistic changes for outside projects they committed them to the central repository, where applicable. Anyway, I'm out of paint. Good day. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Seeking OK to commit KSE MIII
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
I don't consider that to be a gratuitous style change.
I'm rewriting the clause and consider that as a 3 line clasue with 2
levels of indent it makes it more error resistant to have the braces..
The 'then' clause has braces so teh else one should too.
if (foo) {
fumble();
futz();
} else
bah;
always really annoys me.
If I'm looking for the end of the if statement, I'm looing for a '}'..
5) The comment by thread_unsuspend() in procfs_ctl.c seems gratuitous,
that is what one would expect from such a function.
I'll go take a look in a minute..
+ thread_unsuspend(p); /* If it can run, let it do so. */
ok, the reason is that thread_unsuspend may NOT result in the thread
running as it may still be blocked by other suspend types.
It is possible that the correct answer is to rename thread_unsuspend()
to proc_check_unsuspend(). There are three reasons a process may be
suspended and we've only released one of them here.
It was called thread_unsuspend() because it is one of a suite of functions
that are in the thread control code, but it's function really is
process-wide so it should probably start with proc_..
thoughts?
6) In cpu_set_retval() you have:
+ frame-tf_edx = aux;/* I dunno */
[..]
I'll make is a bit more correct
7) Please follow the established convention for names of members in
pcb_ext and call 'refcount' 'ext_refccount'.
removed
8) It would be nice if the CURSIG() - cursig() change were committed
separately to avoid obfuscating the other diffs.
yeah that is a mini thing :-)
I'll see what I can do.
10) In kern_sig.c, prototypes are declared on one line and near the
beginning of the file, not in the middle of code (tdsignal).
Fixed
11) Why is there a whole chunk of code #if 0'd out in kern_sig.c?
It's contriversial..
matt and I feel you shouldn't be checking this stop state in issignal
but rather at kernel exit. I have other code that does this
(thread_suspend_check()) but there is some chance I may need to re-enable
this code if people notice a change in behaviour.
12) You lock p_pptr twice (can't do that) before psignal(). Looks
like you added an extra one along with gratuitous braces and a
whitespace change.
fixed
13) Could you call readjustrunqueue() runq_readjust() to follow the
other namespaces already in kern_switch.c? Also, I find it easier
to read personally.
done
14) Hmm, I'm not sure why you need TDF_INMSLEEP if a KSE always has
a spare thread that is replenished first thing when the spare
thread prepares to do an upcall.
It was a leftover that mini didn't remove.. I'll investigate if it's still
needed.
There may still be a race, however as we call
thread_alloc() from thread_schedule_upcall() which is in turn called
from within msleep().. personally this just protects us from trying to
recurse if we end up trying to sleep because we are trying to allocate a
new one.
I'm not convinced that this recursion cannot happen, even with the new
allocation code.
15) The 'um... dunno' comment in abortsleep() is a bit unsettling, do
you think you could clarify / run some tests to figure out exactly
what is going on there?
I still dunno :-)
I'll look into it more over the next couple of days..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
: :When you make the code more readable, you introduce further diffs, and you :leave no reference against the original code of where the functional changes :are. Either make the base code cleaned up by committing non-functional :changes first, or commit against the base code your functional changes, :and then clean it up. Otherwise, it's a pain in the ass to sort things out. : :And for what it's worth, I'm all for readability improvements in our code, I :just also like to go and view diffs sometimes and try to figure out what's :changed. : :But I think you're also right on the rule of thumb thing, if someone does not :want to do this favor to everyone who might want to read diffs or annotate :changes to the code and get something meaningful, that's fine. I've done it Oh come on, that is not what I meant at all and you know it. What is this junk about 'not wanting to do this favor to everyone'? I never said that. I didn't even come CLOSE to saying that or infering that. It is complete and utter bullshit and a severe... nay, *EXTREME* twisting of what I said. You missed the point entirely. Go back and READ WHAT I WROTE. I made it pretty damn clear. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
* From Matthew Dillon [EMAIL PROTECTED] : :When you make the code more readable, you introduce further diffs, and you :leave no reference against the original code of where the functional changes :are. Either make the base code cleaned up by committing non-functional :changes first, or commit against the base code your functional changes, :and then clean it up. Otherwise, it's a pain in the ass to sort things out. : :And for what it's worth, I'm all for readability improvements in our code, I :just also like to go and view diffs sometimes and try to figure out what's :changed. : :But I think you're also right on the rule of thumb thing, if someone does not :want to do this favor to everyone who might want to read diffs or annotate :changes to the code and get something meaningful, that's fine. I've done it Oh come on, that is not what I meant at all and you know it. What is this junk about 'not wanting to do this favor to everyone'? I never said that. I didn't even come CLOSE to saying that or infering that. It is complete and utter bullshit and a severe... nay, *EXTREME* twisting of what I said. I was twisting my own words, not yours. You missed the point entirely. Go back and READ WHAT I WROTE. I made it pretty damn clear. I was showing a parallel set of thoughts and points of my own. -- J. Mallett [EMAIL PROTECTED]FreeBSD: The Power To Serve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
Julian Elischer wrote:
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
I don't consider that to be a gratuitous style change.
I'm rewriting the clause and consider that as a 3 line clasue with 2
levels of indent it makes it more error resistant to have the braces..
The 'then' clause has braces so teh else one should too.
if (foo) {
fumble();
futz();
} else
bah;
always really annoys me.
If I'm looking for the end of the if statement, I'm looing for a '}'..
We've been over this particular case several times before. After the dust
has settled, we've decided that we would allow it as long as it wasn't
excessive.
ie: it is ok to change this:
if (foo) {
fumble();
futz();
} else
bah;
into
} else {
bah;
}
or to change this:
if (foo)
fumble();
else {
futz();
bah;
}
into:
if (foo) {
fumble();
} else {
But it is generally NOT ok do change:
if (foo)
fumble()
else
futz();
into:
if (foo) {
fumble();
} else {
futz();
}
Of course, a couple of provisos apply:
- It is preferable to do this as a seperate commit. Note: preferable.
- It is not appropriate to do this on sections of code that we are ever
likely to have to sync up with somebody else. (unless the other parties
are doing something similar).
- reformatting rampages are not OK (we've had these before, see the
Delete trailing whitespace commits and the flamewar that resulted).
- Use good judgement when changing stuff. Do not change things into one's
own perferred style when it is well known that folks object strongly to
that particular style. The style guide is a common ground that we've
all agreed to try and adhere to vs using our own. (I personally came from
a 2-space indent background, etc. I had to make big concessions to the
common format just like everybody else.)
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: repeated -CURRENT build failures
On Wed, May 29, 2002 at 10:39:08PM +0200, Sebastien Gioria wrote: Hello guys, I've update May 25 my notebook with a fresh -CURRENT cvsup source and now when I want to build a new -current on my notebook I've got repeated build failures. I've got a lot of time this type of error Illegal instruction - core dumped with or without -j in buildworld in the second stage in various places (binaries, perl, docs, ...) Does anybody notice the same things ? It indicates you're building (or have already installed) a world built with the wrong CPU optimizations, for example via CPUTYPE. Kris msg38971/pgp0.pgp Description: PGP signature
Re: Seeking OK to commit KSE MIII
On Wed, 29 May 2002, Peter Wemm wrote:
ie: it is ok to change this:
if (foo) {
fumble();
futz();
} else
bah;
into
} else {
bah;
}
In this case it's moot because I already did it as a separate commit
but it was changing:
if (foo) {
mumble();
futz();
} else
bah;
to
if (blah_foo()) {
mumble();
futz();
} else {
bah();
}
So it wasn't really just a style change. there was a logic change too.
anyhow.. enough already!
:-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seeking OK to commit KSE MIII
When it comes right down to it, I am getting wholely sick and tired of people acting like rulez-police and complaining about the most minor, most insignificant syntactical changes imagineable. The rest of us developers have better things to do with their time then to spend it on a few undistinguished braces that have no effect whatsoever on readability or reviewability and, frankly, are so insignificant that it doesn't even make sense to commit them separately. You don't believe me? Read Julian's diff and the commit he just made and try telling me that it absolutely *HAD* to be a separate commit because you wouldn't have been able to read the diff otherwise. It is an absolutely ridiculuous thought. Now if someone was going through files making dozens of syntactical changes intermixed with other things then, sure, you could request that they be put in separately and I would call it a reasonable request. But that is not what is going on here. Not by a long shot. We have people on this list that complain over the smallest 'infraction' of the rules, and then jump up the alleged significance of the event by foretelling gloom and doom and the end of all things if the rules are not followed exactly to a T. It MUST STOP. It is not good for the development community or the project. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === bin/sh === bin/sleep === bin/stty === bin/sync === bin/test === bin/rcp === bin/csh === bin/csh/nls === bin/rmail /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/lib/libc.so: undefined reference to `minbrk' *** Error code 1 Stop in /d/home/des/tinderbox/src/bin/rmail. *** Error code 1 Stop in /d/home/des/tinderbox/src/bin. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
XFree86-4-libraries build error
I'm getting the following error on a just built -current, which was a fresh install of 5.0-CURRENT-20020519-JPSNAP: installing in lib/XThrStub... rm -f UIThrStubs.o LD_LIBRARY_PATH=../../exports/lib cc -c -O -pipe-ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../.. -I../../exports/include -DCSRG_BASED -DFUNC PROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DM ALLOC_0_RETURNS_NULL-ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith-I. ./.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHR EADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURNS_NULL -fPI C UIThrStubs.c UIThrStubs.c:102: alias arg not a string UIThrStubs.c:103: alias arg not a string UIThrStubs.c:104: alias arg not a string UIThrStubs.c:105: alias arg not a string UIThrStubs.c:106: alias arg not a string UIThrStubs.c:107: alias arg not a string UIThrStubs.c:108: alias arg not a string UIThrStubs.c:109: alias arg not a string UIThrStubs.c:110: alias arg not a string UIThrStubs.c:111: alias arg not a string UIThrStubs.c:113: alias arg not a string UIThrStubs.c:114: alias arg not a string UIThrStubs.c:115: alias arg not a string UIThrStubs.c:131: warning: `_Xthr_self_stub_' defined but not used UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/XThrStub. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86-4-libraries build error
On Wed, May 29, 2002 at 11:38:57PM -0500, Peter Schultz wrote: FWIW: same here yesterday. I have not yet investigated what's up Wilko I'm getting the following error on a just built -current, which was a fresh install of 5.0-CURRENT-20020519-JPSNAP: installing in lib/XThrStub... rm -f UIThrStubs.o LD_LIBRARY_PATH=../../exports/lib cc -c -O -pipe-ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../.. -I../../exports/include -DCSRG_BASED -DFUNC PROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DM ALLOC_0_RETURNS_NULL-ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith-I. ./.. -I../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHR EADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI-DMALLOC_0_RETURNS_NULL -fPI C UIThrStubs.c UIThrStubs.c:102: alias arg not a string UIThrStubs.c:103: alias arg not a string UIThrStubs.c:104: alias arg not a string UIThrStubs.c:105: alias arg not a string UIThrStubs.c:106: alias arg not a string UIThrStubs.c:107: alias arg not a string UIThrStubs.c:108: alias arg not a string UIThrStubs.c:109: alias arg not a string UIThrStubs.c:110: alias arg not a string UIThrStubs.c:111: alias arg not a string UIThrStubs.c:113: alias arg not a string UIThrStubs.c:114: alias arg not a string UIThrStubs.c:115: alias arg not a string UIThrStubs.c:131: warning: `_Xthr_self_stub_' defined but not used UIThrStubs.c:139: warning: `_Xthr_zero_stub_' defined but not used *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/XThrStub. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ---end of quoted text--- -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Startup problem with DP1
Hi ! I am starting to be developer on Fbsd and sometime I was working on 5.0, then I stopped because of lack of time, and after a while I couldn't build no more, so I decided to reinstall my development environment. Install went OK, but startup didn't. I know excatly where the problem is. I am using VMWare workstation on Win2000, and on compile of kernel, I must change one line in one source file... Problem is that install installed DP1 version of kernel which is normal, so my computer won't start. Is there any way to make some 4.4 boot disks so that I could start system build new kernel and then start again. I tried with PicoBSD system, but I couldn't get it to work. Original version is just 3-BETA, which doesn't support disks I use (I use ad, 3 supports wd). Please, any help will be appreciated so that I can continue with my work. Thanks in advance Andy ** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * [EMAIL PROTECTED] * Sentinel, BH 90210, True's Trooper, * *[EMAIL PROTECTED] * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender* * ICQ-UIC: 4911125 * * PGP key available *http://www.atechnet.dhs.org/~andy/ * ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
