> :> :
> :> :This means that invariants need to add relatively little overhead.
> :> :
> :> :Peter
> :>
> :> which they do.
> :
> :You know, guys, for programmers, wanting immediate panics on stuff like
> :this is great, but there isn't one user in a thousand that wants this.
> :If you ma
:> :
:> :This means that invariants need to add relatively little overhead.
:> :
:> :Peter
:>
:> which they do.
:
:You know, guys, for programmers, wanting immediate panics on stuff like
:this is great, but there isn't one user in a thousand that wants this.
:If you make this kinda stuff
Well, I went and removed "static" from both lines in pcic.c as noted
below, did a make clean, make depend all, and recieved the same error.
Unfortunately, I'm running out of ideas.
I've tried commenting out the whole sections, replacing the
register_pcic.init with "return(10);" (what my pcmcia
Robert Watson wrote:
>
> So this is actually just a general response to the whole thing--one of the
> things I actually dislike about rc.conf is its flexibility: the user can
> put anything script-wise they like into it. My temptation would be to
> reduce the flexibility: to have a simple name:va
> "Ryan" == Ryan Dewalt writes:
Ryan> re-compiling the kernel, I recieved this error. (after the
Ryan> original make all failed, I re-ran this to regenerate the error)
Ryan> porta# make all
Ryan> loading kernel
Ryan> pccard.o: In function `unregister_device_interrupt':
Ryan> pccard.o(.text+0
On Wed, 10 Mar 1999, Matthew Dillon wrote:
> :
> :>Therefore, my preference is to turn invariants on on all my production
> :>kernels as well as my development kernels.
> :
> :This means that invariants need to add relatively little overhead.
> :
> :Peter
>
> which they do.
You
:
:>Therefore, my preference is to turn invariants on on all my production
:>kernels as well as my development kernels.
:
:This means that invariants need to add relatively little overhead.
:
:Peter
which they do.
-Matt
Matthew Dillon wrote:
>there are simply not enough sanity checks being made in the kernel.
There is a trade off between the amount of sanity checking and
performance. We need to make sure that any sanity checking we add
doesn't make the system unusably slow or adversely impact interrupt
resp
After running cvsup today, and running my weekly make world (with no problems)
re-compiling the kernel, I recieved this error.
(after the original make all failed, I re-ran this to regenerate the error)
porta# make all
loading kernel
pccard.o: In function `unregister_device_interrupt':
pccard.o(.
Hi Warner!
Sorry to intrude, but I just want to check that I didn't miss any
messages in this thread. Have you found anything that might be causing
this problem? I think it's related to the 100% CPU utilization while
writing full speed to both the ahc2940uw on pci and the 1542CP on isa. I
realize
On Wed, 10 Mar 1999 sth...@nethelp.no wrote:
> > Uh, no. Invariants are for developers who want to make sure their code
> > is correct. There is no reason why an end user would want to build a
> > kernel with invariants enabled. Invariants will *not* increase data
> > safety. If they have any effe
So this is actually just a general response to the whole thing--one of the
things I actually dislike about rc.conf is its flexibility: the user can
put anything script-wise they like into it. My temptation would be to
reduce the flexibility: to have a simple name:value configuration file
(with app
> I don't use DIAGNOSTIC because it's overly intrusive and cause cause
> panics or create bugs where none exist.
Then it should be fixed. I think DIAGNOSTIC is *supposed* to do
everything you're arguing for and to scream for its removal in one
breath and then call for a mechanism which d
On Tue, 9 Mar 1999, Archie Cobbs wrote:
> wcslen()
> wcscpy()
> wcsncpy()
> wcscat()
> wcscmp()
> wcsncmp()
>
> How come FreeBSD doesn't have these? Is there a complicated problem
> preventing us from adding them?
I have a start at all the wc functions in the NA1 of ANSI C which
incl
Friend in the magic:
My name is Eduardo Hernando, and I am devoted to maker of electronic effects
for magicians, I would like if it is possible you to insert my link in your
web.
I would be pleased if you would agree to add my page to your website.
If you would like to, let me know, an
Brian Feldman wrote:
>
> On Wed, 10 Mar 1999, Garrett Wollman wrote:
>
> > < > said:
> >
> > > I have to concur. I've never understood the "don't worry be happy"
> > > point of view on this issue.
> >
> > Do you always compile and install all your programs with debugging
> > symbols?
>
> This
In message <199903101944.laa57...@apollo.backplane.com>, Matthew Dillon writes:
>I don't use DIAGNOSTIC because it's overly intrusive and cause cause
>panics or create bugs where none exist.
Then it should be fixed.
>Personally, I would be happier if DIAGNOSTIC were ripped out entir
I don't use DIAGNOSTIC because it's overly intrusive and cause cause
panics or create bugs where none exist.
At least that was true in 2.2.x. I remember trying to use it at BEST.
The result was continually crashing machines due to bugs in the diagnostic
code ( such as diagnos
You two are basically discussing "overspecifying source code" vs
"normal source code". It doesn't really matter much if the
overspecifying consists of merging the TeX sources for a book or
by adding invariants as part of design verification. The discussion
itself has about as much merit as our
:Uh, no. Invariants are for developers who want to make sure their code
:is correct. There is no reason why an end user would want to build a
:kernel with invariants enabled. Invariants will *not* increase data
:safety. If they have any effect at all (i.e. if they actually catch a
:bug), the resul
:No, it is not - not in the general case, and not in the long term. I
:was trying to point out that there may be extreme cases where an
:otherwise harmless bug would cause a panic with invariants enabled.
:
:Matt claimed that invariants increase data safety, which I find
:difficult to understand.
:
:We were talking about invariants, which document the conditions which
:nearby code expect and/or cause. To actually check these conditions
:in a production system is a waste of CPU power; their function is to
:define for the developers precisely what the expected outcome of a
:particular operatio
< said:
> No, but I didn't think that was what we were talking about. I thought
> we were talking about assertions.
We were talking about invariants, which document the conditions which
nearby code expect and/or cause. To actually check these conditions
in a production system is a waste of CPU
On Wed, 10 Mar 1999, Garrett Wollman wrote:
> < said:
>
> > I have to concur. I've never understood the "don't worry be happy"
> > point of view on this issue.
>
> Do you always compile and install all your programs with debugging
> symbols?
This is the DEVELOPMENT branch of the FreeBSD proje
On Wed, 10 Mar 1999, Garrett Wollman wrote:
> < said:
>
> > I have to concur. I've never understood the "don't worry be happy"
> > point of view on this issue.
>
> Do you always compile and install all your programs with debugging
> symbols?
No, but I didn't think that was what we were talki
sth...@nethelp.no writes:
> > Uh, no. Invariants are for developers who want to make sure their code
> > is correct. There is no reason why an end user would want to build a
> > kernel with invariants enabled. Invariants will *not* increase data
> > safety. If they have any effect at all (i.e. if t
< said:
> I have to concur. I've never understood the "don't worry be happy"
> point of view on this issue.
Do you always compile and install all your programs with debugging
symbols?
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.
On Wed, 10 Mar 1999 sth...@nethelp.no wrote:
> > Uh, no. Invariants are for developers who want to make sure their code
> > is correct. There is no reason why an end user would want to build a
> > kernel with invariants enabled. Invariants will *not* increase data
> > safety. If they have any eff
> Uh, no. Invariants are for developers who want to make sure their code
> is correct. There is no reason why an end user would want to build a
> kernel with invariants enabled. Invariants will *not* increase data
> safety. If they have any effect at all (i.e. if they actually catch a
> bug), the r
On Tue, 9 Mar 1999, Archie Cobbs wrote:
> The jikes Java compiler relies on an include file "whcar.h" being
> on the system. However, even if it's not, it includes routines
> to do what it needs... only about 40 lines or so for these functions:
I was bitten by this one recently too, and there are
Matthew Dillon writes:
> I would disagree with that. Invariants are for people who want
> their data to be as safe as possible and don't mind eating a little
> cpu doing extra sanity checks in the kernel. It is something I would
> almost certainly enable in a production kernel.
p...@originative.co.uk wrote:
>
> Hmm, feeling of deja-vu here :-)
It was on purpose. :-)
> Why do we need three levels of config files? Can't we make do with two?
Yes, two are enough.
> Configuration of the system is becoming more and more of a horrible mess of
> spaghetti.
That's an unavoid
> -Original Message-
> From: Daniel C. Sobral [mailto:d...@newsguy.com]
> Sent: 10 March 1999 03:47
> To: curr...@freebsd.org
> Subject: HEADS UP: new loader.rc stuff
>
> Meanwhile, the new loader.rc stuff, for those who want it. It is
> modeled after rc.conf files. We now have a
> /boot/d
33 matches
Mail list logo
