> In article <linux.kernel.199810310122.UAA00331@hilfy.ece.cmu.edu>,
> Brandon S. Allbery KF8NH <allbery@kf8nh.apk.net> wrote:
> >In message <71dep8$ari@pell.pell.portland.or.us>, david parsons writes:
> >+-----
> >| david parsons \bi/ Pushing the published kernel interfaces into a shared
> >| \/ library is creeping dangerously close to the NT wad-o-
> >| dll's approach.
> >+--->8
> >
> >And what else is libc.so (aside from being one humongous DLL instead of a
> >bunch of smaller ones)?
>
> But that's not the kernel interface, that's simply a collection of
> nice wrappers around the kernel interface.
>
> Today I can write code that avoids libc altogether and continues to
> work, but if libc becomes the published interface, that guarantee is
> gone.
>
> ____
> david parsons \bi/ Yes, I do have some code that links with
> \/ ld -m i386linux -o $PROG $OBJS
And by working on my own libc (for an embedded system), I run into the
same issues. (It's already been Real Fun figuring out just which
variations of the deprecated syscalls are the best ones.) It's gotten to
the point that I have to look at an existing libc just to understand what
the kernel interface is trying to say.
Also, in my interpreter-evangelist hat, I'd like to be able to bind
anything to anything else, at any level, which at some point means
teaching an interpreter to talk directly to the kernel, without libc in
the middle. This ought to be possible.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/