OSDev.org

Dear All,

Thanks for your posts. It is really a useful discussion.
It is a very old linux code version 0.11, it may ugly, but it is a good start to learn/practice linux kernel. The linux OS/Kernel books are teaching us only the concepts, not the programming tricks used in realtime OS.

osdevkid wrote:The linux OS/Kernel books are teaching us only the concepts...

...used in the Linux kernel at that time.

For learning about what is possible in OS design, more generic books are advised. Without the knowledge of what Linux did not implement, you will always be tied to imitating Linux.

While early Linux sources might be a nice source for learning some tricks, they're a very bad source for learning about concepts. By the time Linux matured to 2.6.x, many of those concepts had been changed because they weren't so brilliant to begin with.

Dear Solar,

Solar wrote:

osdevkid wrote:The linux OS/Kernel books are teaching us only the concepts...

...used in the Linux kernel at that time.

For learning about what is possible in OS design, more generic books are advised. Without the knowledge of what Linux did not implement, you will always be tied to imitating Linux.

Yes, you are right.

Solar wrote:

osdevkid wrote:The linux OS/Kernel books are teaching us only the concepts...

While early Linux sources might be a nice source for learning some tricks, they're a very bad source for learning about concepts. By the time Linux matured to 2.6.x, many of those concepts had been changed because they weren't so brilliant to begin with.

Learning OS concepts from generic books is always good, however to get more confidence on OS, in particular, when we start learning, we need to refer atleast one free (simple) OS source code, that is defnitely not Linux 2.6.x , it may be suitable for professional people, but not for students like me.

This is my personal opinion, however experts like you know better and you are doing wonderful help and support for learners. Thanks lot.

JamesM wrote:If you're going to pooh-pooh something, please explain why so the OP can learn instead of being a whiny ***** about it.

So my options are to be either whiny ***** or to spoon feed the OP. Accusations like these were exactly what I was trying to avoid. Didn't you notice I advised her to study the code that GCC produces? Which I think is a good way to understand how inline assembly works. It helped me a lot at least.

Hobbes wrote:So my options are to be either whiny ***** or to spoon feed the OP. Accusations like these were exactly what I was trying to avoid. Didn't you notice I advised her to study the code that GCC produces? Which I think is a good way to understand how inline assembly works. It helped me a lot at least.

Her? or, Him?

Actually, I don't trust Avatar.

osdevkid wrote: Learning OS concepts from generic books is always good, however to get more confidence on OS, in particular, when we start learning, we need to refer atleast one free (simple) OS source code

I suggest to read at least

Tanenbaum-Woodhull: Operating Systems: Design and Implementation, ISBN 0-13-142938-8

The first part of the book is about generic theories, the second one is about a reference implementation (minix). It's clear, easy to understand, and minix' source is well and deeply discussed in this book. Although it is not a holy grail, on many topics it's too much minix oriented, but at least it has references for further readings.

Chandra wrote:You can't see that particular code in newer Kernel Souce. It is already depreciated. Instead, a newer method of delaying is introduced, by writing to the port that doesn't exit (0x80). This seems reasonable.

However, reading a port is less likely to have adverse sideeffects than writing a port - especially when something does turn out to be there.
I know a SVGA bios that used dummy IO reads, and by doing that it upset my prototyped VMM over it since it accessed "wrong" ports. I can't remember which port (and apparently, I did not document the port number either and somehow my intuition tells me it wasn't 0x080 :s). I would avoid using hacks and instead using an nsleep-like construction if a delay of any sort is warranted.

Yo,

Hobbes wrote:

JamesM wrote:If you're going to pooh-pooh something, please explain why so the OP can learn instead of being a whiny ***** about it.

So my options are to be either whiny ***** or to spoon feed the OP. Accusations like these were exactly what I was trying to avoid. Didn't you notice I advised her to study the code that GCC produces? Which I think is a good way to understand how inline assembly works. It helped me a lot at least.

That said, the topic is relatively trivial anyway, and it really generates no interest unless you simply wanted to get annoyed; the topic title is quite indicative of something newcomer related, so you could have just steered clear of it or browsed while scoffing before closing the tab in dismissal. You don't really have a duty to "break in newbies" or anything mind you

--Ijs
gravaera

Chandra wrote:Her? or, Him? Actually, I don't trust Avatar.

Well, we have to rely on something, don't we. It would be rude to call the OP "it", and female programmers may be rare, but not that rare.

gravaera wrote:That said, the topic is relatively trivial anyway, and it really generates no interest unless you simply wanted to get annoyed; the topic title is quite indicative of something newcomer related, so you could have just steered clear of it or browsed while scoffing before closing the tab in dismissal. You don't really have a duty to "break in newbies" or anything mind you

Okay, another option is not to reply at all. But inline assembly may be very tricky until you get the hang of it, and I tried to point the OP some direction. I am not annoyed at all, and I am sorry if I made the impression that I am.