Subject: Linux-Development Digest #852
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:     Thu, 23 Jun 94 16:13:10 EDT

Linux-Development Digest #852, Volume #1         Thu, 23 Jun 94 16:13:10 EDT

Contents:
  Re: Porting libpthreads to Linux? (John Romein)
  Need help with gcc/ncurses under 99pl15 (Scott Wegener)
  Wine-940620 (NJ. Bruton)
  Re: 1.1.20 - Mosaic 2.4 broken? (James Smith)
  Re: Disk-compression for Linux (TJ Dulka)
  Context of signal handler call (Markus Daetwyler)
  Re: Disk-compression for (Mark van Hoeij)
  Re: Context of signal handler call (Steven Buytaert)
  ghostcsript bj600 driver (Stuart Cornell)
  Wine-940620 (NJ. Bruton)
  Re: Wine-940620 (Wei-Jou Chen)
  Re: Disk-compression for Linux (Bret Patterson)
  Re: Disk-compression for (John Will)
  Re: Disk-compression for Linux (Felix Schmidt)
  SIGCHLD not sent or ignored? (Lee J. Silverman)
  Re: Major device number clash (iCS) (Eric Youngdale)
  Re: PGP 2.6 for Linux (Techy Admin)
  Re: Deadlock with unix domain sockets (Phil Howard)

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

Crossposted-To: comp.os.linux.kernel
From: john@cs.vu.nl (John Romein)
Subject: Re: Porting libpthreads to Linux?
Date: Thu, 23 Jun 1994 11:03:16 GMT

arrouye@petole.imag.fr (Yves Arrouye) writes:
: Hello,
: 
: I would like to port Mueller et al.'s libpthreads (ftp.cs.fsu.edu:/pub/PART/)
: to Linux, but I am having a lot of problems because I really do not know where
: to find the information I need.
:       Did someone do the port? If so, where can I find it? If not, does
: someone volonteer to help me? The informations I need are relative to the
: stack frames management, the jump buffer structure (although I think I've  
: found what I need in jmp_buf.h) and the structure of informations saved when
: a user handler as set by sigaction is called. If soemeone can also implement  
: context switches in assembler, (s)he is welcome!
:       The goal of the porting is twofold: first, having a  
: library-implementation of Pthreads under Linux; second, use it to have tasks  
: in GNAT's Ada9x runtime.
: 
: Thanks in advance for any help.
: Yves.
: 
: --
: Advocates for the C++ school claim that a well designed           Yves Arrouye
:     program does not need the extra flexibility (a lie),  Yves.Arrouye@imag.fr
: while advocates for the Objective-C school claim that         (33) 76 57 48 64
:     the errors are no problem in practice (another lie).             NeXT Mail

There is a pthread implementation for linux available from sipb.mit.edu
Due to the limited amount of anonymous ftp connections, it is hard to login.

John Romein

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

From: wegster@connected.com (Scott Wegener)
Subject: Need help with gcc/ncurses under 99pl15
Date: 22 Jun 1994 14:33:06 -0700


        I have had some problems running gcc 2.5.8 and the ncurses library
with the following setup:
OS: Linux v99pl15
System: Intel 486sx/25
The gcc/g++ package was part of the Linux distribution I downloaded, which 
was an SLS release. I have looked through any man pages I thought useful,
the gcc.help and g++.help and *.bugs newsgroups, and any FAQ I could
get my hands on. Unfortunately, I STILL can not get any of the ncurses
functions to compile in my programs. The following is a test program
I have been using to see if any command line options had helped.
I have commented out EVERY ncurses.h function and still get the 
undefined errors for _stdscr. I have verified that the "curses.h"
header is a symbolic link to ncurses.h and tried using an absolute 
path and believe that the correct (ncurses rather than curses) file
is being used. Anyway, here is the code.....

/**********************************************************************
** test.c: let's make sure cc/gcc are working ok.               *******
**********************************************************************/

#include<stdio.h>
#include<curses.h>
#include<termio.h>

main()
{
  initscr();
  clear();
  move(1,1);
  puts("This is a test....");getchar();
  return;
}
 
According to the ncurses man pages, need to include the -lncurses
switch, but this made no difference in results at all..
ok, so command line is: cc -lncurses test.c
resulting in:
/tmp/cca003041.o:undefined symbol _initscr referenced from text segment
/tmp/cca003041.o:undefined symbol _stdscr referenced from text segment
/tmp/cca003041.o:undefined symbol _wclear referenced from text segment
/tmp/cca003041.o:undefined symbol _stdscr referenced from text segment
/tmp/cca003041.o:undefined symbol _wmove referenced from text segment

As there are no 'complete' references for gcc, or at least any I have 
been able to find :(, I am  not sure what the /tmp files are but am
assuming they are intermediate object files from the #includes and 
main(). Looking through the older curses man pages, it had said to 
#include termio.h, so I did so, although the gcc/ncurses FAQs/man pages
had not made any similar statement other than the -lncurses option be
used.
I have been ripping my hair out with this problem and have exhausted
any avenues I know of to get an answer to this problem. Being primarily
a DOS programmer, I have been trying to make the transition to Unix
programming, but as you can see-not too well...
If you have any ideas or suggestions I would greatly appreciate them.

Scott Wegener
wegster@hebron.connected.com


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

From: ccnjb@sun.cse.bris.ac.uk (NJ. Bruton)
Subject: Wine-940620
Date: Thu, 23 Jun 1994 11:28:55 GMT

I've just built wine940620 but nothing now works (including sol.exe)
Have I made a mistake or has this release broken something ?

Nick

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

From: smith@meishan.animal.uiuc.edu (James Smith)
Subject: Re: 1.1.20 - Mosaic 2.4 broken?
Date: 21 Jun 1994 15:48:14 GMT

smith@meishan.animal.uiuc.edu (James Smith) writes:

>Also telnet in from some sites not work in 1.1.20
>1.1.19 work fine.


all problems are solved in 1.1.21  try it now.

===============================================

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

From: tjd@winternet.com (TJ Dulka)
Subject: Re: Disk-compression for Linux
Date: 23 Jun 1994 00:27:23 GMT

Back in the days when I used my PC for DOS, I would compress my drives to
allow for all that virtual hard disk space.  The problem was that if I stored
a zipped compressed file on that disk it would eat up double the virutal 
space since that data could be compressed no further.  In some cases more
that double the space was burned due to the concept of trying to compress
already compressed data.  I learned that uncompressed hard drive space was
better with select compression of infrequently accessed data in lieu of
taking anything off of my hard drive.  Then the prices dropped and I was
able to convince my wife that we needed more hard disk.  Problem solved.

--
      _/_/_/_/_/_/     _/_/_/_/_/_/              
          _/               _/               T.J. Dulka     
         _/           _/  _/                Software Consultant    
        _/  _/         _/_/   _/            tjd@icicle.winternet.com      

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

From: mdaetwyl@iiic.ethz.ch (Markus Daetwyler)
Subject: Context of signal handler call
Date: 23 Jun 1994 12:08:32 GMT

Hi,
I need to write a signal handler which needs some information about
the context in which the signal occured. As far as I discovered in
the man pages the only parameter given to the signal handler is
the signal number. But I need at least the values the registers
EIP, ESP and EAX had when the signal occured.
Are these also put on the stack when calling the signal handler
and when yes, in which order are they on the stack? (probably in the
same order the function ptrace() gets them ?)

Thank you for any help

Markus Daetwyler

mdaetwyl@iiic.ethz.ch

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

From: hoeij@sci.kun.nl (Mark van Hoeij)
Subject: Re: Disk-compression for
Date: Thu, 23 Jun 1994 12:26:45 GMT

In <1.9600.2382.0N27D133@dscmail.com> john.will@dscmail.com (John Will) writes:

>B >>Also, with the PROVEN unreliability of compressed file systems, you 
>B >>would only have a few people willing to use it.  
>B >
>B >Compressed file systems are not inherently unreliable.  By its very
>B >nature, compression eliminates redundancy, which makes it harder to
>B >recover from disk errors.  However, a well-designed system with error
>B >control built-in could be more reliable than an uncompressed system.

>HUH?  While I disagree that compression automatically makes a file system
>unreliable, I have even more trouble with your statement that it could
>somehow make a filesystem more reliable!  You want to try to expand on
>that idea, it sure seems foreign to me!

A compressed file can be checked if it has errors because of the included
CRC check. An uncompressed file can not be checked for correctness, so in
this way the compressed file is more reliable. I use Stacker on half of
my DOS partition. I install most software on the compressed drive, because
these things are on floppy anyway. I store my own files on the uncompressed
drive. This way it can never go wrong. The compressed drive is also
faster than the uncompressed drive.
For Linux a compressed /usr/Tex would save quite a few Mb. I wouldn't
compress /home though.

Mark van Hoeij

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

From: buytaert@imec.be (Steven Buytaert)
Subject: Re: Context of signal handler call
Date: Thu, 23 Jun 1994 13:13:20 GMT

Markus Daetwyler (mdaetwyl@iiic.ethz.ch) wrote:
: I need to write a signal handler which needs some information about
: the context in which the signal occured. As far as I discovered in
: the man pages the only parameter given to the signal handler is
: the signal number. But I need at least the values the registers
: EIP, ESP and EAX had when the signal occured.
: Are these also put on the stack when calling the signal handler
: and when yes, in which order are they on the stack? (probably in the
: same order the function ptrace() gets them ?)

  Markus,

  You should check out the signal.h file in the linux/include/linux
  directory. You'll see there that the definition of a signalhandler
  is as you describe, a function taken a signal as a parameter.

  You'll see also that there is another definition 'ifdef' ed out,
  that takes a sigcontext_struct as second parameter. The 
  sigcontext_struct however is described later in the include file.

  It's that struct that you need to enable. If that is to complicated,
  mail me at my home address.

  BTW, does someone know why this sigcontext structure was ifdefed out
  and why the signal handler function has changed signature. I have
  to adjust the header files for my application. Why has it changed ?

  Stef

--
Steven Buytaert 

WORK buytaert@imec.be
HOME buytaert@innet.be

        'Imagination is more important than knowledge.'
                        (A. Einstein)

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

From: smc@aivru.shef.ac.uk (Stuart Cornell)
Subject: ghostcsript bj600 driver
Date: 23 Jun 1994 11:03:58 -0400
Reply-To: smc@aivru.shef.ac.uk (Stuart Cornell)


QUESTION: 
        Does anyone know of a ghostscript driver for the Cannon bj600 colour
        bubblejet printer ??????????????????

Stuart Cornell
A I Vision Research Unit
University of Sheffield

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

From: ccnjb@sun.cse.bris.ac.uk (NJ. Bruton)
Subject: Wine-940620
Date: Thu, 23 Jun 1994 13:21:41 GMT

Sorry should have said kernel is 1.1.21
Nick

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

From: jou@nematic.ep.nctu.edu.tw (Wei-Jou Chen)
Subject: Re: Wine-940620
Date: 23 Jun 1994 13:49:15 GMT

NJ. Bruton (ccnjb@sun.cse.bris.ac.uk) wrote:
: I've just built wine940620 but nothing now works (including sol.exe)
: Have I made a mistake or has this release broken something ?

   Me too. Help me!
--Jou
==  Wei-Jou Chen ( 3/+B&{ )                                           ==
==  Email:jou@pdlc.ep.nctu.edu.tw or u7824501@cc.nctu.edu.tw          ==
==  Mail : No. 25, Lane 878, Nan-Ta Road, Hsinchu, Taiwan   __o       ==
==         7s&K%++n$j8t878+Q2589                           _\<,_,     ==
==  Tel  : +886-35-266575    Fax  : +886-35-229605   .  ..(*)/(*)     ==

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

From: faustus@zilker.net (Bret Patterson)
Subject: Re: Disk-compression for Linux
Date: 23 Jun 1994 01:22:59 GMT

Phil Howard (phil@zeus.fasttax.com) wrote:
: vinter@cs.uit.no (Brian Vinter) replies to what
: kevin@valis.worldgate.edmonton.ab.ca (Kevin B. Fluet) writes:

: I don't really like seeing precise compression figures quoted.  Some of my
: data gets whopping compression, but on average I've seen a good bit less
: than 2:1 (usually around 1.75:1).
True but linux has alot more text than most operating systems. Man
pages, sources etc.

I personally hate compression programs because I've never heard of one
that is actually 100% reliable, Nor have I heard of one that is as
reliable as not using one. But if someone could come up with one for
linux I would use it, though I wouldn't Alpha nor Beta test it :).

: -- 
: Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
: Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
: CLR/Fast-Tax            | utility?
: phil@fasttax.com        |

--
=======================================================================
                  Bret Patterson <faustus@zilker.net>  
         For general information requests on Zilker Internet Park:
             info@zilker.net  [automated information response]
      Anonymous FTP from ftp.zilker.net       Voice line: (512)206-3850
Specific information requests can be mailed to: support@zilker.net
=======================================================================

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

Subject: Re: Disk-compression for
From: john.will@dscmail.com (John Will)
Date: Tue, 21 Jun 94 08:20:00 -0640

B >>Also, with the PROVEN unreliability of compressed file systems, you 
B >>would only have a few people willing to use it.  
B >
B >Compressed file systems are not inherently unreliable.  By its very
B >nature, compression eliminates redundancy, which makes it harder to
B >recover from disk errors.  However, a well-designed system with error
B >control built-in could be more reliable than an uncompressed system.

HUH?  While I disagree that compression automatically makes a file system
unreliable, I have even more trouble with your statement that it could
somehow make a filesystem more reliable!  You want to try to expand on
that idea, it sure seems foreign to me!

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

From: felix@eltsac.nbg.de (Felix Schmidt)
Subject: Re: Disk-compression for Linux
Date: Wed, 22 Jun 1994 13:39:16 GMT

albayrak@cc.helsinki.fi writes:

>       I would like to discuss about on-fly disk compression. My
>       opinion is that implementing DoubleSpace(R) and Stacker(R)
>       -type compressing file-system is one of the most important
>       future enhancements needed for Linux.

What about the performance?
I think it isn't a problem on a single-user system like DOS,
because the application has to wait for the disk-io to finish anyway,
so the driver can do some uncompression in the meantime and no
one will notice.

When used on a multitasing-OS, some other processes may want to do
some work while the disk-driver waits for the IO to finish.
I admit that i do not know how fast those algorithms really are, but
there is for sure some work to do to acheive a rate of 2:1.

Has anybody *seen* a compressing filesystem on a multiuser-OS
already?
-- 
+---------------------------------------+-----------------------+
| Felix Schmidt, felix@eltsac.nbg.de    |  data  +49-911-552618 |
| Adamstr. 7, 90489 Nuernberg, Germany  |  voice +49-911-581255 |
+---------------------------------------+-----------------------+

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

From: lee@netspace.cis.brown.edu (Lee J. Silverman)
Subject: SIGCHLD not sent or ignored?
Date: 23 Jun 1994 16:46:47 GMT


        This is a followup to my post yesterday about smail proccesses
turning into zombies on occaison.  I've also had this problem with
NCSA's httpd.

        First, my machine configuration: Slackware 1.2 base
installation, Linux 1.1.19 on a Gateway 2000 486DX4/100 with a 540 meg
HD, 16 megs RAM, and a 3COM 3C509 ethernet card.

        I'm trying to run smail in daemon mode (/usr/bin/smail -bd) in
order to reduce smail's impact on my machine load.  In daemon mode,
smail forks to become a daemon proccess, and opens a socket on port
25.  It sets a signal handler for SIGCHLD, and then starts waiting for
a connection.  When it gets a connection, it forks off a child to deal
with the connection, and goes back to waiting.  Pretty standard
behavior for a daemon.

        When the child proccess exits, it should send a SIGCHLD back
to the parent proccess.  I've modified the SIGCHLD signal handler to
log this event.  When I test the daemon by telneting in from my
machine, the daemon catches the signal, executes a wait, does some
accounting, and exits.  However, the logs show that the signal isn't
always caught, and thus I have a number of zombie proccesses lying
around.  I suspect that the signal is caught if I connect from the
local machine but not from a remote machine, but I don't have enough
evidence to say that this is the case.

        Has anyone else had this problem?  Is this a known bug in the
Kernel?  Whom should I mail about this?  Is there any chance that
nobody else is having this problem?

Thanks in advance for any help anyone can give!

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."

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

From: ericy@cais.cais.com (Eric Youngdale)
Subject: Re: Major device number clash (iCS)
Date: 23 Jun 1994 03:19:19 GMT

In article <2u6p3g$18nh@serra.unipi.it>,
Romano Giannetti <romano@pimac2.iet.unipi.it> wrote:
>It have to happen one day...
>Only to point out to all around here that iBCS2 and the PC sound
>driver (for reference: pcsndrv-0.6 ibcs-940526) use the same major
>device number (30). I hit it when trying the wp demo. The solution is
>simple, change the MAJOR in the iBCS2 in the Makefile to, say, 31, and
>all is ok.

        It would seem that neither the iBCS2 nor the sound driver has 
officially reserved major number 30.  Take a look in include/linux/major.h.
I think that since we (iBCS2) got there first that we should get it, but 
this is my own personal bias of course.  We should probably reserve the 
major numbers for these packages in the include/linux/major.h so as to 
prevent these sorts of problems.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

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

From: Techy Admin <technical@glas.apc.org>
Date: 22 Jun 94 12:02 GMT+0400
Subject: Re: PGP 2.6 for Linux

To tell you the truth 2.3A compiled fine on our linux box too.
Btw had somebody posted announce to comp.o.l.a already?
Hmm, fight Clipper widespreading pgp!
AGL
Reply-To: agl@glas.apc.org
Please don't use technical@glas.apc.org for replyes if any at all...

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

From: phil@zeus.fasttax.com (Phil Howard)
Subject: Re: Deadlock with unix domain sockets
Date: 22 Jun 1994 17:24:21 -0500

iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>Yeah as I keep pointing out unix domain sockets are only partially implemented
>and it doesn't make sense to complete them until the other restructuring is
>done. If that one worries you just fix linux/net/unix/sock.c to handle the
>O_NDELAY flag properly.

Does this mean that the kernel is not organized where all I/O goes through
a master point of some sort where things like O_NDELAY can be done in a way
where it is in effect for all devices?  No, I have not studied the Linux
kernel long enough yet to get the big picture on how it is organized.  I
probably should soon since I have an idea would want to try in the kernel
as a device driver.
-- 
Phil Howard KA9WGN      | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted.  So where do I find an unformat
CLR/Fast-Tax            | utility?
phil@fasttax.com        |

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


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