OSDev.org

The Place to Start for Operating System Developers
It is currently Tue Mar 19, 2024 4:42 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Thu Mar 03, 2016 3:27 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
Aside from some cleanup on web links, Owen has kindly provided me with write access to the PDCLib repository.

I'm in the process of re-familiarizing myself with the project structure, the changes and improvements done by Owen, and the different environment. (I've never worked with either Jam or Mercurial so far.)

My first couple of changes will probably be related to various compiler warnings I am getting (something I was always a bit OCD about), and applying the patch suggested by darkinsanity. (I don't have clang set up ATM, but it seems to make sense and I'll take his word for it.) A good way to get back "the feel", without being disruptive.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Thu Mar 03, 2016 4:43 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
I see I have a lot of my ancient pdclib stubs to replace with proper versions :D

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Mon Apr 04, 2016 12:29 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
A quick update.

Owen did significant improvements to the (rather broken) <stdio.h> implementation I delivered in v0.5. This, however, was entwined with adding <threads.h>, multibyte and wide character support, and a couple of supported platforms (splitting the test-only "example" platform into "example", "posix", "win32", and "gandr") -- which I, personally, would not have tackled before <stdio.h> was truly patched and fixed.

I found it difficult to re-orient myself amidst the numerous (helpful) changes Owen did to the codebase, and pretty quickly met the point where I was afraid that further changes would bring more harm than good.

I created a branch at the point where Owen took over in 2012, to "retrace" his steps. There were several ideas behind this:

  • Being able to work from a "familiar" codebase;
  • working toward an understanding of Owen's changes and additions step-by-step instead of all-at-once;
  • not getting tangled between "content" changes and "style" changes;
  • verifying that implementations are "correct" and "complete", again step-by-step.

The idea was to reach a point where I could merge "my" branch and "Owen's" branch to, basically, form a release-worthy v0.6 I felt I could competently support and maintain toward later releases.

Seeing how <threads.h> figured prominently in Owen's changesets (and, really, should be considered from the start for the various thread-static things necessary for locale / multibyte / time support), and seeing how <threads.h> included <time.h>, I figured I'd start with creating a <time.h> implementation (which is missing from Owen's branch).

This was a part of the standard I haven't looked at or used before, and a fine bag of laughs it is. Not because of any shortcomings in the standard, but because a) times and dates are a rather non-trivial subject, and b) Linux did a rather poor job abstracting the kernel interface at some point. For <stdio.h>, there are things like open() / close() / read() that work just fine as lib-to-OS plumbing, but in the time area, the borders are entangled indeed.

I think I got it, though.

So, at this point I have time(), clock() and timespec_get(), i.e. the functions to get time information from the kernel, and strftime(), i.e. the function to print time information in custom format.

The next thing is the implementation of time zone and DST support... which is entangled with locales, and stdio... which in my branch is not reliable yet.

Oh joy. :-D

I've just downloaded the tzcode / tzdata packages from http://www.iana.org/time-zones, and will keep hacking this into submission. Stay tuned. ;-)

----

Post Scriptum: Of course the "default" branch remains the one to download / use at any point. After all, it is the one with the working <stdio.h>... I will merge any significant improvements of the "retrace" branch back to "default" at regular intervals.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Mon Jun 11, 2018 4:20 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
After Rink Springer buggered me about the lack of work done on PDCLib, I took the project under my own wing again.

https://rootdirectory.ddns.net/dokuwiki/doku.php?id=pdclib:start

There is branches/shepherd, and trunk (my own work, formerly "retrace" branch).

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Mon Jul 05, 2021 3:40 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
I just realized this thread ranks pretty high in search results on PDCLib, and that link I gave in the last post has gotten stale, so...

The PDCLib website always had, and hopefully always will be, available at http://pdclib.rootdirectory.de.

_________________
Every good solution is obvious once you've found it.


Last edited by Solar on Mon Jul 19, 2021 4:51 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Fri Jul 16, 2021 1:43 pm 
Offline
Member
Member
User avatar

Joined: Mon Jun 05, 2006 11:00 pm
Posts: 2292
Location: USA (and Australia)
I had success porting Musl to my non-POSIX OS.

There's a syscall function with one giant switch statement, then in each implementation file I print "System call x is unimplemented". (I generated everything up to this stage btw, I didn't do this all by hand!)

Then, as I use the C standard library and try to do something, I emulate what the syscall would do.

_________________
My OS is Perception.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Fri Jul 16, 2021 1:46 pm 
Offline
Member
Member

Joined: Tue Feb 18, 2020 3:29 pm
Posts: 1071
Great project, @Solar! I will probably port PDCLib as my libc when I get there to be free from licensing stuff, and because it looks super easy to port.

_________________
"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Fri Aug 13, 2021 5:57 pm 
Offline

Joined: Wed Aug 05, 2020 3:38 pm
Posts: 9
There's also https://github.com/managarm/mlibc/ that I contribute to along with other managarm developers. It's MIT licensed so that should prove no issue and I think it'd be interesting to have a non-POSIX OS to check our portability, so to say. We welcome more OSes.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group