Errors when cross-compiling the kernel

Those that cannot devise a properly working algorithm and write the code that implements it usually cannot write proper testcases either.
Clear examples are code to sort an array or to search a value in a sorted array using binary search. Remember "sorting and searching" by Donald Knuth?
It will take the typical singlestep-modify-test-again programmer many many iterations before he will be satisfied that the code works OK, and it will fail within an hour of first release.
The more theoretical approach will require some study but will pay off in reliability.
Reply to
Rob
Loading thread data ...
you're welcome, and I hope you're successful as well.
that's something I can't answer; it's just that I prefer more recent kernel versions out of principle :)
gregor
--
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/ 
 Click to see the full signature
Reply to
gregor herrmann
Mmmmm.... maybe it's time you considered drinking decaf!
;-)
Reply to
mm0fmf
Probably true, but I'd strongly suggest it is a skill that can be taught but that nobody ever bothers to teach it. Evidence: I've *NEVER* seen a hint of trying to teach it in any course I've been om or in any programming book I've read.
If you've seen this approach to testing taught, then please tell us about it.
I've not read Knuth, but I own and have read copies of Sedgewick's "Algorithms" and Wirth's "Algorithms + Data Structures = Programs", which I suspect is a fair approximation to having all four volumes of Knuth, and with the added advantage that these use Pascal rather than idealized assembler as example code. Sedgewicks' code is particularly easy to transcribe directly into C. Been there, done that.
Very true.
Dunno about 'theoretical', but if you start cutting code before thinking through what you must achieve, preferably by iterating it on paper or at least as a test file, until you understand what you're doing and can explain why it is the best approach to another programmer, then you're heading up a blind ally at full throttle.
On top of that there are probably issues with structuring the code that you didn't think of and that will bite your bum unless dealt with. IME Wirth's "top-down incremental development" approach helps a lot here. Look it up if you've not heard of it.
This approach solves many of the code structuring problems that bottom-up development can cause. Use it and be prepared to redesign/restructure/ replace existing code as soon as you realize that the code organization you started with is becoming harder to work with. These difficulties are only highlighting issues you should have fixed before starting to cut code. The only good way out is to admit that the code you've ended up with is crap and do something about it, i.e. rewrite/refactor the ugly bits and try to never make that mistake again.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Pure experience over a few decades, dear boy.
Anybody who claims to have written bugfree code that is more complex than "Hello World" is talking out his arse.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
I should have added that I've met so-called programmers[*] who couldn't write even that without introducing bugs.
*
One particularly memorable example cut COBOL I had to fix on the infamous GNS Naval Dockyard project. This clown didn't know that COBOL code drops through from one paragraph to the next by default and consequently wrote code like this:
PARA-1. NOTE sentences doing stuff. GO TO PARA-2. PARA-2. NOTE more sentences doing stuff. ...
Other contractors knew him from previous projects and said that they'd never seen him write a working program. He always managed to leave with his last paycheck just before the deadline for his program to be delivered. He was always known for turning up late, doing sod all during the day, staying late and claiming overtime.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Sounds like the guy was a genius to me!
Reply to
Guesser
That's probably because you only read books or attended cousre on 'programming; or 'computer science'.
Try reading books on 'software engineering' which cover all of this in far more detail.
indeed.
Been on projects run exactly like that.
or bottom up...
you have to do both., At the bottom emd you have to build the sort of library of useful objects to deal with the hardware or operating system interface. At the top you need a structured approach to map the needs of the design into one or more user interfaces, and in between is an unholy mess that is neither perfectly addressed by either method. In essence you have to think about it until you see a way to do it.
In general this takes about three iterations. because that's how long it takes to actually fully understand the problem.
Whether those iterations are on paper or in code is scarcely germane, the work is the same.
What is not possible is to arrive at a result that is problem free without actually understanding the problem fully. That is the mistake we are talking about. Top down or bottom up are just places to start. In the end you need top to bottom and all places in between.
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
No, it can be done, just not at the first pass.
its not hard to write and to test for bug free code for all the eventualities you thought of, its what happens when an eventuality you didn't think of comes along....
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
And then he went into politics?
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
My informatics teacher was focussing a lot on algorithms and proof of correctness, and explained a lot about the types of errors you have to watch out for. However, that is over 30 years ago. We also learned generic principles of compilers, operating systems, machine code, etc. I hear that today they only train you how to work in specific MS tools and if you are lucky present some info about Linux.
About books: what I found is that many books that explain programming do not cover the topic of error handling. It is left as an exercise for the reader, or as a more complicated topic not covered now.
In practice it is quite important to think about error handling before starting to write code. When it is added as an afterthought it will be quite tricky to get it right. (especially when it involves recovery, not only bombing out when something unexpected happens, and when some kind of configurable logging of problems that does not overflow during normal operation is desired)
My experience with larger projects is that a lot of time is spent discussing an error handling strategy and the result still is not satisfactory and often has a lot of variation depending on who wrote the specific module.
Reply to
Rob
One of my maxims is: "Our most important design tool is the wastebasket, and it is much underused."
Until you have considered several different approaches to writing a program (in enough detail to see the advantages and disadvantages of each), you have no idea whether you are proceeding appropriately.
An empty wastebasket is a sign of trouble unless you've done it before and know exactly how to proceed. (And yes, pencil and paper are the right tools at the outset. ;-)
One should never get too wrapped around the axle on the issue of bottom-up vs. top-down. Virtually every real programming effort will involve both.
Proper high-level structure is a result of top-down thinking, while efficient use of machines and libraries requires bottom-up thinking. When insightful top-down design and careful bottom-up design meet elegantly in the middle, a beautiful and efficient program is the result.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon
Hear, hear!
I'm in complete agreement. That's what I get for reading and responding in order of posting. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Reply to
Michael J. Mahon
My functions always check that functions they called completed correctly[1] and return appropriate error codes if they didn't.
That's where I get stuck though, the actual main program loop tends to just execute some "print error message and terminate" code or if I'm really feeling generous to users "indicate that operation failed and go back to main input loop" ;)
[1] of course the exception is the functions that "can never fail" [2]. No need to check those ;) [2] unless they do of course, but you'll never know because I didn't return any status.
Reply to
Guesser
But didn't using GOTO make you feel dirty?? :-)
Reply to
Rob Morley
On Fri, 20 Dec 2013 01:24:52 +0000 (UTC), Martin Gregorie declaimed the following:
It would take me half an hour of reading to even do that much in Java (and likely C#) since so much of them is buried deep in hierarchical module trees.
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
No. immensely relieved like when you have a bloody great crap and say 'there I did it'...
it enabled me to pull the project forward at least two weeks and deliver on time and on budget, and it was a lot easier to understand.
Sometimes 'go to jail., go directly to jail, do not pass go, do not
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
I'll drink to that. What I was really objecting to with bottom-up is the idea that you can simply keep on building upwards until you magically top it out and that this will give a good result. In practice I think you need to start with top-down and design far enough down to know what support modules you're going to need and how they'll fit together. *Then* you can do a bit of bottom-up design to build that layer.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
Well, now you've got a system with an excellent event logging system. The Linux logging subsystem classifies the events that get logged and can even give you control over which logged details get displayed and which log files they get written to. It even has configurable mechanisms to automatically discard old log entries. Take a look in /var/log to see what gets logged, at 'man logrotate' for how log files are managed and at 'man syslog' to see how to write log entries.
Use less and grep to search through the logs and display their contents.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
AFAIK it has no mechanism to control logging of earlier messages based on later events. e.g. you send all results of DNS lookups to the log daemon with some thread identifier and only when a "system unreachable" event occurs all the related DNS lookup results plus the event are written to the log. When the event does not occur the DNS lookup results are simply discarded.
This kind of functionality is what you require when you want detailed logs of events without logging loads and loads of information that is not required (in this example: all the lookup results that do not end in a failure at top level).
Usually programs in Linux resort to some kind of "debugging mode" where the program logs more verbosely when required during testing. However, in practice the debugging mode is not on when the failure occurs, or it is on all the time and the log gets flooded with useless information, possibly causing the disk to fill or the performance to worsen.
Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.