A question on apps

lukem95 · Post by **lukem95** » Wed Aug 08, 2007 6:04 am

Hey, i'm not quite at this stage yet, as i havn't quite mastered disk I/O, but...

When i begin wanting to craft my own applications, how do they communicate with the operating system??

to put it a different way, how do i define printf(), would i do it the same way as in my OS, writing to the video memory or is there a way to send a message to my kernel and get it to do the printing?

Sorry if this confused you, it may be blindingly obvious but i can't see how it would work.

~Lukem

sancho1980 · Post by **sancho1980** » Wed Aug 08, 2007 6:23 am

its an ovious question and it took me a long time to understand as well
obviously, you cannot let applications do i/o, what you need is indeed a way to communicate to the kernel that you want some i/o done by the kernel on behalf of your application

there are many different ways how to implement this

but the bottom line principle is always the same: your application ends up issuing an interrupt, which leads to kernel code executing on your behalf

so in order to implement something like printf, what you might want to do is write these routines, compile them and place them in a seperate library.
when you then link your application to these libraries, you can call the i/o functions without having to care about how they are implemented.
that means the application programmer doesnt actually know anything about the interrupt thing, because all he does is call printf(parameter).
the printf function then takes care of placing the parameter(s) wherever your interrupt routine expects them and issues the interrupt

when you write a lot of code in c under linux and get used to using such standard library functions and then say to yourself you want to code a kernel yourself, its an obvious question to ask how this is implemented, so this is the answer (roughly)..everything takes place behind the scenes

the minix book is very instructive, maybe you want to read it

lukem95 · Post by **lukem95** » Wed Aug 08, 2007 8:36 am

Thankyou for your reply, thats helped me quite a bit.

I'll try and find the book i think, but as i said, i still have a little bit of time before i need to worry about this anyway.

Thanks again, lukem

AJ · Post by AJ » Thu Aug 09, 2007 4:36 am

Hi,

I havent got disk IO yet but do have user apps. If you want to do the same, let GRUB load a user app as a 'module'. Your kernel can then relocate the module and run it - a good way to play with user-space programs.

Cheers,
Adam

JamesM · Post by **JamesM** » Thu Aug 09, 2007 5:05 am

I get grub to load only one 'module' - my initial ramdisk. I use a similar system to linux in this respect, and have written the simplest file format ever for it (just headers then data. you can't write to it or delete from it. Why would you want to?). From that I can load several programs, support files etc. I need it because my disk I/O drivers are/will be userland programs

JamesM

lukem95 · Post by **lukem95** » Mon Aug 13, 2007 1:32 pm

Thankyou all for your help, one last thing however

how to you execute the application once you load it as a module?

do you point esp at the starting offset in memory?? or is that utter bullsh*t i picked up somewhere :S

lukem

jerryleecooper · Post by **jerryleecooper** » Mon Aug 13, 2007 9:30 pm

I just tought about a way your applications can issues commands to the kernel, by writing to some special addresses, which causes, if Im correct, some page fault, which handled correctly by the kernel, make it execute the function as defined by the 0x6536356 = SOME_FUNCTION, that execute the start of the function, you then send the rest of the parameter, and most important the magic number, 0xDEADBEEF, that must NEVER be a parameter nor a function, be the last thing you instantiat in your *0x6536356++ = thing, you get your function, and bonus you didnt use any interrupt, and the patent trolls cant claim they invented it.
Sorry if that doesn't work.

Edit: It will not work, but I keep it for posterity, I was a bit, em

? and

. I keep it for you to see, but don't take it seriously, please.

sancho1980 · Post by **sancho1980** » Tue Aug 14, 2007 12:40 am

jerryleecooper wrote:and bonus you didnt use any interrupt, and the patent trolls cant claim they invented it.

you would still be writing data to memory, something someone else has surely done before
how dare you at all make use of all the nice instructions in your cpu given someone else had found out they can be used to execute programs

AJ · Post by AJ » Tue Aug 14, 2007 1:47 am

lukem_95 wrote: how to you execute the application once you load it as a module?

do you point esp at the starting offset in memory?? or is that utter bullsh*t i picked up somewhere :S

I'm afraid it is, but don't worry - it's not much more difficult!

If your module is a flat binary, you need to copy the binary image to wherever it is linked to run and point eip to the first address. If you use an executable format such as ELF (which I would recommend, given the safety of knowing e.g. the BSS size), you will need to read the ELF header. This will tell you where to relocate all the various bits of the executable, and what the value of EIP should be initially.

Of course, if you want to do all this with multitasking, you will need to set up a new memory space, a separate stack and so on...

Oh - and stick with using an interrupt to communicate with the kernel rather than using odd page fault handlers

. Although using interrupts is theoretically slow, you can eventually convert to using syscall/sysret or equivalents.

Cheers,
Adam

lukem95 · Post by **lukem95** » Tue Aug 14, 2007 6:31 am

Thankyou

especially A.J lol

*gets to work with module's*

.. this may also be obvious, but i have absolutely NO clue how to do it.

I know that to "request" (??) a system call you push an identifier into eax and a pointer to any data into a register, then cal int 80h (or whatever i chose), but how do i get my kernel to realise its been called?

frank · Post by **frank** » Tue Aug 14, 2007 7:45 am

lukem_95 wrote:Thankyou

especially A.J lol

*gets to work with module's*

.. this may also be obvious, but i have absolutely NO clue how to do it.

I know that to "request" (??) a system call you push an identifier into eax and a pointer to any data into a register, then cal int 80h (or whatever i chose), but how do i get my kernel to realise its been called?

Add an interrupt gate to the IDT.

lukem95 · Post by **lukem95** » Tue Aug 14, 2007 10:43 am

haha it was obvious after all that

Combuster · Post by **Combuster** » Tue Aug 14, 2007 3:12 pm

frank wrote:Add an interrupt gate to the IDT.

Consider a trap gate as well. Interrupt gates disable the interrupt flag. that means that a system call can not be interrupted. This can have dire consequences: consider a read from a floppy that has to complete before another task can run.

Gizmo · Post by **Gizmo** » Wed Aug 15, 2007 8:27 am

If you don't want to use interrupts everytime you can make one interrupt that maps a shared area of data to your app and polls it (asyncronis i/o) so you can do other things like respond to the user input while your kernel reads from the floppy (just make the kernel a separate task).

As far as patents, this was/is all patented, but its patented by intel, amd, ibm, etc and they wouldn't be able to sell processors if they sued people for writing apps that run on their cpu architecture. (All of the cpu manufactures have long ago sued each other and settled so basically they all mutually own almost every x86 design patent, those that haven't expired after 7 years- all patents expire after 7 years)