Return-Path: owner-linux-activists@Niksula.hut.fi
Return-Path: <owner-linux-activists@Niksula.hut.fi>
Received: from joker.cs.hut.fi by hydra.Helsinki.FI (4.1/SMI-4.1/39)
	id AA09600; Mon, 3 May 93 02:06:25 +0300
Received: from joker.cs.hut.fi by niksula.hut.fi id <62124-8>; Mon, 3 May 1993 02:05:39 +0300
From: "Linux Activists" <linux-activists@Niksula.hut.fi>
To: "Linux-Activists" <linux-activists@Niksula.hut.fi>
Reply-To: "Linux-Activists" <linux-activists@Niksula.hut.fi>
X-Note1: Remember to put 'X-Mn-Key: DOC' to your mail body or header
Subject: Linux-Activists - DOC Channel digest. 93-4-2-20:39
X-Mn-Key: DOC
Sender: owner-linux-activists@Niksula.hut.fi
Message-Id: <93May3.020539eet_dst.62124-8@niksula.hut.fi>
Date: Mon, 3 May 1993 02:05:37 +0300
Status: RO
X-Status: 


Topics:
	 LPG topics
	 LPG contents & other pre-existing books
	 glibc manpages already there? (Was: LPG possible organization)


----------------------------------------------------------------------

From: johnsonm@stolaf.edu (Michael K Johnson)
Subject: LPG topics
Date: Sun, 2 May 1993 23:24:10 +0300


   I see that we have to define what does and does not belong in the LPG. The
   name suggests it would be a guide to programming under the Linux operating
   system. Its goal should be more of a tutorial rather than a reference.

I wouldn't say that.  It is just not supposed to be a complete
reference to every possible thing you need to know to program Linux.
I think that some tutorial material will be appropriate (converting
sgtty to termios) but that tutorial material should have reference
value.

   mkj says he wants to cover the API, but there seems to be no agreement as
   to what constitutes the API. I guess his definition of it as the functions
   provided WITH Linux seems to be adequate.

Functionality provided with "standard" packages for Linux would be
closer.  That means that we document functionality that people use
when programming that is either not well documented or not
conveniently documented.

   The first step should be to collect a series of topics we would like to
   have covered in the LPG.

That's exactly what I have been saying since my first tentative post...

   I'll fire the first shot and then duck :-)

Well, it's not the *first* shot, but it is a very nice one.  I am
collecting ideas, and this will go in my collection.  I'll try to
organize the ideas after I get more, and the present my collection to
the list for comment.

   2) unreliable singals vs. reliable signals including the use of
	   _BSD_SIGNAL.

This is a very good example, as it is not really non-posix, so much as
Linux-specific, and useful to know when porting.

   3) using the /proc file system.

Another good example.  I will probably move or copy part of the /proc
chapter from the KHG to the LPG, as part of it involves the user-level
presentation.  The /proc API, you might say.

   7) sockets both AF_UNIX and AF_INET (client-server in general).

Is there anything in linux that is non-standard, assuming the new
networking layer?

   11) rpc.

Isn't this standard?  Ire there any differences that need to be noted?

   12) ipc.

Yep.  Linux IPC has a bit of extra functionality.

   14) psuedo-terminals.

Anything non-standard about ours?  I suppose the naming scheme should
be documented somewhere, and an explanation of how to go about opening
them...  (Of course, editorially, I will say that I would prefer SysV
clone devices... ;-)

   17) iostream-based stdio.

Absolutely, including all the members of the FILE structure.  It is
not good to muck with it, but when you are trying to port a program
that does, it's nice to know what to do.  The LPG will not be purist,
though it will make recommendations.

   19) gdbm.

The FSF should be documenting this one.

michaelkjohnson



------------------------------

From: johnsonm@stolaf.edu (Michael K Johnson)
Subject: LPG contents & other pre-existing books
Date: Sun, 2 May 1993 23:39:44 +0300


   I have been hearing a lot on this list along the lines of "Here's someone
   else's outline--we could use this as a potential LPG structure...", etc.

   I think this is the wrong approach entirely.
   I fully Support Michael K Johnson's approach here...

   These other books & tables of contents should be a guide
   as to what NOT to include.

I'd like to point out that I have been seeing two extremes here,
neither of which is exactly what I am trying to do.

I am not re-writing available books, nor am I stealing organization
from them.  I do not intend to compete.

On the other hand, I am not afraid of duplicating information where it
is reasonable to write a real book.  I don't intend to make the LPG a
set of diffs to 10 other books, that require all of them to use it.
The LPG should stand on its own, for what it says, and for what it
doesn't say, it should make reference.  However, to require anyone who
wanted to get real use out of the LPG to buy both Lewine's book and
Stevens book is not my goal, as much as I respect both authors and
books.  Well, as much as I respect Stevens, and have been told I will
respect Lewine when I scratch up the money to furnish my bookshelf
with his guide.

"Write a complete book, but don't compete."

I hope this clarifies my intentions somewhat for everyone.

michaelkjohnson



------------------------------

From: johnsonm@stolaf.edu (Michael K Johnson)
Subject: glibc manpages already there? (Was: LPG possible organization)
Date: Sun, 2 May 1993 23:45:24 +0300


   From: Thomas Koenig <ig25@rz.uni-karlsruhe.de>
   johnsonm@stolaf.edu (Michael K Johnson) writes:
   >I don't think we need to
   >document glibc --- the FSF is doing that just fine --- but we should
   >document linux-specific extensions.

   Where can this documentation be found?  I think this is quite interesting
   for the manpage project; it would really cut down the time we'd have to
   spend on section 3 manpages.

The FSF is writing info pages for their glibc.  Ours is admittedly not
the same, but it is close.  I don't know how much progress has been
made, nor when they will be released, but it is a project that they
have.

Unfortunately, that's all I know.

michaelkjohnson








------------------------------

End of DOC Digest
*****************
-------
