Date: Wed, 14 Apr 1999 10:31:32 -0400 From: MALCOLM BOFF <Malcolm_Boff@compuserve.com> To: Greg Lehey <grog@lemis.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Debug kernel by default Message-ID: <199904141031_MC2-71EA-853@compuserve.com>
next in thread | raw e-mail | index | archive | help
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. In the early days of FreeBSD when one was lucky if the system stayed up for more than 15 mins at a time I also thought that I needed more info to find out what was going on I did exactly what is being discussed here. I found that I did not have enough space to compile the kernel so I plonked in a bigger disk and upped the swap space. Of course I forgot as is often the case that when you do this kind of thing you actually change the conditions that existed at the time and a whole heap of different problems exhibited themselves. The moral here which as an experienced systems programmer I had ignored is that there is a world of difference between debugging an application programme and debugging an operating system. 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. 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. 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). Now to your comments which I found facetious but I will answer them anyway. > >> On Friday, 9 April 1999 at 11:12:41 -0400, MALCOLM BOFF wrote: >> I cannot really believe that this is being discussed in a serious >> way as a future proposal. While I accept that bugs in the kernel >> are notoriously difficult to locate I cannot accept that the majority >> of users of FreeBSD really want to have this imposed on them. > Have what imposed on them? An unnecessary modification to the 'make' of the kernel. >> I think that this will most certainly give potential business users >> the view that the product is in some way *wonky* and to be steered >> well clear of. > Yes, I think you're right. From now on, rather than try to fix the > bugs in the system, we'll just turn the screen blue and print out some > meaningless numbers. I like this idea and I have put some thought into it. I do however have a question about how you are going to acheive it when the kernel has just died. Sample code please ! >> What other version of UN*X is shipped with such a feature ! >> Would you buy it if it did ?? > Yes, I would, but I must be strange. The screenful of numbers > obviously sells, so we'll do that. And millions of Microsoft > customers can't be wrong: they don't want the bugs fixed anyway. There is this strange belief that flaming M$ somehow makes people happy and attempts to divert the eys of the reader away from the problem at hand. Can't we give M$ a rest and start IBM bashing which is another form of diversion that we haven't used for a while. >> 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 b) the placement of "well known" files (printcaps/termcaps) into other directories than /etc and c) the change of device names. I have seen no acceptable explanation as to why these changes took place at all. GNU has already stated that support for a.out format load modules will continue. 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. 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. 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!). I think that before you respond in the manner which you did you should perhaps consider that the people using this forum are customers of FreeBSD and should be treated as such and the mere fact that I do not agree with your proposal should not receive a response which suggests that it has come from God. Finally you asked does anyone which to VETO the proposal and the answer to this is simply that my small vote is YES. > Greg > -- > When replying to this message, please copy the original recipients. > For more information, see http://www.lemis.com/questions.html > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key Malcolm G. Boff 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?199904141031_MC2-71EA-853>