OSDev.org

BI lazy wrote: @Solar: d'ya want a malloc/realloc/free library in your pdclib?

Most certainly. I had been looking at dlmalloc(), a PD implementation of malloc() that actually formed the base for Linux' malloc() implementation for some time (still?).

Mine is probably not the most sophisticated and most efficient one, but it does its job quite well - although it yet lacks hooks for semaphore locks/spinlocks around critical regions and hooks for the system call "gimme mo memory".

Any contribution is welcome. Even if it isn't "correct" code, working through two impelementations and coming up with the best of both is still easier than writing it up all on yourself.

BTW, there's no way around that hook into the kernel - that's sbrk() for you on POSIX systems.

I have not yet written a calloc (what properties does this one have?) nor do I consider my realloc a correct one (what is it expected to return upon failure?)

Amazing how far people get without having a standard at hand... You should be able to look it up in virtually every C language reference. Or try 'man calloc' on your favourite bash shell.

*hereby waives copyrights on the malloc of atlantisos* Take it and check it out, do whatever you like. It does have mutexes, but I don't know whether they work. You can take the mutex module too . They're in 0.0.2.1 (don't take the zip, winzip doesn't make nice zips)

well, then a simple STFW might do the trick too. *maaan, i'm in a lazy mood today*

well ... I think, I'll do something like morecore(), hm?

Or some #defines & #ifdef 's, maybe they do the trick?

stay safe.

Not sure what you're referring to, BI... how to implement your morecore() / sbrk() / whatever?

In regard to PDCLib?

In this case: The idea is to write PDCLib main code so that it calls a "personality" function - let's call it __pdc_getMemFromKernel(). The name doesn't really matter.

Then, to adapt PDCLib to your individual OS / CPU / compiler, you'll have to write a "personality module". Among other things, this module must somehow implement __pdc_getMemFromKernel(). That might be as simple as
or require some nifty mapping tricks, or whatever. If you think such modularized mapping would impact performance, you could add patches to your personality module that patch the PDCLib main code directly. (As you would do for any other platform-specific optimizations.)

You will then end up with a module that binds / interfaces the generic PDCLib code with your specific environment.

This module could be hosted in the PDCLib repository itself - I'll allow this for mainsteam operating systems. The preferred way, however, is to have the personality module in the code base of your OS, where you can quickly adapt it to any changes you make in your OS. (Since, as I said above, PDCLib will be rather static code once completed, with the only expected changes being bug fixes and possibly adaptions to platforms with so-far unconsidered capabilities.)

The latter form also would avoid any code for XYZ_OS getting stale in our repository, should the maintainer of XYZ_OS lose interest.

(Damn, seems like I have to write up some FAQ on all this... )

The hooks for the implementation of my own morecore are already present. Just need to *use them* damnit.

the ifdefs refer to: whether one wants to use sbrk() or morecore(): and as for the semaphor support: upon compiletime, just add a definition: USE_SEMAPHORES I'll of course offer the option to init a set of semaphores on the fly upon semget() when creating a new set. Just need some thinking on how to do it best. Maybe some parameter struct as I use it for the semop call? Just thinking ... *tick...tick...tick...*

this trick of yours with the define and the extra module is fine. This sounds like splitting the chunk in a generic lib (everyone needs math.h, string.h, stdio.h et al) and some os specific sub modules to be defined by the os developer.

stay safe

BI lazy wrote: this trick of yours with the define and the extra module is fine. This sounds like splitting the chunk in a generic lib (everyone needs math.h, string.h, stdio.h et al) and some os specific sub modules to be defined by the os developer.

Exactly.

It also moves the lots of #ifdef's out of the main code. Instead of:
...you get:
...and the person merging PDCLib with a specific environment must chose whether to use posix/__personality.h, sysv/__personality.h, or iso/__personality.h. You get the idea. Cleaner code, cleaner concept IMHO.

It also moves the lots of #ifdef's out of the main code. Instead of:

Code: Select all

#ifdef POSIX
...
#ifdef SYSV
...
#ifdef ISO
...

...you get:

Code: Select all

#include <__personality.h>

...and the person merging PDCLib with a specific environment must chose whether to use posix/__personality.h, sysv/__personality.h, or iso/__personality.h. You get the idea. Cleaner code, cleaner concept IMHO.

Why not a makefile change that adds
-DPERSONALITY=$(PERSONALITY)
and
PERSONALITY=PROPOS
when compiling, and then using a:

Hmm... nice idea, there - technically speaking. However, I seriously doubt there will be a makefile coming with the library... the preferences of the various environments are too different. One user would like to compile a .so file, another would want a .a archive, the next one wants to link statically...

Practically, I picture a personality module to have the same directory structure as the main code base, so all you'd have to "set" is (assuming Unix shell / fileutils):
(I.e., you copy your p. module over whatever is in /includes and /functions, and there you have your source tree ready to do with it whatever you like.)

i do doubt the macro expansion delves into filenames for includes. However, you could pre-include the personality header with the appropriate '-I path_to_personnality.h' ...

was my question THAT off topic? I asked about libc. Not even a titter? No? Tough crowd.

Pype.Clicker wrote: i do doubt the macro expansion delves into filenames for includes. However, you could pre-include the personality header with the appropriate '-I path_to_personnality.h' ...

As far as I saw the C preprocessor, it was a plain search&replace on the text after the define. That made some ioccc submissions neater, they did:
to obfuscate some more. Since it is a plain S&R (imo) it should replace the PERSONALITY in the text too. Not 100% sure though, might be it skips the bracketed stuff.

gives

hmmm .... I 've always thought, the <..> tells the preprocessor to search for the files in some directories indicated in $PATH or something similar. The ".." tell it not to search but use kinda relative path. Hm ...

BI lazy wrote: hmmm .... I 've always thought, the <..> tells the preprocessor to search for the files in some directories indicated in $PATH or something similar. The ".." tell it not to search but use kinda relative path. Hm ...

the <> tell it to search the default lib dirs (also those you specify with -I) and " " tell it to search the current dir first, and then those dirs.

Before anyone cries bloody murder, I know the pro-pos.org webserver is down. ::)

Turned out I screwed up several things when trying to install Subversion 1.0 from source tarball ([me=Solar]not good at ./configure && make && make install), the reinstallation from clean slate this morning turned out to be trickier than expected - and then I had to catch the train for work.[/me]

Will fix this evening - including web-based repository browsing for PDCLib sources.