[ILUG] Re: System programming POSIX

[Brian Foster]

  | Date: Thu, 10 Jan 2008 23:13:25 +0000
  | From: "Pedro Jurado" <ped.jurado at gmail.com>
  | 
  | If you want to take a look to a *NIX kernel POSIX complaint, try Minix
  |  http://en.wikipedia.org/wiki/MINIX
  | it was created specifically to be use like a resource for students, I
  | studied this kernel in my degree in Computer Science in Seville to learn
  | concepts like threads, semaphores and other things.

 the Minux kernel and libraries, like the Linux
 and Unix kernels and libraries, _implements_ some
 or all of the POSIX APIs.  the kernels themselves
 are _not_ POSIX compliant; that simply makes no
 sense.

 to illustrate:  POSIX specifies the properties
 read(2) must have; i.e., the arguments, returns,
 essential functionality, interaction with fcntl(2),
 and so on.  POSIX describes a high-level machine;
 that is, a system, by listing the caller-visible
 properties each system call must have.  broadly,
 the read(2) man(1) page is POSIX's description of
 ‘read’; and for a version closer to what POSIX
 says, see The Open Group's Single Unix Specification
 (registration required):

    http://www.opengroup.org/onlinepubs/009695399/

 the libraries and (mostly) kernels provide an
 implementation of ‘read’.  to do this, they
 manage disc buffers, interrupts, concurrency,
 caches, DMA, &tc and --- this is key --- run
 on bare metal (or, nowadays, virtual metal).
 that is, the kernels run on a low-level machine;
 not on the high-level machine POSIX describes.
 ergo, the kernels themselves cannot possibly
 be POSIX complaint programs.  instead, they
 provide POSIX compliance; i.e., the kernels
 implement the POSIX high-level machine.

 it's usually said that (e.g.) “Linux is POSIX
 complaint”.  that's correct, when you read
 “Linux” as meaning what GNU/Linux provides.
 it's not a statement about the kernel's code
 itself; nor about kernel programming.

 sorry if I'm growing a molehill here, but the
 distinction between what something implements,
 and how that something is itself implemented,
 can be important.  and in the case of the OP,
 it wasn't clear whether s/he meant writing code
 to use the POSIX API (systems programming),
 or implementing that API (kernel programming).
 as a result, s/he got two completely different
 sets of answers:  one assuming the OP meant
 kernel programming, and the other assuming s/he
 meant systems programming.

cheers!
	-blf-

  | The only problem is the different design, microkernel in Minix vs.
  | monolithic in Linux but to start to learn and understand this concepts, I
  | think is enough.
  | 
  | 2008/1/9, Brian Foster <blf at utvinternet.ie>:
  | >   | Date: Wed, 9 Jan 2008 12:58:53 -0000 (UTC)
  | >   | Subject: Re: [ILUG] Re: System programming POSIX
  | >   |
  | >   | Thanks, this looks like a great place to start.
  | >
  | >        systems programming ≠ kernel (or driver) programming.
  | > kernel/driver programming ≠ writing POSIX compliant code.
  | > kernel/driver implements _part_ of POSIX.
  | > systems programming _uses_ API exported by kernel/driver.
-- 
“How many surrealists does it take to    |  Brian Foster
 change a lightbulb?  Three.  One calms  |  somewhere in south of France
 the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobile)!
 with brightly-coloured machine tools.”  |       http://www.stopesso.com