Writting drivers

crackers · Post by **crackers** » Mon May 21, 2007 1:01 am

I want to add to my OS drivers which would be in seperate files, not as a part of kernel code. So I've created one driver for test and started to wonder what parameters should I give to linker since driver can be loaded into any place in memory. Code of functions it's not a problem since all calls, jmp's within driver are relative (not absolute). Problem is how can I post data from one function to another. For example let's say that we have driver that is responsible for reading data and there are 2 functions. One is a main loop that is run as a seperate task and second one is function that is being called by system to read or write data. How this second function can pass informations to first one?
1.One solution would be to link all drivers with the same address and in kernel set pages for each task related with each driver. With this it's possible to use global variables in drivers. But this solution is a little bit complex from kernel point of view since there is a need for creating page tables and what's more important before executing any driver function I would have to switch to task that would see driver at good location in memory.
2.Second solution would be to pass address of some common buffer to each function of driver. I think it's better than first solution but it's uncomfortable to pass these informations for all calls.
3.Third solution I thought about is most interesting in my opinion. I'm adding bogus function to each driver, than I'm calculating it's position (which is rather fast operation) and at the end I'm using it as a global variable (by overwritting or reading it). I've already implemented it and it's working fine, but I wanted to get others opinion. Maybe I'm not seeing something that will cause problems in the future.

Combuster · Post by **Combuster** » Mon May 21, 2007 1:58 am

Have you considered using relocation information? that way you can set the addresses at load time to whatever you want among any number of drivers without the need for elaborate hacks.

Besides, you should be aware that normal x86 code is not position-independent. References to data/bss space are absolute rather than relative and hence if the binary is loaded to a place it is not expected it will access the wrong memory areas.

crackers · Post by **crackers** » Mon May 21, 2007 2:09 am

Combuster wrote:Have you considered using relocation information? that way you can set the addresses at load time to whatever you want among any number of drivers without the need for elaborate hacks.

Relocation informations? Could you tell me what is that ?

Combuster wrote: Besides, you should be aware that normal x86 code is not position-independent. References to data/bss space are absolute rather than relative and hence if the binary is loaded to a place it is not expected it will access the wrong memory areas.

Yes I'm aware of it, but for gcc I'm getting good results - I've checked generated code and run through it with bochs debuger, but I will have to look if there is some magical switch in gcc that would force generation of relative addresses for instructions.

Combuster · Post by **Combuster** » Mon May 21, 2007 2:53 am

crackers wrote:Relocation informations? Could you tell me what is that ?

http://en.wikipedia.org/wiki/Relocation

crackers · Post by **crackers** » Mon May 21, 2007 4:02 am

So, if I understood corectly, there is additional table in such files that is being used as a reference and it's filled by kernel after loading executable file but before using it. If that's how it works than I'm wonedring how to determine where this table starts and where code is starting (I guess only one of these values can be at fixed position). Beside of that it's only moving problem to other place (instead of doing changes in driver I have to do it in kernel by filling this reference table).

TomTom · Post by **TomTom** » Mon May 21, 2007 4:11 am

That's correct. You're basically reading a table with offsets where your executable image loader needs to patch pointers. Once that is done you can execute the code.

mathematician · Post by **mathematician** » Mon May 21, 2007 7:50 am

crackers wrote:Beside of that it's only moving problem to other place (instead of doing changes in driver I have to do it in kernel by filling this reference table).

If your OS is going to load and run applications it is going to need a loader which can fix up executable files anyway.

crackers · Post by **crackers** » Mon May 21, 2007 11:36 pm

mathematician wrote:
crackers wrote:Beside of that it's only moving problem to other place (instead of doing changes in driver I have to do it in kernel by filling this reference table).
If your OS is going to load and run applications it is going to need a loader which can fix up executable files anyway.

Hmmmm why? Of course loader is needed but I can't see why it have to do any changes in loaded programs?

AJ · Post by AJ » Tue May 22, 2007 2:58 am

Well, it's going to at least need to relocate and zero sections of the executable as required...

crackers · Post by **crackers** » Tue May 22, 2007 3:29 am

AJ wrote:Well, it's going to at least need to relocate and zero sections of the executable as required...

Zero sections ? Hmmm I guess it's another new word for me

In my previous OS I was executing programs (only COM's) with only good paging mechanism so I still don't understand why I must interfere within loaded code.

AJ · Post by AJ » Tue May 22, 2007 3:38 am

If you are loading e.g. a COFF executable, you will have at least 3 sections: .data, .text and .bss.

* The .bss contains uninitialised data and must be zeroed - it does not actually exist in the file but you will have a table with data about where the section should start and how long it is.

* .text contains your code - supposing you load your executable file at a location somewhere in the kernel's page space, you will need to copy x number of bytes to location y from the executable file in RAM to wherever the file is going to execute from (you can then jump to the entry point at the appropriate time).

* .data should be treated as .text - it needs relocating.

There may be other sections e.g. .ctors and .dtors which need locating as appropriate.

Because the BSS is not present in the file and .text and .data are not necessarily aligned, you will find that a COFF (or other format) executable will be a lot smaller than its' flat equivalent. You also don't have to assume nearly as much as with a flat binary (for one thing, the entry point can be anywhere in the file).

HTH
Adam

crackers · Post by **crackers** » Tue May 22, 2007 4:29 am

AJ wrote: * .data should be treated as .text - it needs relocating.

I think that in normal tasks it's a better idea to just use paging - that way you don't have to do any changes in loaded code. Beside, is it always easy to change such informations in file regarding of compiler and linker that were used ?

AJ · Post by AJ » Tue May 22, 2007 4:50 am

No - you link at a certain address and the relocation information information in the COFF file is based on that base address. You don't have to change information so much as obeying the built in rules.

Sorry - I seem to have sidetracked you a bit as you were originally asking about dynamic linking which I have no idea about - maybe someone else is better placed to get this back on topic again...

Cheers,
Adam