OSDev.org

Well, obviously, as the code would get more complex, it would be easier to write it in C or ASM from the beginning, but that would make it less portable. Portability is an issue that hasn't been discussed yet, and as being XML and that these files must be interpreted or compiled first, a kernel might choose to compile them to C, others to ASM. And then, when replacing the out command with real code, some OS's would have different functions for that. So, this specification could include a number of methods that the kernel has to implement and which XML methods access them and in which manner. This way, you would have "One driver, run everywhere" (got inspired by Java ), but the approach is similar to the one of GRUB (I know it's arrogant to compare this with GRUB, please forgive me).

By including "real" code directly into the XML file, the driver compiler would be more complex; it had to create various files and provide all required compilers (nasm and gcc, mainly) and linkers (I like ld), and so, it is impossible for a new OS (such as mine) to directly integrate these new drivers (unless you create the drivers at compile-time and link them into the kernel before sending them to the floppy, also an approach).

But I think Pype is right, one had to create a driver for a more complex device and look what the XML would look like. Right now, I've got only drivers for the PIT and the keyboard (and the screen ;D); as I'm still a beginner in the field, I'm currently implementing my memory manager...

If it's going to go through the XML and generate the code that it needs to compile then it could just as easily go through real source code/psuedo-code and make the substitutions. The only advantage you have with XML really is that it *looks* more portable to a human.

Well, I think it *is* more portable, because from XML, you can compile it to C, ASM, but also to Pascal and every other language you like. Only if you have embedded real source code, you have to compile them separately and link them together correctly. But real code would _only_ be acceptable if it didn't use any relevant functions. A relevant function is one that relies on the OS; so it would be ok to write a function to multiply three numbers, but it wouldn't if it mapped a function to an irq. If you look at the PIT code, it says at the beginnig:
If you noticed, I modified this line in the old post to be more XML-compliant ;D. But anyway, the trick is that every OS implements this kind of things different, and with real code, you must always port the code so that it works in you kernel. But here, the only thing that has to be ported by the developer (that is, *you*) is the module that compiles and links device drivers out of this XML code.

The main advantage of C is that it is shorter for some things, e.g. variable declarations, etc. So, modifying the PIT code to use C everywhere it is possible (non-relevant function calls), it would look like this:
I rewrote the driver in order to show the new concepts, but yes, I will try to provide a more complex driver in this format... As I said, I'm implementing my memory manager...

Reimplemented in a pseudo-code-thing that could be used just as easily and I find much easier to read (btw, you don't compile into C unless I understand the term wrongly, it would be translation). Functions provided by the system have a leading underscore.
Thus leading onto my point, this could be translated as easily (if not easier) than the XML example. Then consider how close this is to C, it could very easily be done in C style code and then translated into code that can be compiled by the system.

2 things you should consider here, both of which don't apply for XML (since the language structure is already defined):

- Learn 'flex' or some other parser/tokenizer. Flex and Bison make a good pair. Don't design a language you cannot write a compiler/translator for, and don't be afraid to add redundant information if it helps parsing (for example using the word 'function' before a function definition).

- Be very careful if you rely on whitespace for information, eg. use indentation to identify a block of code. Using an opening tag ('{' or 'begin') and a closing tag ('}' or 'end') is in my opinion much better. It could also make parsing easier. Just don't write something like make ("It's got to be a tab character, 8 spaces is not good enough").

lol, I didn't even notice my use of whitespace, Python habits are getting to me now. Though I do like using whitespace in the form of indentation to define code blocks, looks neater to me.

Also, remember that was just chucked together to illustrate my point, it'd obviously need some tweaking to be used properly.

Well, we could go a step further and just add semicolons at the end of each statement, and there we almost have got valid C code!

So, instead of an XML parser, we could use a kind of compiler instead, but one that replaces all system functions with the OS specific ones. Yes, it would actually be a compiler that just performs a few replacement routines on it's syntax tree!

Hey, think about it! With this, we could also make the compiler mostly the same for all systems. Maybe it would be possible to hack gcc and add this part as a module, I don't know. This module could read the statement replacement rules out of a file (XML would fit here, I think).

If this were possible, the following steps would be necessary to implement this interface:

- Implement the framework (driver module manager, microkernel/hybrid (easier than monolithic, I think) maybe internet downloads, etc.)
- Include the gcc module
- Provide an adequate XML file that tells the module how to replace the "system calls"

You didn't even have to create the driver code, as they could be created by the community and released to public domain (I'm afraid this is necessary (no (L)GPL) in order to allow mayor commercial OSes support the standard and develop for it). This would be compliant with the original philosophy of this to make the os dever's life easier and allow them/us to focus on our actual os design.

That's what I've thought about, but it surely could be improved.

And someone gets my point ;D Glad to know I'm not quite crazy enough to be imagining making a certain level of sense.

I go away for a month and someone has another OS-independent driver idea.

Can I ask the question of how drivers are going to be downloaded over the internet without a preexisting internet driver? This worries me, because some people have esoteric network devices that act up or won't work. This would prevent you from getting drivers, ie: getting the driver for the device acting up.

Note that the above situation actually ocurred for a while when I installed Gentoo.

Well, that's the chicken&egg problem, but if you read all of the thread, then you'll have noticed that after a few replies, the internet idea was more or less dropped... But as I said, the OS could work with a few drivers that provide only basic support for the widest possible product range of e.g. ethernet cards and then, use these basic drivers to get full-fledged drivers, with the URL provided by the device. But I don't know; I think it would be too much to ask (some) device manufacturers to join an open-source effort... :-\ But as we discussed later on, you could still use the idea to provide a standard device interface language...