Date: Thu, 15 Apr 1999 10:36:31 +0930 From: Greg Lehey <grog@lemis.com> To: MALCOLM BOFF <Malcolm_Boff@compuserve.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Debug kernel by default Message-ID: <19990415103631.G23745@lemis.com> In-Reply-To: <199904141031_MC2-71EA-853@compuserve.com>; from MALCOLM BOFF on Wed, Apr 14, 1999 at 10:31:32AM -0400 References: <199904141031_MC2-71EA-853@compuserve.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 14 April 1999 at 10:31:32 -0400, MALCOLM BOFF wrote: > > Greg I have to say that this is a most unusual response > for you and I am somewhat surprised at this outburst but > guess we all have off days. I'm not sure what you're quoting, since you have not put this near anything I have said. But I suppose you're welcome to your opinion. > I think you should consider a number of things that can > and do occur. > > 1) The "system crashes" and dies (possibly leaving a dump > image). Here you are assuming that a system compiled with > a -g option will provide a solution to why the crash > occurred. This is rarely the case in practice but probably > was created by code several thousand instructions before > and corrupted the core giving an illegal instruction code > or an address violation. Occurrences of this ilk do not > in my experience occur very often and I feel sure that > "hackers" do extensive testing to prevent this occuring. I can see that you have never tried this solution. I debug kernel dumps on a regular basis. About 80% tell you (well, an experienced kernel hacker, at any rate) exactly what happened; with another 10% you can find out after a little searching. Maybe only 2% leave you none the wiser. But of course, if you're not prepared to try, you won't find out. > 2) The "system" does not crash at all but gives weird > returns to system calls causing applications to crash. > Here the approach is to first find out what the application > is getting back from the kernel. Does it give consistent > returns ? If it does then one can isolate the problem > and concentrate on the specific kernel code. I can't think of a good example of what you're talking about here, but again a kernel debugger would help. > All in all my view and experience is simply that symbolic > debugging of a kernel is just not a practical proposition. > You just got to do it the hard way (ddb raw). This says more about your view and experience than anything else. To your out-of-sequence comments on my reply: >>> I am beginning to wonder where FreeBSD is actually going as >>> a project as some of the things that have been done on the 3.1 >>> release seem to be moving away from a vein whereby an >>> "upgrade" becomes the norm and not an "install" as now seems >>> to be more the case. Perhaps the leaders of the project should >>> perhaps spend a little more time looking at "questions" for users >>> who have had or are having problems with 3.1 or even poll us >>> with what they intend to do next so at least we provide some >>> input. > >> OK, how about some input then? How would you have done the transition >> from 2.2.8 to 3.1? What's your objection to having information at >> hand to diagnose problems you're having? > > Here you assume that I have some other way of doing this > transition when at a more fundamental level I question > a) the jump to ELF Are you saying this was a mistake? You'd need to say why. > b) the placement of "well known" files (printcaps/termcaps) into > other directories than /etc /etc/printcap is still in /etc. /etc/termcap has been in /usr/share/misc for years. > and c) the change of device names. I have seen no acceptable > explanation as to why these changes took place at all. In regard to ELF, this shows your lack of understanding. In regard to the others, you might have an argument, but they're not exactly world-shattering events. > GNU has already stated that support for a.out format load modules > will continue. FreeBSD also supports a.out and will continue to do so. > I would be more than willing to input more to a "wishlist" > if one existed and I could be sure that the project > manager(s) actually read it and prioritised it which would > give us all an opportunity to contribute. You have your chance on FreeBSD-hackers. Don't overestimate the public value of your own opinion. > As I have previously referred to IBM I would suggest that > you seriously consider what they have done to meet the > needs of their customers eg Physical/logical volumes > which allow spreading file systems across disk boundaries > and allows the expansion/contraction of such file > systems without the need to 1) regen the kernel and 2) > permits the operation to be done on a live system. > This is just a simple example but does demonstrate the > point that I am trying to make. I've done a lot of consideration. It's very close to what Vinum does, but IMO Vinum does it better. Note that we have never needed to rebuild a kernel in order to change disk layout. > Or how about the base system using 'make' (as opposed to 'pmake') so > that the system is at least compatible with others (we have spoken > about this before!). This would be the kind of unnecessary change you were complaining about above. What's wrong with BSD make? In many way's it's superior to GNU/System V make. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990415103631.G23745>