Date: Sun, 31 Mar 2002 02:51:24 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Emiel Kollof <coolvibe@hackerheaven.org> Cc: Doug White <dwhite@resnet.uoregon.edu>, "A.Z." <synfin@unixroute.com>, freebsd-current@FreeBSD.ORG Subject: Re: kldxref problem Message-ID: <3CA6EA2C.E814420C@mindspring.com> References: <20020330205329.D51062-100000@resnet.uoregon.edu> <3CA6BFE4.8296DF74@mindspring.com> <1017571105.901.4.camel@loki.ipv6.hackerheaven.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Emiel Kollof wrote: > On Sun, 2002-03-31 at 09:51, Terry Lambert wrote: > > Perhaps if the kernel printf also "ignored" the request to print > > the little S.O.B. out, there would be less confusion... > > I'm still sticking to the idea that one could test for kldxref, and if > it isn't there, don't execute it. > > [ -x /usr/sbin/kldxref ] && /usr/sbin/kldxref > > like so, which is perfectly sane bourne shell syntax, which is also used > by BSD make. Like someone else says, work around it or deal with the > users that don't get the (ignored) part. If failures are ignorable, then it shouldn't try, since attempts are ignorable (might as well "fail" up front by not even trying, and not generate the message, if failing's an OK thing to do). It seems to me that there are four potential cases: 1) It's not there, and it's not OK. 2) It's there, and that's fantastic. 3) It's not there, and it's not OK, but instead of stopping, the code is going to do some half job where you don't get everything, and then bitch about it in such a way that it will be hard to find the source of some failure later, if someone really cared about the failure enough that complaining about it is important in the first place. 4) It's not there, and it's OK, but the code is going to bitch about it not being there anyway because it likes to add to the amount of entropy in the universe, and this is an easy way to do it that's unlikely to get fixed. It seems to me that #3 and #4 are bad, and should be removed from the realm of allowable output. I think the "test to see if it's available" hack you suggested is #3, without the code bitching about it, which is even worse than #3 as it is. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CA6EA2C.E814420C>