William Case wrote: > On Fri, 2008-07-11 at 08:04 +0200, Rene Herman wrote: >> On 11-07-08 07:25, William Case wrote: <snip> >>>> Please do, even if only with a large brush. Until then, at least I >>>> personally am going to view your model as a little ridiculous and >>>> of no substance or use. >>> >>> Suggest another one then. His definition suggests a library of >>> abstracted hardware access, device multiplexing (eg. multiple >>> programs use the network card at once), storage and retrieval of >>> data and other system services. How does that get me anywhere new? >> >> Why do you think you need to get anywhere new? > > We are both getting way off tack. > > I have done a substantial amount or reading a research to get to this > point. As well as spending many hours exploring the kernel on line. > I > am now ready to download the source and using git to delve into the > kernels workings. > > Some things I have learnt. The kernel code is long (over 6 million > lines by one count I read). It is complex, convoluted and often > confusing. Without changing the purpose of the Operating system, or > the > definition, one needs a mental model to find ones way around to > understand what lines of code are being used for which process. > >> Operating systems are not >> new and many intelligent people have thought about them over the >> decades and the above model that you say that (snipped) "could have >> been cut and pasted from the opening pages of any first year text" >> did not end up on those first pages for nothing. > > I am not trying to write a new first year intro. Let that one stand. > I > have read it in several texts. > > I did find that as I read and explored, that, like in all things with > computers, there are patterns. I assumed that if one could create a > mental image of the most important patterns and use that as a model > for > find ones way through the kernel code. > I disagree, when trying to find the closest tube station in London, I don't need to have a mental model for the entire road layout of the UK. A local A-to-Z will be much more useful than an atlas. In the same way, I don't need to understand every interaction if the Linux kernel, to write a device driver or even to port an existing architecture to a new board, I just need to know roughly what steps are required and how to interact with specific parts of the kernel. This has far more to do with understanding specific frameworks and run-time flow than having a over-all view of the kernel as a whole. The rest come with experience. > The only other alternative is to start at line 1 and memorize. Even > if > one only starts at line 1 of particular kernel task it could become a > lifelong task. > Given the number of texts you have apparently read, I'd have thought you'd already have a very good mental understanding of how a kernel functions, even if you can't put it easily into words. May I suggest that another way to understand the kernel may be to become familiar with it by doing something with it, be that porting it to a board currently not supported; add a device driver; fixing known bugs; try to make some subsystem or other more efficient, etc. > One pattern I noticed -- and it was not the only pattern -- was that > each process started by looking up the data (i.e. by using pointers) > supplied to it by a structure (struct). So that I didn't have to > retain > in my mind the side issues involved with creating a 'C' struct I could > use the shorthand designation of 'a table'. > > I could also see a pointer interrelationship between these tables. > > A second pattern was the number and nature of #defined CONSTANTS that > usually ultimately reflected the pieces of hardware on my system. > Yes - there's lots of structures and they may all be connected in one way or another by pointers. However these structures on there own will not provide the essential interaction with the hardware - it's the functions that you seem to be trying to overlook that do this and without them all you end up with is a lot of structures and possibly some (now) meaningless data. > It also seemed to me that in the end there where not that many > structures nor did they have that many fields that they couldn't be > quickly learnt. The code that was pointed to or the functions that > were > called could be learnt as the need or the desire arose. Which every > the > case, I would have a working bare bones mental image of the kernel to > call on. > >> >> You asked for (explicitly non-expansive) comments on your model, not >> for readers to provide another one even though Rik in fact did. >> Ofcourse, if you think you need more useful comments, the onus is on >> you to first explain why your model helps any. > > Well, if it is accurate it helps me. And I am pretty certain that I > am > not the only one in this world that tends to have a visual mind and > memory. > >> > Describing the kernel as a library, says to me there are 6 > million lines of code and that is the only way to view it -- from top > to > bottom. You have to because all those lines are in random order. > No - just not all neatly interconnected and used as a whole on it's own. The library view of the kernel is apt, the majority of the code within the kernel is functions used by processes of other software - the userspace. > >> Wouldn't you in that case agree I'd first have to >> explain WHY I'd like to do such a ridiculous thing in order to >> indicate >> to you that any comment you'd provide would have a chance of being >> useful; wouldn't just be swallowed whole into my intellectual vanity? >> > No, I am not exercising intellectual vanity. I am trying to assemble > an > intellectual tool or template that allows me to dive in. The usual > process with computing is to tell the student to select a problem, > then > sweat bullets and/or die of frustration trying to solve it. That to > me > is cruel -- it is the kind of thing that they do to medical interns > and > almost always unnecessary. > A really high level abstraction of the entire kernel really isn't going to help you dive in. Gaining a working knowledge of a complex code base is difficult, frustrating at times. It requires lots of time and patience. There isn't any way around this, short of getting someone else to do it. >>> As far as I can see each one of those tasks simply has code that >>> points to further code in the library. Libraries are simply a list >>> of definitions and functions. The particular library codes that >>> have to be pointed to for each task are in stored in a structure. You seem to be missing the parts of the code that actually _do_ something to the underlying hardware and hence the predominant reason for the kernel. >> >> And why does that view help any? What does it explain? Frankly, this >> table view you've outlined sounds as the kind of Unifying >> Encompassing Model every single one of us will have thought up back >> when we were >> naieve, beginning programmers. As indicated, you are here in very >> pragmatic surroundings and reality is that operating system kernels >> aren't collections of tables or any other neat abtraction but heaps >> and heaps of messy code... >> >> And sure, you can talk anything to any model, even if only by >> insisting that enough of that whch doesn't fit is an uninteresting >> detail (can you see I walked this road?) but the question of it >> helping any is the important one. > > All that I can say to that is I have made a very good living over the > years deconstructing, analyzing, and reassembling and documenting > logic > gaps in businesses, public policy and government programs over the > objections and obfuscations of experts, professionals, bureaucrats and > politicians. In forty years I never found a system that didn't have > patterns. > > I have used the same skills to learn computers. And in the end, over > the same type of objections, those skills have seemed to prevail. I can remember clips of people logging every result of the national lottery here in the UK when it started, trying to find patterns to predict the next weeks balls. Don't see any of those clips any more and haven't heared of anyone winning the jackpot may times over. There is a pattern: A machine (picked from a pool of machines) is used to pick 7 balls randomly from a set of 49 balls (picked from a pool of sets). It's just not the pattern that those logging the results we looking for. You seem to be looking at the kernel in the wrong way to find patterns. Martyn -- Martyn Welch MEng MPhil MIET Principal Software Engineer GE Fanuc Intelligent Platforms Tove Valley Business Park, Towcester, Northants, NN12 6PF, United Kingdom Telephone: +44 (0) 1327 359444 Direct Dial: +44 (0) 1327 322748 Fax: +44 (0) 1327 322800 email: martyn.welch@xxxxxxxxxxx web: www.gefanuc.com GE Fanuc Intelligent Platforms Ltd, registered in England and Wales (3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 729 849 476 GE Fanuc Intelligent Platforms Confidential and Proprietary. If you have received this message in error please notify us immediately and permanently remove it from your system and destroy any printed hardcopies. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
