DragonFly kernel List (threaded) for 2006-12
DragonFly BSD
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


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 6 Dec 2006 08:45:07 -0800 (PST)

: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]