OSDev.org

Yesterday I wrote a message and I linked to the Ralf Brown's interrupt documentation hosted here. I do not like too much linking to a site like this (yet I did it again here). What would you think if we created our own database of important interrupts? It would contain only useful interrupts that are relevant (e.g. ones that are usually available). I think it could be very doable because there are no more than few dozens that are relevant. If more exotic interrupts are needed, the documentation could be found elsewhere. In the long run, it would make us more self-hosted. There will be questions about how to use a BIOS interrupt. Linking to our Wiki sounds much better than linking to some external site.

I think there should be one wiki page for every interrupt main service. Like "INT 0x10, AH=0x0E". Things like VBE should not be documented because there are official documents available. There might be copyright issues or is the Ralf Brown's list public domain? If it is, then we could make sure our database contains at least all the information that is available there. Of course, we should make it even better. The main benefit would be that it contained all the information that is relevant to us, OS developers.

Maybe this is ten years too late but what do you think? I am not asking "please do it for us" but I would contribute too. I am not willing to start if this is a stupid idea. Is it?

In a few years time everything will be UEFI anyway.

I do not like too much linking to a site like this (...) it would make us more self-hosted

The wiki is written in a completely different style than Ralph Brown's, and the RBIL serves a very specific purpose of it's own, so I don't see any reason not to link to it when relevant, nor to clone a selection of references for the sake of cloning it.

That said, the wiki already references a fair number of BIOS interrupts between the lines, but only because it demonstrates the functionality that comes with it, so I think the information you say you want on the wiki is for the most part already documented as such. It just happens not to be indexed in the fashion RBIL is.

I just want to add my 2 cents in that maybe one page per interrupt might be too much? Maybe, just having one page and using the sections ==== markers might be enough so readers can just use the table of contents generated on the page. But, that is just my opinion and subject to being wrong!

I agree with Combuster though that maybe (I have not personally made this observation because I do not use BIOS interrupts much) a lot of the interrupts are already documented. But, cloning it would not hurt and I do not think it would be a copyright infringement unless it was copied word for word and then would the guy who holds any copyright actually care or have a reason to sue over it?

Maybe it might be nice just to ask him. This seems to be his email ralf+ AT cs.cmu.edu.

The idea of having one page for every service is debatable. I think it would make the wiki page clean and not too verbose. The link would be something like this "http://wiki.osdev.org/INT10_AH0E". My vision is that it could be a safely shared link that would exist as long as this site exists.

mathematician wrote:In a few years time everything will be UEFI anyway.

I hope so but I dare to say that BIOS services are relevant to hobby OS developers for many many years. I know that my idea is not a great one. It is just a normal idea. It will not help much advanced users but could be a great help for beginners.

I'm in favor of this because our wiki is community reviewed. This is a very important property when so many tutorials and articles out there contain errors and omissions that causes us all trouble (or at least the newbies that end posting help requests here).

We may be able to ask for permission to relicense his interrupt list under CC0 and thus integrate it here=

Hi,

sortie wrote:We may be able to ask for permission to relicense his interrupt list under CC0 and thus integrate it here=

I'm not too sure now (can't find a discussion about it), but I think someone has tried that in the past - e.g. they tried to contact Ralph Brown to ask for permission to reuse parts of the interrupt list, and got no answer at all.

For what it's worth; I'm in favour of having BIOS interrupts in the wiki for a few reasons:

• Ralph Brown's Interrupt List is old and hasn't been updated. There are newer BIOS functions (e.g. AMD's stupid "int 0x15, ax=0xEC00" mess) and changes to old BIOS functions (e.g. "int 0x15, eax=0xE820" additions in newer ACPI specs).
• Ralph Brown's Interrupt List has a lot of unnecessary information (e.g. DOS function calls, TSRs, extensions, etc) that are mostly irrelevant and get in your way.
• It gives us a way to add links in the other direction (e.g. the BIOS function for enabling/disabling A20 could have a link to the A20 wiki page, etc)

The main problem here is that (if we can't get permission) it may be hard to avoid copyright issues without Ralph Brown's permission. For that reason, the entry for the each BIOS function in the wiki could/should have a link to the same BIOS function in Ralph Brown's Interrupt List, so that it's easy for people to check and fix anything that could seem like potential copyright infringement as soon as possible. This could also be used as a citation.

mathematician wrote:In a few years time everything will be UEFI anyway.

All real hardware will be UEFI sooner or later. However; people will still be writing and/or using emulators for the 20+ years after that happens.

Sadly, for computing nothing ever dies (not even ancient OS designs from the mid-1960s, even when its creators try to replace it with a better OS! ).


Cheers,

Brendan

I will try contacting Mr. Ralf Brown today. Just to open a discussion about this with him.

Note that the URL from the OP is not the official RBIL page; you can find that here. I'm saying this because it's possible that other lists might not be up-to-date (he suggests that it might not) and because it has contact information, along with some user-contributed interrupt descriptions that had not been merged with the official list.

Who is this actually for? Would it be so wrong just to provide some example code showing how to use the BIOS for the small number of interrupts that people will actually want to use if they've already written code to boot via UEFI and just want a quick fix for getting their OS to run on older machines too? The example code would cover all the pitfalls without copyright issues and make it simple, while comments would explain the complications (many of which only relate to ancient hardware which the programmer may not care about, so this would be an invitation for them to skip many of those sections). They could then adapt it to their own needs and look up Ralph's list if they feel the need to go off piste, but there isn't much reason for them to want to do so if their main way of booting is UEFI. This part of the process isn't the real work of writing an operating system, so it wouldn't be cheating - it would just be making it easier to get to the start line. There are unlikely to be many/any future BIOS developments, so it's really time to put it in a museum and not spend a lot of time providing extensive new documentation on it.

DavidCooper wrote:The example code would cover all the pitfalls without copyright issues and make it simple

I think it is better to have "reference-manual-driven development" than "example-code-driven development".

DavidCooper wrote:it's really time to put it in a museum and not spend a lot of time providing extensive new documentation on it.

I was not thinking that anyone should spend a lot of time documenting obsolete things. Only important and widely used BIOS functions would be documented. Those functions are not obsolete but will continue being an important part of the PC culture. I am not a fan of BIOS. I have supported UEFI from the very beginning of my OS hobby.

Ralf has not responded. Here is the message I sent (if anyone is interested).

If you send another one try using one or two sentences and no links to prevent it from going into spam. Like:

I was wondering if you got my previous mail or it went to spam about copying your interrupt list?

LOL, you know spam more likely to grab something with links and a bunch of writing maybe. Just an idea!

Pancakes wrote:If you send another one try using one or two sentences and no links to prevent it from going into spam

Yes, the message was not very good but I will not send another message. It is over and I might have missed my chance. If you just look at the message layout, it is likely to be categorized as a spam message. I try to learn from this and not to make this mistake again.