libc and *nix - Unix

This is a discussion on libc and *nix - Unix ; My question concerns how the Standard C library is layered in OSs like unix. Does the Standard C library itself directly call system calls like the kernel does to implement the developer's requests ? Or does it call a more ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: libc and *nix

  1. libc and *nix

    My question concerns how the Standard C library is layered in OSs
    like unix. Does the Standard C library itself directly call system calls
    like the kernel does to implement the developer's requests ? Or does it call
    a more universal API ?

    I know linux uses posix unlike unix but there is something called
    pthreads that are a posix API for non-posix standard machines like unix.
    What type of system call API does unix use?

    Bill





  2. Re: libc and *nix

    On 8月10日, 下午12时16分, "Bill Cunningham" wrote:
    > My question concerns how the Standard C library is layered in OSs
    > like unix. Does the Standard C library itself directly call system calls
    > like the kernel does to implement the developer's requests ? Or does it call
    > a more universal API ?
    >
    > I know linux uses posix unlike unix but there is something called
    > pthreads that are a posix API for non-posix standard machines like unix.
    > What type of system call API does unix use?
    >


    In most of time libc call system call directly.

    POSIX unlike UNIX? I don't think so, most assemble.

  3. Re: libc and *nix

    "Bill Cunningham" writes:
    > My question concerns how the Standard C library is layered in OSs
    >like unix. Does the Standard C library itself directly call system calls
    >like the kernel does to implement the developer's requests ? Or does it call
    >a more universal API ?


    > I know linux uses posix unlike unix but there is something called
    >pthreads that are a posix API for non-posix standard machines like unix.
    >What type of system call API does unix use?



    Hmm, some confusion here.

    First off, POSIX is a standard for unix systems for what headers,
    libraries, APIs, etc. they have. pthreads is part of the POSIX
    specs. Other unix varients have had their own threading model pre
    pthreads standard, but then converged to it after it was part of the
    spec so programs can be carried over easily.

    You can probably think of POSIX as the standard that binds unix type
    systems together, not like linux has a native API, and a POSIX
    API. They are one in the same, and each vendor works to making their
    total system match what POSIX says is compliant.

    Just because Linux isn't 100% POSIX compliant, it doesn't mean that
    its not even close, its just that they don't care to make it 100% for
    whatever reason. Taking something that is 100% like Solaris, you'll
    find the APIs, system calls, etc. are interoperable in 99.99% cases,
    there's just a few odd things here and there.

    The system calls in libc on a unix type system map pretty much 100% to
    what the kernel provides. Ie. you look at the source code for libc for
    anything in section 2 of the man pages, you'll find a wrapper passing
    the args and trapping to the kernel in whatever way that OS on that
    architecture does it and returning the result code. Nothing more.

    Many varients of unix system have source code that is freely
    available. Many of them also have excellent books written about their
    inner workings (ie. 4BSD, Solaris, Darwin, Linux, or even old school, like
    SysV for Bach, etc).








  4. Re: libc and *nix


    "Doug McIntyre" wrote in message
    news:489fc169$0$90343$8046368a@newsreader.iphouse. net...

    > Hmm, some confusion here.
    >
    > First off, POSIX is a standard for unix systems for what headers,
    > libraries, APIs, etc. they have. pthreads is part of the POSIX
    > specs. Other unix varients have had their own threading model pre
    > pthreads standard, but then converged to it after it was part of the
    > spec so programs can be carried over easily.
    >
    > You can probably think of POSIX as the standard that binds unix type
    > systems together, not like linux has a native API, and a POSIX
    > API. They are one in the same, and each vendor works to making their
    > total system match what POSIX says is compliant.
    >
    > Just because Linux isn't 100% POSIX compliant, it doesn't mean that
    > its not even close, its just that they don't care to make it 100% for
    > whatever reason. Taking something that is 100% like Solaris, you'll
    > find the APIs, system calls, etc. are interoperable in 99.99% cases,
    > there's just a few odd things here and there.
    >
    > The system calls in libc on a unix type system map pretty much 100% to
    > what the kernel provides. Ie. you look at the source code for libc for
    > anything in section 2 of the man pages, you'll find a wrapper passing
    > the args and trapping to the kernel in whatever way that OS on that
    > architecture does it and returning the result code. Nothing more.
    >
    > Many varients of unix system have source code that is freely
    > available. Many of them also have excellent books written about their
    > inner workings (ie. 4BSD, Solaris, Darwin, Linux, or even old school, like
    > SysV for Bach, etc).


    I see. Someone told me linux was posix and unix wasn't.

    Bill



  5. Re: libc and *nix

    On Aug 11, 3:50 pm, "Bill Cunningham" wrote:
    > "Doug McIntyre" wrote in message
    > I see. Someone told me linux was posix and unix wasn't.


    Funny, in theory, it's just the opposite. The Unix
    specification (from the Open Group) is a superset of Posix;
    Linux isn't.

    Practically, Linux is fairly close to Posix, and most of the
    systems which sport the Unix trademark aren't really fully
    compliant by default, so the difference is more theoretical than
    practical, at least for the things that I'm concerned with.

    --
    James Kanze (GABI Software) email:james.kanze@gmail.com
    Conseils en informatique orient閑 objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place S閙ard, 78210 St.-Cyr-l'蒫ole, France, +33 (0)1 30 23 00 34

+ Reply to Thread