Hunting Fopen Source

[MadDog]

There is very little I need from the std libs so i'm looking for the source that I need and robbing it. But i'm being thwarted by the mass of source files and not knowing the gcc + Linux way of doing things. In the demo frame work there is a file open and close, these I beleave are the low level OS versions. Thats cool as my file code only needs open, close and read a block of data.

So, I have the source to gcc 4.0.3 the version the sdk is on, I know my start pos, fopen. I know the end point, an swi call. Using this I should be able to work out how its all stitched together and so let me find all the other bits I need.

And this is where i've come stuck :blink: , I can not find the code for fopen anywere, in the FW source of in the gcc source. Any ideas????

 

[rixed]

Why do you want to use libc fopen instead of just plain unix open ?

 

[Squidge]

I can understand wanting to use fopen/fread/fclose/etc for porting apps, but if your writing your own, you are far better off using open/read/close instead, which map directly to swi calls and so will be the smallest to include.

 

[MadDog]

I'll rather use the lowest forms, thats what I do on windows. But as I don't know Linux dev that well I made the assumption that fopen was a good place to start looking, i'm hoping that some where down the line fopen is calling the low level os call. And in finding this I will also find the other stuff I need. Bit like trying to find london but only knowing that its on the River Themes and where the River Themes starts.

I think I found the code to open in the FW source, looks like it works out the device that the file is on then gets the open func for that driver and calls it. So, somewhere, if I understand things correctly, the libstdc++ source must be doing an interrupt call as the demo code is.

Mmmm, can't help to think i'm barking up the wrong tree.

 

[Squidge]

What 'other stuff' do you need? You already have access to open/read/write/seek/close, what else is there?

The 'lowest forms' on Linux are open/read/etc too (mapped directly to swi calls). The 'highest forms' are fopen/fread/etc.

 

[skeezix]

Size is so important you want to ditch fopen for open?

Don't want buffered streams?

Whacky We like abstraction layers.. tasty tasty!

jeff

 

[rixed]

fopen sometimes do a mmap instead of an open, anyway.

 

[Squidge]

but... abstraction layers add bloat!

 

[MadDog]

What 'other stuff' do you need? You already have access to open/read/write/seek/close, what else is there?

The 'lowest forms' on Linux are open/read/etc too (mapped directly to swi calls). The 'highest forms' are fopen/fread/etc.

I'm missing something here. :unsure:

At the mo I only link to stdc++, are you saying that the low level file ops are not a part of this lib? If not then what does gcc do when it hits these? My exec's are 1.2 megs (big assumption that this is due to the lib, but seemed a good place to start)

The demo frame work only has open and close, no read. (unless I missed an update, although I did check)


Thanks.

 

[Squidge]

If you want the low-level file i/o, it's part of the kernel. Goto \arch\arm\kernel\call.S in the kernel source to see the list. You'll see entries 3 & 4 are read & write.

When the library wants to use the low level routines, it simply issues a swi call with the arguments in the appropriate registers as documented in DZZ's demo tutorial. The swi call numbers can be found in the above file.

 

[MadDog]

If you want the low-level file i/o, it's part of the kernel. Goto \arch\arm\kernel\call.S in the kernel source to see the list. You'll see entries 3 & 4 are read & write.

When the library wants to use the low level routines, it simply issues a swi call with the arguments in the appropriate registers as documented in DZZ's demo tutorial. The swi call numbers can be found in the above file.

You little beauty this is just what i've been looking for, thanks Squidge.