I'd like it if I could find out how to get a simple libdl implemation (or at the most tips). My kernel is the dyn. linker, and everything will be exported via a user-space libc implemation.
My shared libraries end with .so, like in Linux and maybe other OSes. So far I'll be making a ATA driver and I should get a working minimal VFS. Otherwise, I would be looking a complete libdl with dl{open,sym,close} so I can port Python and possibily GNU bash with ncurses.
libdl implemation?
libdl implemation?
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
Re: libdl implemation?
Hi,imate900 wrote:I'd like it if I could find out how to get a simple libdl implemation (or at the most tips). My kernel is the dyn. linker, and everything will be exported via a user-space libc implemation.
My shared libraries end with .so, like in Linux and maybe other OSes. So far I'll be making a ATA driver and I should get a working minimal VFS. Otherwise, I would be looking a complete libdl with dl{open,sym,close} so I can port Python and possibily GNU bash with ncurses.
If you're only just making an ATA driver and minimal VFS, you're miles away from porting bash, and even further away from porting python. You can't possibly imagine the work that is needed to port that beast!
Cheers,
James
Re: libdl implemation?
I understand what I'm doing, I even use a Linux that is compiled from source as package manager. I implemented dlerror(), but yes, it's too early in the way. I'll just write my OS and see if it works before going ahead and porting stuff to it. So, now my kernel has no dyn. linker, but now the question is: How am I going to map my kernel to a processes' address space?JamesM wrote:Hi,imate900 wrote:I'd like it if I could find out how to get a simple libdl implemation (or at the most tips). My kernel is the dyn. linker, and everything will be exported via a user-space libc implemation.
My shared libraries end with .so, like in Linux and maybe other OSes. So far I'll be making a ATA driver and I should get a working minimal VFS. Otherwise, I would be looking a complete libdl with dl{open,sym,close} so I can port Python and possibily GNU bash with ncurses.
If you're only just making an ATA driver and minimal VFS, you're miles away from porting bash, and even further away from porting python. You can't possibly imagine the work that is needed to port that beast!
Cheers,
James
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
-
- Member
- Posts: 524
- Joined: Sun Nov 09, 2008 2:55 am
- Location: Pennsylvania, USA
Re: libdl implemation?
A dynamic linker doesn't do that. There is no linking (in the shared library sense) between your kernel and a process. Instead, the process uses system calls (interrupts, call gates, syscall, sysenter) to communicate with the kernel. The kernel mapping is fairly static, you just have to put the kernel's page tables in the page directories of all your processes.So, now my kernel has no dyn. linker, but now the question is: How am I going to map my kernel to a processes' address space?
Re: libdl implemation?
Ding! I need to get ELF working!JohnnyTheDon wrote:A dynamic linker doesn't do that. There is no linking (in the shared library sense) between your kernel and a process. Instead, the process uses system calls (interrupts, call gates, syscall, sysenter) to communicate with the kernel. The kernel mapping is fairly static, you just have to put the kernel's page tables in the page directories of all your processes.So, now my kernel has no dyn. linker, but now the question is: How am I going to map my kernel to a processes' address space?
Current work on a OS: SauOS (project homepage: http://code.google.com/p/sauos/)
Re: libdl implemation?
Actually python does not require libdl unless you need that functionality included in your python port. It's quite straight forward to strip away unneeded functionality (or functionality not supported by the OS) from python.JamesM wrote:If you're only just making an ATA driver and minimal VFS, you're miles away from porting bash, and even further away from porting python. You can't possibly imagine the work that is needed to port that beast!