DragonFly kernel List (threaded) for 2006-12
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: Function conflicts between kernel and libc
:maybe we should not link libc at all? or at least use a linker script wh=
:ich removes all functions from libc (won't work possibly).
:
:i mean, what do we need from libc?
:
:- write (syscall)
:- read (syscall)
:- open (syscall)
:- mmap (syscall) to get pages/memory
:- new VM syscalls
:- maybe ioctl (syscall)
:
:apart from that, the kernel is self-hosting anyways. maybe it will be le=
:ss effort to not use libc functions that to rename all overlaps. actuall=
:y, i'm sure about that.
:
:cheers
: simon
Well, there are so few symbols that overlap now that I would rather
take the simpler path and just make it build like a normal program
would, with no major special cases.
I don't think we should underestimate how little or how much of libc
we might want to use. For example, simulating a virtualized SMP kernel
could be made as simple as compiling with POSIX threads (though in
reality I would probably implement it directly with rfork and control
serialized access into libc manually).
In anycase, it is a non-problem. I've got some fairly trivial work
not yet committed after which the only functions left in conflict
will be *printf(). Those have to be separated anyhow since the
kernel printf and the libc printf are not compatible with each other.
-Matt
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]