PDCLib

[Knyght]

I'm quite new to this. After some pondering about whether I want a vga console driver in my microkernel I decided that I probably do want it so that I can spam error messages if things go wrong before the other stuff gets to load. Anyway, after reading up on VGA, which seems simple enough, I figure I'm probably going to start needing stuff like memcpy and friends. So I figure the easiest and probably best way is to just use PDCLib and use the functions from there rather than reinventing the wheel.

But I have no idea how to do this. From what I gather from the rather scarce documentation, I need to implement (or at least dummy-implement) some system calls and set some constants by messing with the example platform files and then overwriting them back over the main directory, which seems simple enough. After that, I'm not sure what to do so that I can access this stuff from my kernel. Some insight (or a hand-holding guide at this point) would be appreciated.

Thanks.

[Griwes]

Stuff like memcpy and friends is dead simple, if you cannot write then reasonably quickly, you should probably consider another hobby. Also, OSDev is entirely about reinventing the wheel; why don't you want to do it with dead simple functions?

Also, don't expect hand holding and detailed step by step guides above "how to boot my kernel" level here.

[Knyght]

I could write that stuff very quickly and easily yes, but I figure that since they're in the standard library, why bother to write it only to replace it? Personally I think that having the C library around from the start just stops me repeating myself and having to incrementally add more functions that I would just replace later when I did switch to PDCLib.

And yes, I realise the whole thing is about re-inventing the wheel, but rewriting the standard library (or even a subset) isn't my idea of fun, really and I'd rather be spending my time on the stuff that I consider to be fun.

[JamesM]

I could write that stuff very quickly and easily yes, but I figure that since they're in the standard library, why bother to write it only to replace it? Personally I think that having the C library around from the start just stops me repeating myself and having to incrementally add more functions that I would just replace later when I did switch to PDCLib.

And yes, I realise the whole thing is about re-inventing the wheel, but rewriting the standard library (or even a subset) isn't my idea of fun, really and I'd rather be spending my time on the stuff that I consider to be fun.

Only a very very very small subset of the C library will actually run baremetal. Most of it requires some underlying support such as malloc/sbrk/mmap at the least.

It's not worth the pain, IMHO. Just implement memcpy,memset,strlen,strncpy and printf yourself. That's all you need.

[Owen]

Now that I've taken up the reins, PDCLib's build system no longer copies any files around; it builds them straight from the source directory.

It provides it's own malloc (actually dlmalloc, found in opt/dlmalloc), which requires you to provide a memory allocation function. You can stub that out for now: stdio works without it.

It also needs the C11 mutex functions. You can find stub (single thread emulation) implementations of those in opt/nothread

Your best bet is to copy the example (stub) implementation and work from there, using the win32 implementation as a guide (it is the most complete)

IO goes through the _PDCLIB_fillbuffer/_PDCLIB_flushbuffer methods. IMO, these aren't well enough factored (i.e. they require too much messing with the internals of the IO system), so I will be cleaning those up soon. It's on my todo list, or rather, in the bug tracker

Porting PDCLib will likely be significantly easier and quicker than implementing a full printf on your own. Before I'd even started working on the project and gotten used to the codebase, it took me ~30mins to port it to run in my kernel. It is far easier to port than newlib, for example (which requires malloc before stdio can work).

[Knyght]

I have decided that my kernel will simple enough that I don't even need that much stuff. So yes you guys were right.

Owen, is there any chance you (or anyone really) could throw together a tutorial on porting PDCLib for a pretty barebones minimal kernel? It'd be useful not only for me if I do decide to do this, but for many others I expect.

[Kevin]

There's a Readme.txt. Read it. It's really not hard.

The one thing that I found less than optimal in the past was upgrading PDCLib. It's really nasty if you have to check and forward port all of your platform specific code. That's why I tend to keep sitting on old PDCLib versions...

[Owen]

I have decided that my kernel will simple enough that I don't even need that much stuff. So yes you guys were right.

Owen, is there any chance you (or anyone really) could throw together a tutorial on porting PDCLib for a pretty barebones minimal kernel? It'd be useful not only for me if I do decide to do this, but for many others I expect.

More comprehensive documentation is on my todo list.

The one thing that I found less than optimal in the past was upgrading PDCLib. It's really nasty if you have to check and forward port all of your platform specific code. That's why I tend to keep sitting on old PDCLib versions...

This is one of the reasons I want to churn the I/O APIs now, rather than later. Where feasible, I want the PDCLib <-> Platform to "smell like" POSIX in broad strokes; and looking at POSIX provides a system which has well understood flaws.

Obviously if you restructure PDCLib you'll have more trouble moving to newer versions. I have PDCLib as a mercurial sub repository and just have the build system enter PDCLib as a normal sub directory. Actually, the tricky part is going to be enabling it to be built multiple times (potentially three: bootloader, kernel, userspace)