Function conflicts between kernel and libc

[Matthew Dillon]

: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