Subject: Linux-Development Digest #828
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:     Tue, 14 Jun 94 09:13:08 EDT

Linux-Development Digest #828, Volume #1         Tue, 14 Jun 94 09:13:08 EDT

Contents:
  Re: assembly language & Linux (ATTN!) (Alan Cox)
  Re: Linux and symmetrical multiprocessing (Alan Cox)
  Re: Why are there no streamss in Linux ? (Alan Cox)
  Re: parallel port modems (Alan Cox)
  Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?] (Martin Cracauer)
  mkimage error: mkimage: error running 'ld -o foob foob.o' (Tom Griffing)
  Xconfig doesn't work on XF86_SVGA (tf49665@delphi.com)
  Re: Filesystem semantics protecting meta data ... and users data (Dan Swartzendruber)
  Re: device driver woes (M.A.Cooper)
  Re: Linux game development (Was Re: Why [DOS, W (David Holland)
  Re: SMP supprot for Linux???? (Chas Hirst)
  Re: looking for some information on the clone() system call. (Michael David McCartney)
  PPP dial in problem (Naresh Sharma)
  Re: Symmetric Multiprocessing for Linux? (Marcin Benke)
  Re: dosemu: pre51_26.tgz does not work with 1.1.19  (Terry Carlin)
  Re: IDE PERF. PATCH SECURITY HOLE (Matthias Urlichs)

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: assembly language & Linux (ATTN!)
Date: Tue, 14 Jun 1994 09:56:21 GMT

In article <2tho41$1uo@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes:
>1) The kernel is *rife* with assembler in what is otherwise portable
>   code.
Its hard to avoid in many places. There isn't a c mapping for 'hardware
task switch' nor a clean C output for other things like checksumming and
a lot of the driver and fpu code which is also fundamentally non portable.

>
>2) Many Linux *applications* have assembly code. I guess the attitude
>   must be: "This is obviously never going to run on anything other
>   than an i386".

Very few - and those that do like xwt often need it for the tricky parts or
are driving hardware. svgalib is fundamentally non portable

Alan

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Linux and symmetrical multiprocessing
Date: Tue, 14 Jun 1994 10:02:34 GMT

In article <2ti2v7$o73@bronze.coil.com> bradb@bronze.coil.com (Brad Block) writes:
>Has anyone seen or heard anything that would hint that Linux will be able 
>to take advantage of SMP (symmetrical multiproccesing) in future kernel 
>releases?  Or, has anyone seen such a patch, driver, etc, for Linux or 
>another similair OS (BSD...)?  Or, would anyone like to try to help me 
>write a driver to take advantage of SMP motherboards and the new 
>specially adapted Pentiums that are easily multiprocessed?
>
Get me a 3+ CPU SMP motherboard and the low level programming docs for the
SMP and I have an entire computer society who'll happily do the rest if they
get to keep the board.

Alan



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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Why are there no streamss in Linux ?
Date: Tue, 14 Jun 1994 10:05:27 GMT

In article <CrCnE9.KLC@aston.ac.uk> evansmp@mb52114.aston.ac.uk (Mark Evans) writes:
>Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
>: This also needs changes to the sk_buff code so you can push data onto the
>: start of an sk_buff. I have code for this but not yet fully integrated,
>: and its done in such away that you don't end up with the performance hit that
>: BSD style mbufs cause - especially on a CPU with few registers.
>
>One possible way of doing this is VARIABLE buffer size linked lists.

Any kind of linked list is a bad performance hit. Doing scatter gather with
bus mastering DMA ethernet cards isn't normally viable. What the test code I 
have does is to use precomputed worst case headers on send. The send packet
wastes a small amount of space but is linear and fast to handle and the
memory cost because the packets clear quite quickly under a real(ish)
environment was about 8K - or less than the cost of implementing a linked
list buffer system.

Alan



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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: parallel port modems
Date: Tue, 14 Jun 1994 10:34:50 GMT

In article <2tiolq$32u@sundog.tiac.net> bill@bhhome.ci.net (Bill Heiser) writes:
>Are there any plans by anyone to develop a driver to allow a modem
>with parallel port connectivity (such as the Microcom DeskPorte FAST)
>to communicate via the parallel port in LINUX?
>
Try getting the docs for the parallel port protocol used from microcom. If they
say no then you dont have to worry about even considering their product.

Alan


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

Crossposted-To: comp.sys.sun.admin
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: Linux ext2fs vs. ufs vs. presto [was Re: Fast File System?]
Date: Mon, 13 Jun 94 09:18:30 GMT

torvalds@cc.Helsinki.FI (Linus Torvalds) writes:

>In article <1994Jun6.073403.4235@wavehh.hanse.de>,
>Martin Cracauer <cracauer@wavehh.hanse.de> wrote:
>>
>>SunOS-4.1.3 has a policy to have asynchronous writes for data, but
>>inodes and other superinformation is always written immedeatly. So, a
>>crash could only affect files that a written at that moment. I think
>>Solairs 2 does this, too. Does anybody know?
>>
>>There was a patch for SunOS 4.1.3 to make the BSD-Filesystem writing
>>inodes async, too. That speeds up writing a large number of little
>>files by a factor of 2 to 3. Of course, a crash could really hurt now
>>that superinformation could be damaged.
>>
>>I would relly like to know what the standard behaviour of Linux is. If
>>someone know, please tell us.

>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 agree and I drive my Sun's with everything asynchronous, too.

> - 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.. 

I think the difference is that with sync indoes only files that are
actually written when the crash happens can be affected. With
asynchronous metadata other files can be lost, too.

Of course, this only count for crashes that don't happen when the
kernel actually syncs the buffer cache, so I agree that it's not worth
the overheap to write anything async.
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin.Cracauer@wavehh.hanse.de, Fax. +49 40 5228536, German language accepted
 No guarantee for anything. Anyway, this posting is probably produced by one 
 of my cats stepping on the keys. No, I don't have an infinite number of cats.

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

From: tom@metronet.com (Tom Griffing)
Subject: mkimage error: mkimage: error running 'ld -o foob foob.o'
Date: Tue, 14 Jun 1994 04:27:41 GMT


The title says it.  I got the sources for "tools" and
according to the README's, compiled them and installed
them using "make install".  Then when using mkimage on
the examples with the tools code or anything else, I
get the following:

$ make      
gcc -B/usr/dll/jump/ -DANSI_ARROWS -DHAVE_STDLIB -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DUSE_TERMCAP -O    -c editline.c -o editline.o
gcc -B/usr/dll/jump/ -DANSI_ARROWS -DHAVE_STDLIB -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DUSE_TERMCAP -O    -c complete.c -o complete.o
gcc -B/usr/dll/jump/ -DANSI_ARROWS -DHAVE_STDLIB -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DUSE_TERMCAP -O    -c sysunix.c -o sysunix.o
gcc -B/usr/dll/jump/ -DANSI_ARROWS -DHAVE_STDLIB -DHAVE_TCGETATTR -DHIDE -DUSE_DIRENT -DSYS_UNIX -DUSE_TERMCAP -O    -c version.c -o version.o
ar r libedit.a editline.o complete.o sysunix.o version.o
Creating archive file `/home/tom/tools-2.12/example/libedit.a'
ranlib libedit.a
/usr/dll/bin/mkimage -l libedit -v 0.2 -a 0x80000000 -j 0x4000 -g 0x2000 -- editline.o complete.o sysunix.o version.o -ltermcap -lc `gcc --print` -lc
mkimage v2.12
Warning - non-absolute pathname specified for library
Reading configuration files from ./jump/
ld: failure reading string table size of foob.o
system: No such file or directory

/usr/dll/bin/mkimage: error running 'ld -o foob foob.o'

make: *** [libedit.so.0.2] Error 1
$

I looked in the sources and found the function "is_q_magic()" 
that makes several system calls to assemble and link the
file "foob".

I've worked with it for a while, but the solution is not
evident.

Can anyone help?


Thanks in advance.


--
 _____________________________________________________
| Thomas L. Griffing       |  Dallas Softworks, Inc.  |
| tom@metronet.com         |  (214) 352-1011          |
|__________________________|__________________________|

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

From: tf49665@delphi.com
Subject: Xconfig doesn't work on XF86_SVGA
Date: Tue, 14 Jun 94 01:14:34 -0500

   After many hours of tingering with different X servers, I finally got 
a stable X display using XF86_VGA16 under 640x480 mode with 25 Mhz.                 
Everthing is fine. But when I step it up to 800x600, I got a lime 
green root background instead of a gray background.                                         
   I tried using XF86_VGA256 server under 640x480,    
800x600, and 1024x768, but all three modes give me the same lime green 
root background, white window background, and lime green foreground. 
I can't see what I was typing under this color scheme. 
I tried XF86_Mono with the same green color.  The only mode
that worked is VGA16 (see below Xconfig and probe file).  Is it because         
the VGA16 uses a generic chipset (VT number 7) whereas the rest of the 
servers use the NCR77C22E driver?  

  My configuration is a NCR77C22E graphics chip, Viewsonics 6E 
monitor, mousesystem serial mouse, a 486/33 MHz with 8M running under 
Linux Slackware 1.0.

  My Xconfig file :

#-------------------------  Xconfig -------------------------------------
RGBPath         "/usr/X386/lib/X11/rgb"
FontPath "/usr/lib/X11/fonts/75dpi/"
FontPath "/usr/lib/X11/fonts/Speedo/"
FontPath "/usr/lib/X11/fonts/misc/"

Keyboard
  AutoRepeat 500 5

LeftAlt         Meta
RightAlt        ModeShift
ScrollLock      ModeLock

#Microsoft      "/dev/mouse"
MouseSystems   "/dev/ttyS0"
#
# The graphics drivers
#
vga16
  Virtual       800 600 
  ViewPort      0 0
  Modes         "640x480" "800x600"
#Grayscale
#Staticcolor
#Pseudocolor
#Truecolor
#Directcolor
Displaysize    1024 768
#Screenno       0
# Clocks  25.40  28.32  40.10  65.40  45.10  50.10   0.00  75.40
# Clocks  25 28 32 36 40 45 47 48 95 94 91 82 80 89 94 95
#
ModeDB
# clock  horzontal timing      vertical timing
 "640x480"   25     640  672  768  800    480  490  492  525
 "800x600"   40     800  840  968 1056    600  601  605  628
#"1024x768"  65.1  1024 1024 1168 1256    768  768  774  812
==================  end of Xconfig ================================

  I link VGA16 to X and startx. 

> cd /usr/X11/bin
> rm X
> ln -s XF86_VGA16 X
> startx

  My probe data :
========================  X =probeonly ================================
XFree86 Version 2.1 / X Window System
(protocol Version 11, revision 0, vendor release 5000)
Operating System: Linux 
Configured drivers:
  VGA16: server for 4-bit colour VGA (Patchlevel 0):
      et4000, tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga9000,
      generic
(using VT number 7)

Xconfig: /usr/X386/lib/X11/Xconfig
(**) stands for supplied, (--) stands for probed/default values
(**) Mouse: type: MouseSystems, device: /dev/ttyS0, baudrate: 1200
(**) FontPath set to "/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/Speedo/,/usr/lib/X11/fonts/misc/"
(--) VGA16: chipset:  generic
(--) VGA16: videoram: 256k (using 256k)
(--) VGA16: clocks:  26.00  28.32  40.10  65.20
(--) VGA16: Maximum allowed dot-clock: 90MHz
(**) VGA16: Mode "640x480": mode clock =  25.000, clock used =  26.000
(**) VGA16: Mode "800x600": mode clock =  40.000, clock used =  40.100
(**) VGA16: Virtual resolution set to 800x600
======================== End of X =probeonly =============================================


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

From: dswartz@pugsley.osf.org (Dan Swartzendruber)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 14 Jun 1994 11:33:00 GMT

In article <2tie0q$p5d@nwfocus.wa.com> ken@chinook.halcyon.com (Ken Pizzini) writes:
>In article <1994Jun12.225907.12160@rpp386>,
>John F. Haugh II <jfh@rpp386.cactus.org> wrote:
>>In article <DHOLLAND.94Jun10102522@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>>
>>The 6th Edition alloc() function wouldn't return the block number
>>until the block had been zero'd.  That is how strong the guarantee is.
>
>To *disk*?

No, why does that matter?  When you alloc a block from the free list,
before using it for any file, you zero it.  

-- 

#include <std_disclaimer.h>

Dan S.

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

From: M.A.Cooper@bradford.ac.uk (M.A.Cooper)
Subject: Re: device driver woes
Date: Tue, 14 Jun 1994 11:29:45 GMT

Rick Power C-3028 x-8844 (rickp@kelvin.physics.mun.ca) wrote:


: I am a grad student at memorial university of newfoundland - I just 
: finished convincing my supervisor that Linux is the way of the future
: for multi-processing :-). Previous to using Linux we had QNX 2.* on 
: the PC. We have a digital multimeter controller (labmaster) which had
: driving code written in C for QNX. I have been trying to port this code
: to linux. These are the things I know:

: to write/read to ports I can use the stuff defined in /usr/include/asm/io.h

: I know how to set up pipes between different processes ( popen/pclose )

: I also know of the messaging facilities provided by ( msgsnd/msgrcv ).

: the driving code consists of an initializing routine, a killing routine,
: and a controlling routine. Each of these processes have to communicate
: with each other and with the labmaster board on the ISA bus.  

: I would like to find out what is considered the proper way of writing and
: reading to ports ( I should have said on the ISA bus I suppose ).

: What is the proper way of setting up communication between processes that
: run concurrently?   
:  
: I would also like to know if this stuff is covered under any FAQs.

:                                               Thanks in advance
:                                                       Rick.

        Hi there,
                I don't know if it will help, but the kernel hackers guide on
sunsite.unc.edu under /pub/linux/docs/LDP has a large section on writing device
drivers for linux. Also check out the modutils package under /pib/linux/kernel.
This package allows you to load device drivers at run time, great for testing and
much quicker than recompiling the whole kernel.

        Hope this helps
                Martin 
-- 
***************************************************************
*                M.A.Cooper@bradford.ac.uk                    *
*       "Real programmers don't write documentation"          *
***************************************************************

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

Subject: Re: Linux game development (Was Re: Why [DOS, W
From: dholland@husc7.harvard.edu (David Holland)
Date: 14 Jun 94 00:57:24


behnke@tu-harburg.d400.de's message of 6 Jun 1994 13:39:49 GMT said:

 > |> 15% faster output code than Watcom was. All I want to see is a decent C++
 > |> compiler.
 > could you please state your dislikes with the g++ and tell me what single
 > other compiler beats all that?

Well, for starters - I've had g++ compile a function that had an
undeclared variable without so much as a whisper of a complaint. 

It only happened once, at least that I know of, and not with the
current version. Nonetheless this kind of behavior does not exactly
inspire confidence.

--
   - David A. Holland          | "The right to be heard does not automatically
     dholland@husc.harvard.edu |  include the right to be taken seriously."

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

From: chas@visionware.co.uk (Chas Hirst)
Subject: Re: SMP supprot for Linux????
Date: Tue, 14 Jun 1994 12:02:49 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <2t8f95$3hp@charm.magnus.acs.ohio-state.edu> ewalton@magnus.acs.ohio-state.edu (Elaine Walton) writes:
: >At present, there has been a lot of talk on the subject--not much done.
: >The problem stems from the sheer problem of a highly-coupled MPU (multi-
: >processor unit).  Some have suggested porting Linux over to the Transputer
: >processors to take advantage of it loosely coupled arrays.  For the most
: >part, a MPU would require restructuring the OS and the compilers (unless
: >you can manage the critical sectioning yourself--not an easy task;).

: With tightly coupled SMP its not so bad. Its very easy to right a 
: pessmistic solution that works and refine it later. The initial one many
: unixes used for MP was a processor that ran the kernel and syscalls on the
: other cpu trapped the process and rescheduled it as a software interrupt
: on the 'kernel' CPU. Thats _overly_ pessimistic but gives the idea. 

Addison-Wesley have just published a book that may well be of interest to
people interested in this topic.

Unix Systems for Modern Architectures
Symmetric Multiprocessing and Caching for Kernel Programers

Author Curt Schimmel
ISBN   0-201-63338-8
Hardback 432 pages

Tel no 1-800-822-6339

A table of contents and a preface are available on their FTP server aw.com
in the directory aw.prof.comp.series.

The book is not available in the UK yet but I have ordered it on the basis of
what I read in the preface.  No other book I have come across appears to cover
the topic of multiprocessor OS implementations as well at this one.

Regards

Chuck

Note:  I have no association with either the author or publisher apart from
being the owner of other Professional Computing Series books by A-W that I
have found very good.

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

From: mmccartn@cs.utexas.edu (Michael David McCartney)
Subject: Re: looking for some information on the clone() system call.
Date: 14 Jun 1994 01:01:18 -0500

In article <CrCAK7.Gp@wg.saar.de>, Patrick Schaaf <bof@wg.saar.de> wrote:
>
>I also noticed that my code destroyed %ebx, which is callee-saved...
>
>Below is a version of do_clone() that should work for all cases and
>switches. I tested it with 1.1.8 kernel and gcc 2.5.8, and it seems
>to work.
>

well, i thought you (and other developers) might be interested in what
i came up with last night.  basically, i ran with your first version
of the code to produce a clone() call that behaves like fork.

it just so happens that my function saves ebx so "technically" it's
not a problem but i would rather have better reassurance.  since i've
decided i don't need the clone() functionality in my project, i'll
leave it up to someone else to make improvements.  (i'm getting sleepy :-))

Below is a function called clone3() which takes the first 2 arguments to
do_clone() and the third argument tells it how many levels up the stack it
is to traverse when figuring out where the top of the stack is.  the
primary difference between clone3() and do_clone() is that it constructs
a stack for the clone process and returns on that stack so the user can
use the function just like fork().

Future work:
  1) i didn't know an exact way to find the top of the
     stack so it's dangerous to return more than the number of levels specified
     by the "num_frames_to_copy" argument.  if there is a nice way of finding
     out the address of the top of the stack, we could do away with the
     argument all together.
  2) There may be some register abuse in the assembly code (with respect to
     ebx, ecx, and edx.  I was more concerned with getting the stack frames
     set up properly.
  3) The code i added to copy and rethread the stack should really be done
     inside sys_fork() with the added knowledge of the actual size of the
     stack.  Thise works, but IMHO is a bit clumsy.

I'll include the entire clone3.c so you can see how it runs.  it's basically
the same as your previous example with do_clone().

Enjoy!
Mike McCartney

/* clone3.c - a test program using the clone syscall */

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

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

pid_t clone3(long *clone_esp,
             unsigned long clone_flags,
             int num_frames_to_copy)
{
  long *current_esp;
  long *current_ebp;
  long *current_top_ebp;
  long *clone_top_ebp;
  long *clone_ebp;
  size_t size;
  pid_t pid;
  int i;

  /* get the current esp and ebp */
  __asm__ (
           "movl %%esp, %0\n\t"
           "movl %%ebp, %1\n\t"
           : /* outputs */ /* %0 */ "=m" (current_esp),
                           /* %1 */ "=m" (current_ebp)
           : /* inputs */
  );

  /* traverse up stack frames (num_frames_to_copy) */
  current_top_ebp = current_ebp;
  for (i=0; i<num_frames_to_copy; i++) {
    current_top_ebp = (long*) *current_top_ebp;
  }

  /* calculate size of stack frame + argv, argc, main */
  size = (current_top_ebp - current_esp)+1 + 3;

  /* adjust clone's esp to point to bottom of stack frame */
  clone_esp -= size;

  /* calculate ebp for clone */
  clone_ebp = clone_esp + (current_ebp - current_esp);
  
  /* copy stack frames */
  memcpy(clone_esp, current_esp, size * sizeof(long));

  /* rethread clone's stack frames with ebp's which are in terms of the
   * addresses in the clone's stack
   */
  current_top_ebp = current_ebp;
  clone_top_ebp = clone_ebp;
  for (i=0; i<num_frames_to_copy; i++) {
    current_top_ebp = (long *) *current_top_ebp;
    *clone_top_ebp = (long) (clone_ebp + (current_top_ebp - current_ebp));
    clone_top_ebp = (long *) *clone_top_ebp;
  }

  /* make the clone syscall and store the return value in pid */
  __asm__ (
           /*
            * make the syscall
            *   eax = __NR_clone
            *   ebx = clone_esp
            *   ecx = clone_flags
            * returns:
            *   carry if error
            *   eax = pid of child (for parent)
            *       = 0            (for child)
            *       = error code   (if error)
            */
           "movl %3, %%edx\n\t"
           "movl %1, %%ebx\n\t"
           "movl %2, %%ecx\n\t"
           "movl $" DEREF_STR(__NR_clone) ", %%eax\n\t"
           "int $0x80\n\t"

           /*
            * error checking:
            *   if (carry) {
            *     errno = eax;
            *     eax = -1;
            *   }
            */
           "jnc 1f\n\t"
           "movl %%eax, _errno\n\t"
           "movl $-1, %%eax\n\t"
           "1:\n\t"

           /*
            * set ebp for clone:
            *   if (!eax) {        (in child)
            *     ebp = clone_ebp  (via edx)
            *   }
            */
           "testl %%eax, %%eax\n\t"
           "jne 3f\n\t"
           "movl %%edx, %%ebp\n\t"
           "3:\n\t"

           /*
            * save pid:            (note %0 is based on value of ebp)
            *   pid = eax;
            */
           "movl %%eax, %0\n\t"

           : /* outputs */ /* %0 */ "=m" (pid)
           : /* inputs */  /* %1 */ "m" (clone_esp),
                           /* %2 */ "m" (clone_flags),
                           /* %3 */ "m" (clone_ebp)
  );

  return(pid);
}

int clone_pid = -1;
int parent_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;
}

long clone_stack[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;

  parent_pid = getpid();
  printf("parent pid = %d\n", parent_pid);
  signal(SIGUSR1, sigusr1);
  pid = clone3(clone_stack+(sizeof(clone_stack)/sizeof(long))-1, SIGUSR1, 1);

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

  exit(EXIT_SUCCESS);
}

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

From: nash@dutllu4.gmd.de (Naresh Sharma)
Subject: PPP dial in problem
Reply-To: Naresh.Sharma@LR.TUDelft.NL
Date: Tue, 14 Jun 1994 11:31:51 GMT

Hi,
My dial-in connection is composed of two steps.

1. I dial the host, and authenticate myself, then the host disconnects.
2. The host dials me back, I reauthenticate myself, and login in. At this stage
   I can start a ppp, slip or a single tty session.

I can successfully start the pppd daemon, after loging  myself in by any comm
program. If I use chat or dip, the script flakes out on the connection as soon
as the connection is broken. I dont know enough about expect or chat to correct
this. I'd like to log-into my host without using umpteen different comm 
programs.

Can anyone provide a solution?

Naresh


--
_______________________________________________________________________________
Naresh Sharma [N.Sharma@LR.TUDelft.NL]  Snail-Herenpad 28          __|__
Faculty of Aerospace Engineering              2628 AG Delft \_______(_)_______/
T U Delft                     Optimists designed the aeroplane,   !  !  !  
Ph(Work) (+31)15-783992       pessimists designed the parachute!
Ph(Home) (+31)15-569636  Plan:Design Airplanes on Linux the best OS on Earth!
===============================================================================

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

From: benke@mimuw.edu.pl (Marcin Benke)
Subject: Re: Symmetric Multiprocessing for Linux?
Date: 14 Jun 1994 13:52:29 GMT
Reply-To: benke@mimuw.edu.pl


In article 68328@sdcc12.ucsd.edu, imcclogh@cs.ucsd.edu writes

> >Are there plans afoot to extend Linux to support symmetric
> >multi-processing (a la Mach?)
> 
> I sincerely doubt it, since as far as I know, Linux only runs on
> 386-architecutre

There is a series of WYSE machines which have true SMP and are 486 based.
I even once thought of launching a project to port Linux there, but WYSE was not interested. 

Regards,
        Marcin Benke


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

From: tgc@world.std.com (Terry Carlin)
Subject: Re: dosemu: pre51_26.tgz does not work with 1.1.19 
Date: Tue, 14 Jun 1994 12:29:43 GMT

Michael Will (michaelw@desaster.student.uni-tuebingen.de) wrote:
: Hello,

: someone mentioned that he had no problems with dosemu 0.51 and kernel
: version 1.1.19, so I jumped into the development-stuff and got me the
: newest version of the beast.

: Now that I compiled it without problems, I cannot run it at all. First
: it did not search the config-file in /etc/dosemu/config, and died with

: ERROR: par dead: cannot open configuration files!
: leavedos(0) called - shutting down
: ERROR: signal 11 received in leavedos()
---DUMP Deleted -------

Try copying /etc/dosemu/config to ~/.dosrc

This is not in the README.  I found it in the source code.  Just
grep'd for "cannot open configuration files" and found it.
Looks like it is made for multi-user now.  Each user can have their
own version of messy-dos, etc.  Neat Stuff, eh?

: Cheers, Michael Will
: -- 
:    In my experience, and there are some social psychology studies
: to support me, in real life, smart people make just about as many
:         really dumb decisions as dumb people, they just make them
:                                 for more sophisticated reasons...
-- 
Terry Carlin
tgc@world.std.com

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: IDE PERF. PATCH SECURITY HOLE
Date: 14 Jun 1994 08:41:38 +0200

In comp.os.linux.development, article <2tiaaf$e61@bmerha64.bnr.ca>,
  mlord@bnr.ca (Mark Lord) writes:
> In article <1994Jun12.203822.15133@unlv.edu> ftlofaro@unlv.edu writes:
> 
> >I have a Seagate 1239A (a total piece of crap), and a Samsung drive.
> >The Samsung works fine with the IDE patch, but the Seagate trashes
> >file systems badly if ANY IDE performance features are enabled. Now if
> >a user has even read-only access to any partition on /dev/hda (the
> >Seagate), they can trash all the filesystems there. NOT GOOD.
> 
> Eh?  This is something I'd like to know more about.  If the filesystems
> on the device are mounted read-only, then there's no way for hdparm to 
> trash them.  Even enabling the various performance enhancements should not
> be capable of trashing anything on the drive when mounted read-only.
> 
You misunderstood. If there's read-only access to _any_ partition, the user
can turn on the performance stuff, which will of course affect other
partitions on the same disk, presumably mounted R/W.

It might be a good idea to limit access to the performance switches
to /dev/hd[ab], and to return an error if somebody tries them with
/dev/hd[ab][1-9].

-- 
Fudd's Law of Insertion
   What goes in, must come back out.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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


** 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
******************************
