OSDev.org

Currently, the wiki's entry on interrupts is highly x86-specific (even PIC-specific). In my opinion, for someone who wants to write portable code, it would be interesting to have some arch-independent description of the interrupt mechanism, and separate entries about the arch-specific bits.

Having collected some data on how it works on some past and current CPU architectures, I've begun experimenting with that. Here's a tentative rewrite of the "Interrupts in a nutshell" bit. What do you think about it ?

I don't mind splitting the (small) theory part out of the Interrupts page - actually it would probably be a good plan to move it to Interrupts (x86), move your page to Interrupts and add a forward to the platform-specific part.

I added a note on your Wiki user discussion page on the rewrite before seeing this here. I temper my Wiki remark a bit now that I see what you are trying to do - but only a bit. Take care not to start from too base a level.

The basic theory shouldn't need to be explained again, the real juicy bits are in the implementation.. I'd opt for a rename of that article as Combuster stated.

Solar wrote:I added a note on your Wiki user discussion page on the rewrite before seeing this here. I temper my Wiki remark a bit now that I see what you are trying to do - but only a bit. Take care not to start from too base a level.

I indeed have a tendency to explains the basics even when I'm talking about relatively advanced topics. Thanks for pointing it out I'll try to avoid this in further revisions of this page (even though I don't know which level of knowledge I should assume to be there... If people knew all those matters perfectly, wiki entries would be unnecessary and OS projects would succeed more often)

An idea I've had this afternoon is to introduce a sort of glossary for those who are unsure about some matters (short reminders of the difference between an interrupt and an exception, masking, what are software interrupts, different ways vectors can work, what are PICs and what can they do, interrupt priority mechanisms) and then to write a big table comparing various architectures on points where implementations differ and linking to the page of each arch.

Neolander wrote:...I don't know which level of knowledge I should assume to be there...

I would expect an OS developer to have a good grasp of what an interrupt is, in general terms, and I also expect an OS developer to have the documentation for his CPU of choice at hand (and read front-to-back at least once).

I know that many aspiring OS developers don't meet this criteria, but I do think that it's reasonable.

The job of the OSDev Wiki, IMHO, is to:

• summarize on a subject and give an overview (making the technical docs easier to comprehend);
• point out design choices involved;
• point out caveats, cross-subject considerations;
• provide exemplary, "best practice" how-to's where appropriate.

I.e., the Wiki should / could never be a replacement for the technical docs, but a supplement, providing those parts that are not immediately obvious from the official manuals but born out of experience.

I agree that perhaps the basic information need not be repeated.

To write portable code one needs to create a portable 'model' of an interrupt system that can be applied to a number of architectures. Perhaps your wiki entry could present the design of such a model.

gerryg400 wrote:To write portable code one needs to create a portable 'model' of an interrupt system that can be applied to a number of architectures. Perhaps your wiki entry could present the design of such a model.

That's the idea

Just dropping by to say I like that people are seeing the need to make the wiki articles more focused on design and not "tutorials", and that there are people interested in presenting good theory pages. Nice

--Peace out
gravaera

What would you think about something at this level of required knowledge ? Would it be a step in the right direction ?

http://theosperiment.wordpress.com/2011 ... l-alpha-1/

Well, nevermind, I had started to do too much things at the same time and this task didn't progress. I'll stop there, though I think that I could have done more in the right circumstances. If anyone else wants to work on this, he can use my draft in any way he wants, public domain, blah blah blah.