Subject: Linux-Development Digest #816
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Sat, 11 Jun 94 10:13:05 EDT

Linux-Development Digest #816, Volume #1         Sat, 11 Jun 94 10:13:05 EDT

Contents:
  Re: PANASONIC CDROM DRIVERS ???? (Eberhard Moenkeberg)
  Re: Filesystem semantics protecting meta data ... and users data (Orc)
  Re: New kernels and # of lines on screen (Rob Janssen)
  Re: Wanted : Mail (Rob Janssen)
  Re: looking for some information on the clone() system call. (Rob Janssen)
  Re: Linux game development (Was Re: Why [DOS, W (Brandon S. Allbery)
  Re: My problem? GCC problem? Linux problem? (Brandon S. Allbery)
  Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?] (Kevin Brown)
  A 1.1.19 (Hildo Biersma)
  Re: Frustrated with new kernels (Kevin Brown)

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

Date: Thu, 09 Jun 1994 23:36:52 +0200
From: Eberhard_Moenkeberg@p27.rollo.central.de (Eberhard Moenkeberg)
Subject: Re: PANASONIC CDROM DRIVERS ????


Hello CASTEELS JAN and all others,

on 08.06.94 CASTEELS JAN wrote to All in USENET.COMP.OS.LINUX.DEVELOPMENT:

CJ> Is there somebody who has drivers for a double-speed CD-ROM drive on
CJ> a PCI motherboard

A CDROM drive on a motherboard? Never seen or heard about.

Greetings ... Eberhard


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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: orc@pell.com (Orc)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Sat, 11 Jun 1994 06:42:44 GMT

In article <idletimeCr7Ayr.L4K@netcom.com>,
Totally Lost <idletime@netcom.com> wrote:
>After a wild strike three Burkhard Neidecker-Lutz is OUT!
>
>To recap this exciting drama ... [verbage elided]


   Please take it to email.

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: New kernels and # of lines on screen
Reply-To: pe1chl@rabo.nl
Date: Fri, 10 Jun 1994 15:58:28 GMT

In <2t931q$d8p@quartz.ucs.ualberta.ca> kurtk@ee.ualberta.ca (Kurt Klingbeil) writes:

>Both bash and csh come up with lines and cols set according to
>the video mode of the console, even if one is coming in on ttySn.

>For bash, one can just export LINES=24; export COLS=80.
>Actually, I'm just working on hacking up the /etc/profile to
>incorporate ttySn-dependancy to override the "auto-smart-ness".

>For tcsh, however, things aren't so easy since term type seems to
>be defined even before /etc/csh.login is hit.  The lines/cols
>are implicitly set to the console's video mode, but if one
>attempts to explicitly setenv LINES/COLS, the "autotracking"
>which is related to SIGWINCH (which probably wasn't implemented in 1.0.0 ?)
>stomps them back into the wrong values.

>Then there's "vim" which appears to ignore both TERMCAP and LINES
>and config itself according to the console mode even when run on ttySn.

The only thing the kernel affects is the 'window size' that is indeed
related to SIGWINCH.  However, it has been present for a long time, and
I doubt it has recently changed.
On my 1.1.18 system the size (see stty -a) is set to "rows 0; columns 0"
on a serial line.  Checkout what it says on your system.

The behaviour of any program depends on the code and/or libraries it uses
to determine screen size.  It can look solely at the terminal type (and
hence get the info from /etc/termcap or terminfo), it can look in the
window size structure, and it can check environment variables like
LINES.  This is the "inconsistent mess" that people like to refer to
when discussing Unix :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Wanted : Mail
Reply-To: pe1chl@rabo.nl
Date: Fri, 10 Jun 1994 15:59:59 GMT

In <Cr6BHq.Dw5@eng_ser1.ie.cuhk.hk> yksiu2@ie.cuhk.hk (siu yan kam) writes:

>I am looking for the source code of the mailing system on Linux.
>Please give me some suggestions on how I can find it.

There are so many components and alternatives in the mailing system that
you really need to supply more information.
However, source code to almost everything can be found on sunsite.unc.edu
and tsx-11.mit.edu

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: looking for some information on the clone() system call.
Reply-To: pe1chl@rabo.nl
Date: Fri, 10 Jun 1994 19:25:42 GMT

In <2t9s2b$hll@levelland.cs.utexas.edu> danielsi@cs.utexas.edu (Daniel Aaron Supernaw-Issen) writes:


>Hey all.  I'm looking for some information on the clone system call.  I 
>understand that it is undocumented, all i need is the paramter list, I'm 
>more than happy to experiement from there.  Better yet, could someone 
>explain how to find out this information from looking at kernel source?
>I grep through all the includes for clone, came up with the syscall number 
>(120) but thats it.  Basically, I hope to implement a kernel level thread
>package.

~Newsgroups: comp.os.linux.development
~Path: pe1chl!rnzll3!sun4nl!EU.net!howland.reston.ans.net!xlink.net!sbusol.rz.uni-sb.de!coli.uni-sb.de!news.coli.uni-sb.de!uhf.saar.de!midget.saar.de!wg.saar.de!bof
~From: bof@wg.saar.de (Patrick Schaaf)
~Subject: Re: Looking for Docs on "clone" system call ?
~References: <1994Jan3.004554.7942@aio.jsc.nasa.gov>
~Organization: Yoyodyne Posting Systems, Bellona
~Date: Mon, 3 Jan 1994 16:09:50 GMT
~Message-ID: <CJ2A8E.p4C@wg.saar.de>
~Lines: 230

sohail@trixie (Sohail M. Parekh) asks:
>I was recently told about the "clone" system call but I have been unable to
>find any documentation on it. Could someone point me in the right direction.

I have no idea whether this is in the kernel hackers guide somewhere; if
not, and the following makes any sense, feel free to include it after
adjusting my english appropriately.

Since the question comes up from time to time, I decided to do a bit
kernel reading.  The following might be a useful tour on the matter.
This is from reading the source only, so I might be totally wrong...

The kernel I base this on is pl14i, but I don't think the area was busy
recently.

Any comments? Linus?

Enjoy
  Patrick


clone() - a slightly bent fork()
====================================

clone() has its own entry in the syscall tables, but runs sys_fork().
This is found in kernel/fork.c

The syscall expects the following parameters:
  %eax          __NR_clone      (the syscall number)
  %ebx          stack pointer   (where the child stack should be)
  %ecx          clone flags

OR some of the following constants together to build the flags argument:

  COPYVM
    page tables will be copied to the new process, separating the address
    spaces of parent and child.  This is forced for apparent reasons when
    the stack pointer for the child is the same as for the parent, and it is
    the default for the real fork().

    If COPYVM is not set (this would be normal for a thread implementation),
    mm/memory.c:clone_page_tables() sets up sharing the page directory
    between parent and child.  This should mean that any changes in memory
    mapping in the child or parent will affect the other process, i.e. mmap()
    might work.  I wonder who uses those vm_area thingies.  It looks like
    ->stk_vma is not ok for the clone (a copy of the parents area).  The clone
    has to ensure there is memory at its own stack pointer, probably
    using mmap() for anonymous memory, but it will still get the self-growing
    stack behaviour in the original stk_vma.  I don't want to think about
    what this means for consistency.  When allocating the stack, remember
    those thingies grow towards lower addresses.

    On process exit, if the page directory is still shared with someone,
    the reference is decremented (mm/memory.c:free_page_tables()); the
    tables are left intact until the last decrement.

    It even looks like you can have any of your clones or the parent
    use exec(); that uses mm/memory.c:clear_page_tables(), which does
    the right thing to the page directory.

  COPYFD
    usually, a fork() increments the reference count of the 'struct file'
    for all open file descriptors, parent and child thus share file offset
    and flags.  When COPYFD is given, the child receives duplicates of
    the 'struct file's sharing only the inode (as if they had been
    open()ed independently).

COPYVM and COPYFD come from <linux/sched.h>

You additionally OR a signal number into the flags, which will be sent to the
parent on child exit instead of the usual SIGCHLD.
If I have the parent die before the clones are dead, this might be a way for
normal user processes to confuse the heck out of init.  Whoops, this is
handled in kernel/exit.c:notify_parent().  It is reassuring to find all
nasty things you can think of already handled properly :-)

Besides the sharing mentioned, the clones are independent processes.
When one of them opens a file, nobody else sees it.  When one of them closes
a file, the others keep it open.  Maybe you can pass newly opened files via
Unix domain sockets or SysV message queues - is this implemented?

Also not shared is the SysV IPC stuff, and a lot of Posix process
attributes (pids, pgrps, sessions, controlling ttys, whatever).
This especially means that all clones are scheduled indepentanty,
can run with varying persona, and block without interference.


Related to clones is kernel/exit.c:sys_wait4().  You can OR __WCLONE
into the options parameter to modify wait4() behaviour as follows:

  exit signal SIGCHLD for the child (normal fork() case)
    __WCLONE given:
      does not wait on that child
    __WCLONE not given:
      waits
  exit signal not SIGCHLD (child was created by clone())
    __WCLONE given:
      waits
    __WCLONE not given:
      does not wait on that child

Looks like if you want to manage clone() termination, you should choose
an exit signal other than SIGCHLD, and use wait4(..,..,__WCLONE,..) to
wait for the clone()s only, and wait4(..,..,0,..) to wait for normally
fork()ed processes only.

__WCLONE comes from <linux/wait.h>


clone()'d processes are rather heavyweight for threads, and might not be
appropriate for the threading you want to do.  I do not want to say they
are useless, though; maybe a two-level approach to threading (I hear
that Sun does it) works for all cases (implement user-level threading
within each clone).


Whoever managed to follow me up to here should be rewarded; here is a
an working example for using clone():

#include <errno.h>
#include <stdio.h>
#include <signal.h>
#include <linux/sched.h>
#include <linux/wait.h>
#include <linux/unistd.h>

/* NOTE: the clone() starts up on a new stack. Thus, we cannot return
 * from this function in the clone (we would have to copy stack frames
 * for main and the call). Instead, we call the given function, and
 * call _exit() with whatever it returns.
 */

#define STR(x) #x
#define DEREF_STR(x) STR(x)

int do_clone(unsigned long esp, unsigned long flags, int (*func)(void))
{
  __asm__ (
           /* make the syscall */
           "movl %2, %%edx\n\t"
           "movl %0, %%ebx\n\t"
           "movl %1, %%ecx\n\t"
           "movl $" DEREF_STR(__NR_clone) ", %%eax\n\t"
           "int $0x80\n\t"
           /* error? */
           "jnc 1f\n\t"
           "movl %%eax, _errno\n\t"
           "movl $-1, %%eax\n\t"
           "jmp 3f\n\t"
           "1:\n\t"
           "testl %%eax, %%eax\n\t"
           "jne 3f\n\t"
           /* the clone */
           "call *%%edx\n\t"
           "pushl %%eax\n\t"
           "call _exit\n\t"
           /* not reached */
           "1:\n\t"
           "jmp 1b\n\t"
           /* the parent */
           "3:\n\t"
           "ret\n\t"
           : /* outputs */
           : /* inputs */  /* %0 */ "m" (esp),
                           /* %1 */ "m" (flags),
                           /* %2 */ "a" (func)
  );
  errno = EINVAL;
  return -1;
}

int clone_pid = -1;
int do_terminate = 0;

/* we use sigusr1() for child termination signalling */
void sigusr1(int sig)
{ unsigned long status;
  int pid;

  printf("parent: got SIGUSR1, waiting for children... clone_pid=%d\n",
         clone_pid);
  pid = wait4(clone_pid, &status, __WCLONE, (struct rusage *)0);
  if (pid < 0) {
    perror("wait4");
    return;
  }
  printf("parent: wait4 returned %d\n", pid);
  if (clone_pid == pid)
    do_terminate = 1;
  signal(SIGUSR1, sigusr1);
  return;
}

char clone_stack[4*4096];

int clone_function(void)
{
  clone_pid = getpid();
  fprintf(stderr, "clone running, pid = %d\n", clone_pid);
  sleep(5);
  fprintf(stderr, "clone terminating\n");
  return 0;
}

int main(int argc, char **argv)
{ int pid;

  printf("parent pid = %d\n", getpid());

  signal(SIGUSR1, sigusr1);

  pid = do_clone((unsigned long)(clone_stack+sizeof(clone_stack)-1),
                 SIGUSR1,
                 clone_function);

  if (pid < 0)
    perror("clone");
  else if (pid == 0)
    fprintf(stderr, "funny, clone() returned pid=0 in parent\n");
  else {
    printf("parent: clone running, pid = %d. waiting for termination.\n", pid);
    while (!do_terminate) {
      printf("parent: child did not signal termination, yet.\n");
      sleep(1);
    }
    printf("parent: looks like our kid is gone. BTW, clone_pid = %d\n", clone_pid);
  }
  return 0;
}


-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: Sat, 11 Jun 1994 03:50:48 GMT

In article <2sv8v5$oan@rztsun.tu-harburg.de>, behnke@tu-harburg.d400.de (Lutz Behnke HiWi) says:
+---------------
| could you please state your dislikes with the g++ and tell me what single
| other compiler beats all that?
+------------->8

g++ 2.5.x is broken, ask the OI folks...  Supposedly the current development
snapshot works properly; let us hope they release it before they break it
again...  For that matter, bugs in g++ 2.4.x aborted an attempt to make a C++
Linux kernel some time ago.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: My problem? GCC problem? Linux problem?
Date: Sat, 11 Jun 1994 04:01:32 GMT

In article <jameslCr7AnH.IFy@netcom.com>, jamesl@netcom.com (James Logajan) says:
+---------------
| For what it's worth, this code also runs successfully on SCO ODT 3.2.
| Did a quick scan on the cc man pages; doesn't seem to be any way of
| telling it to put string constants in read-only memory. Hmmm...
+------------->8

SCO's cc is an obsolete Microsoft C port.  rcc is even worse; it's a
derivative of the ancient AT&T Portable C Compiler, and predates all of this
stuff.  (Even though rcc is a newer version of pcc, it's still basically the
same simplistic K&R C compiler.)

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

Crossposted-To: comp.sys.sun.admin
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?]
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Thu, 9 Jun 1994 22:06:34 GMT

In article <2t7bpv$ork@klaava.helsinki.fi>,
Linus Torvalds <torvalds@cc.Helsinki.FI> wrote:
>The standard behaviour for linux is to write everything asynchronously,
>as others have already pointed out. I'd just like to put in my two cents
>for why this is done:
>
> - synchronous writes are slow.  You'll lose *lots* of performance.  I
>   tend to think that you can trust the hardware, and just ignore the
>   minor problems you can get with asynchronous writes - the benefits
>   far outweigh the problems IMNSHO. 

I totally agree with this.  Synchronous writes aren't the answer.

> - doing synchronous writes on meta-data is broken: you'd really need to
>   do synchrnonous writes on data too to be safe.  BSD does metadata
>   synhronously to give you a sense of security and ignores the actual
>   file data -- they too did a trade-off in efficiency and security. 
>   They just did a better job at trying to fool people into thinking
>   it's a good idea.. 
>
>Remember: fsck can clean up the filesystem metadata if you crashed (and
>metadata is the only thing the FFS tries to do synchronously), so why
>pay the overhead of doing the same thing at runtime?

It *can* clean up the filesystem metadata, but the question is
whether or not it will do so correctly.

For instance, with 0.99.13 and the cluster patches, I experienced
several crashes (unrelated to the cluster patches.  My system
consistently, but randomly, hung when I accessed my magneto-optical
drive with multiple processes (single processes didn't seem to
cause problems) or when I accessed it while the serial port was
receiving incoming characters (e.g., when attempting to download
to the MO drive).

After fsck ran, a number of files, some of them seemingly unrelated
to what was going on, had extremely wrong metadata.  For instance,
I had symbolic links in /usr/bin which had turned into files with
rather amazing sizes.  :-)  The filesystem was consistent according
to fsck, but ls would consistently crash trying to do a long listing
of /usr/bin.  It should be noted that the symbolic links in /usr/bin
had been there a *long* time, and had not been updated.

The fact that I was running the cluster patches is important.
Before, the entire filesystem would by sync()ed every 30 seconds
or so (I actually had it set for something like 5 minutes to get
better performance under the conditions my system runs).  Between
these periods, the filesystem on disk was reasonably likely to be
in a consistent state.  But the cluster patches changed things such
that the system is *continuously* writing to the filesystem, if
only because there are periodic processes which access (for read)
files on the filesystem, causing the filesystem to update the access
times of all accessed files.  Indeed, I can see the hard drive
being accessed every 5 seconds, the default update period for
bdflush().  This significantly increases the probability that
filesystem damage will occur if a crash happens.

The hangs *might* be a device driver problem.  It probably is,
actually.  But I don't know this to be the case.

Not that it matters that much.  If system operation is interrupted,
FOR WHATEVER REASON, there is a good chance that the filesystems
will be left in an inconsistent state, given the continuous update
nature of bdflush.

I'm running 1.0.9 with the cluster patches now, and haven't
experienced any problems, but I haven't taken any chances.  I
haven't tried beating on my MO drive very hard.  I will soon, but
under very tightly controlled conditions (e.g., using a root
filesystem that I can safely "throw away").

> Yes, you can get
>such corruption that fsck gives up in horror but if you had that bad a
>crash, you'd probably have been screwed anyway even with synchronous
>write.  How many of you have gotten that kind of filesystem corruption
>under linux without it being a device driver of hardware problem (which
>a filesystem couldn't fix anyway)?

The SCSI device driver has been rock-solid reliable in writing data
correctly to my fixed disks, and when it *does* write data to my
MO drive it does so correctly.  It's just that it likes to lock up
if I beat on my MO drive too much, especially if there's other
activity (such as serial port activity) going on.

>Final question: what's the use of "safe filesystems" if the hardware
>itself isn't safe? Who do you think you're kidding? If the harddisk
>crashes on you (or even gets just one bad sector) you won't be safe even
>if you write *everything* synchronously.  So why take the performance
>hit? (yes, I know about RAID etc, and I don't care.  I don't have that
>kind of hardware, and I don't think most people here wanting a "safe"
>filesystem do either). 

It's a question of probabilities, and of minimizing damage.  If
the power suddenly fails, that will surely cause as definitive a
crash as would bad hardware.  But a power failure is much more
likely to occur.  When it does, you would *prefer* that the damage
to the filesystem be minimized, as long as you don't take a
significant performance hit to get it.

>               Linus
>
>PS.  As if you didn't notice, you pushed a button.  I think sync writes
>are stupid, and find some of the FFS proponents attitudes irritating. 
>Logbased filesystems at least make sense, even though I don't
>particularly want to run them myself. 

It seems to me that *when* you write data isn't nearly as important
as *what order*.  An individual cluster of writes takes a relatively
short amount of time.

So it seems to me that you should be able to prioritize the data
that you have to write to the disk in such a way that, between
writes, the filesystem will be consistent even if not all writes
have been performed.  Have I just described the premise behind a
log-structured filesystem?

I do not know how much of a performance penalty you'd take.  I
don't know that it would be truly significant, particularly in
low-memory situations when you're writing data in a semi-random
(with respect to the location of data on disk) fashion anyway.


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

From: biersma@dutiws.twi.tudelft.nl (Hildo Biersma)
Subject: A 1.1.19
Date: Sat, 11 Jun 1994 12:58:08 GMT

Hi all,
A new problem in 1.1.19 which might be a bug, or a user error:
- I use kermit to call a terminal server
- When the connection is established, i start ppp remotely,
  then start pppd locally from kermit using a shell script that
  runs pppd.  Note: I don't quit kermit first, I use a shell escape.
- This used to work just fine (up to 1.1.18).  However, in 1.1.19, kermit seems
  to be disconnected from my tty (a virtual console).  I return to my shell;
  however, kermit is still active, and when I kill pppd (after I'm done
  modeming), kermit will act up strangely (especially if I loggout out
  on the tty, or started another program).

Now I know I should 'dip' instead of kermit, but is the new tty behavior correct
or a bug?

Hildo Biersma
-- 
Hildo Biersma

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Frustrated with new kernels
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Thu, 9 Jun 1994 22:15:11 GMT

In article <Cr3C2M.8rz@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>In <ATOENNE.94Jun8123536@mpii02013.mpi-sb.mpg.de> atoenne@mpi-sb.mpg.de (Andreas Toenne) writes:
>
>>At the heart of my problem lies the *EMPTY* Changes list for Linux >= 1.0.0
>>I cannot trace all hints in this newgroups since I am no developer and
>>I do not understand the details of the discussed bits and patches.
>>My plea is: can someone list the (for a user) interesting changes and
>>ongoing developments such that we understand when it is time to try
>>a new kernel, even when it is not officially finished (ie. 1.1.x). 
>
>But Russ Nelson has posted such lists for some time!
>
>Are they archived somewhere?  Would there be some way to get them included
>in the README, e.g. at the release after the one it refers to?
>It seems that many people want to have them, yet don't find them in the
>news...

It seems to me that, wherever patches are located, there should be
a file, perhaps called CHANGELOG, to which the change list is
appended whenever a new patch comes out.  When you grab a new patch,
you can grab the changelog.

Or keep the individual change lists in the same place as the patches
are located.  It would result in the same thing, and would be of
benefit to everyone getting patches.

Whenever a new kernel tar file is released, the CHANGELOG file
(consisting of all the change lists) should be included with it.

Not a hard thing to do, but might require a little more bookkeeping.
Perhaps Linus is busy enough as it is.  :-)

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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
