Subject: Linux-Development Digest #307
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 Dec 93 00:13:10 EST

Linux-Development Digest #307, Volume #1         Tue, 14 Dec 93 00:13:10 EST

Contents:
  have init run dip? (Brad Midgley)
  Re: Compiling LAPACK with f2c and Linux (Marc ter Horst)
  Re: have init run dip? (Kai Petzke)
  Re: Compiling LAPACK with f2c and Linux (David Klein)
  getting message -- MARK -- (Ruedi Kneubuehler)
  Looking for  dlopen() and stuff... (Bryan Sparks)
  XF86_SVGA with PEX support (Manuel Weindorf)
  Printer Problem? (Maximilian Ibel)
  Re: What is JAM? (Re: What tools would you use on Linux for business applications?) (Scott Babb)
  ftape-0.9.7 and older Jumbo QIC-40  (Eric Cartman)
  Re: getting message -- MARK -- (Bruce Thompson)
  Has any one ported MAGIC v6 and SPICE3 to LINUX??? (George Shin)
  fs/proc/fd.c bug(?) with patch (Ken Pizzini)

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

From: bmidgley%peruvian.cs.utah.edu@cs.utah.edu (Brad Midgley)
Subject: have init run dip?
Date: 13 Dec 93 01:58:28 MST


I have been using slip with pl14 for a while now and it works great.

To make the use of slip a little cleaner, wouldn't it help to have the
option of running dip from init?  If carrier drops, it would be
restarted (assuming it watches ttyS1 not cua1 so it gets sighups), and
a rudimentary demand-dialed slip could be arranged using init's
runlevels.

I changed dip 3.3.4 to not do a fork and to open the port with
O_NDELAY.  in my dip script I'm telling it to use ttyS1 instead of
cua1.  however, the line settings seem to be different on ttyS1 than
they are assumed to be on cua1.  An aggrivating difference is ttyS1 is
in some sort of buffered mode.  Could anyone show me how to get dip to
put the line in an unbuffered mode?

anyone have thoughts on the concept of using init?
-- 
bmidgley@peruvian.cs.utah.edu

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

From: mht@nuclint.nl (Marc ter Horst)
Subject: Re: Compiling LAPACK with f2c and Linux
Date: Mon, 13 Dec 1993 09:50:45 GMT

In article <2e8sgv$shb@fs7.ece.cmu.edu> weber@young.ece.cmu.edu (Dave Weber) writes:
>From: weber@young.ece.cmu.edu (Dave Weber)
>Subject: Compiling LAPACK with f2c and Linux
>Date: 10 Dec 1993 04:04:47 GMT
>Keywords: LAPACK, numerical analysis, f2c, LAPACK++


>              Getting LAPACK to work with f2c using Linux
>              ===========================================


>This is what I did to get the lapack distribution "lapack.tar.z" from
>netlib.att.com:netlib/lapack/lapack.tar.z running on my Linux box. It
>should work for any site without a FORTRAN compiler but no promises.
>comments would be most welcome, especially in the places where I have
>had to modify code or a test has failed. If there is sufficient interest,
>I will upload the libraries to a suitable site.

>Send comments to me (Dave Weber) at weber@young.ece.cmu.edu.  Please
>take a look at the file INSTALL/install.ps in the lapack distribution
>(careful, it is 150 pages long) for more information.


>The bottom line:
>================

>The good news: LAPACK compiles and looks like it works. The single precision
>               tests as well as the LAPACK++ tests work.

>The bad news: Most of the LAPACK tests (single excluded) fail to 
>              compile (f2c just dies with a segmentation error) 

>              This is not too hard to do but I am sure I have
>              overlooked something :-).

Try switching off optimisation in gcc for a start. Has worked for me before.
 Marc

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

From: wpp@lise.physik.tu-berlin.de (Kai Petzke)
Subject: Re: have init run dip?
Date: 13 Dec 1993 12:24:04 GMT

In <1993Dec13.015829.23741@hellgate.utah.edu> bmidgley%peruvian.cs.utah.edu@cs.utah.edu (Brad Midgley) writes:

>I changed dip 3.3.4 to not do a fork and to open the port with
>O_NDELAY.  in my dip script I'm telling it to use ttyS1 instead of
>cua1.  however, the line settings seem to be different on ttyS1 than
>they are assumed to be on cua1.  An aggrivating difference is ttyS1 is
>in some sort of buffered mode.  Could anyone show me how to get dip to
>put the line in an unbuffered mode?

There are some obvious and some subtle differences between /dev/cua?
and /dev/ttyS?.  In case, you only use a serial line for dialling
out, use /dev/cua? only.  I recently switched from /dev/ttyS1 to
/dev/cua1 when using dip.  Not only, it stopped to "hang", when
calling dip for the second time, it also made auto-retrain work
correctly.  Before, I lost carrier every so often, when I had a
bad line, and now, the modem chooses a lower transmission speed
instead.  I have not modified the modem parameters.

--
Kai
wpp@marie.physik.tu-berlin.de
Advertisement by Microsoft in a well-known German magazine:
        If you don't like our programmes, then make your own ones.
However, they expect you to use Microsoft products for this -:)

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

Subject: Re: Compiling LAPACK with f2c and Linux
From: klein@sunrise.cs.huji.ac.il (David Klein)
Date: 13 Dec 93 12:30:21

In article <2e8sgv$shb@fs7.ece.cmu.edu> weber@young.ece.cmu.edu (Dave Weber) writes:

>   The bad news: Most of the LAPACK tests (single excluded) fail to
>                compile (f2c just dies with a segmentation error)

    Using f2c outside of the makefile on individual files with no
compiler options seems to work for most (but not all) of the files.
Using the new version of f2c definetly works. I compiled all of the tests
and ran them and all of the timing except for eigenvalues (I ran out of
patience). The only errors I got on the tests is that in one place
it told me that it was expecting to call one subroutine and called
a different one instead. (All the results were correct though so I think
that someone forgot to reset a varaible which states which subroutine should
be called.) On one test the accuracy was 27 units instead of 20 so it
gave me a warning but in the documentation they say that anything up to
100 is acceptable.
>   4) I did not run the timings because I used the BLAS in the distribution
>      which are apparently not well optimized so benchmarks will be a bit
>      iffy.
   There is a toms (653) which has an assembler version of BLAS for PC's.
I was told that it can be compiled with the gas compiler but I haven't
treied it yet. (I probably will soon.)

>  5) I had to kludge an "ETIME" function for the LINPACK testing routines.
>      It is just a dummy and always returns 1. Maybe some kind soul can write
>      an ETIME for linux as I do not feel like doing this right now.
   I wrote a timing replacement for ETIME in c code. I am including it
below. Just compile it and link it in with the rest of the code wherever
the makefiles ask for etime. (Note the underscore needed to link fortran
and c together happily.)

#include <sys/times.h>
#include <unistd.h>

#include "f2c.h"

doublereal etime_(tarray)
real *tarray;
{
  struct tms buf;
  time_t ticks;

    /* System generated locals */
    real ret_val;

    /* Parameter adjustments */
    --tarray;

    /* Function Body */
  ticks=times(&buf);
  tarray[1]=buf.tms_utime/100.0;
  ret_val=tarray[1];
  return ret_val;
}

  My timing results seemed appropraite for my machine. I am using a
486DX2-66 and I calculated an approximate MFLOP of 4 just from reading
clock counts off of the handbook that comes with BORLAND assembler.
These are obviously absolutely optimum results. BLAS gave me a
single precision of ~3MFLOPS and a double precision of ~2.5MFLOPS whihc
I consider very decent given the theoretical ceiling. From the actual
LAPACK timing routines there was of course greater variation but I was
consistently getting about 2MFLOPS.

   David Klein
   KLEIN@SUNRISE.HUJI.AC.IL



--
                      David Klein
                      KLEIN@SUNRISE.HUJI.AC.IL

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

From: pingu@chg.imp.com (Ruedi Kneubuehler)
Subject: getting message -- MARK --
Date: Mon, 13 Dec 1993 16:21:56 GMT


hi linuxers out there,

is anybody here, that can tell me, what this message i get every 20 minutes
does mean.    

    -- MARK --


thats all its write to the screen.


thanks for your help.

ruedi.


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

From: bsparks@Novell.COM  (Bryan Sparks)
Subject: Looking for  dlopen() and stuff...
Date: Mon, 13 Dec 1993 16:56:30 GMT


Someone posted some time ago the dlopen() library but I lost the post.
Could you please direct me to this library for Linux pl14?  Or was I 
dreaming?

Thanks
Bryan
--
Bryan Sparks     bsparks@Novell.COM     (801) 429-3853

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

From: weindorf@bau-verm.uni-karlsruhe.de (Manuel Weindorf)
Subject: XF86_SVGA with PEX support
Date: 13 Dec 1993 18:17:53 GMT
Reply-To: weindorf@bau-verm.uni-karlsruhe.de

Hello world,

does anybody know a FTP-server which containes
XF86_SVGA (XFree 2.0) with PEX support ???

please mail me .... thank you

Manuel




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

From: ibel@informatik.uni-wuerzburg.de (Maximilian Ibel)
Subject: Printer Problem?
Date: 13 Dec 1993 19:31:29 GMT

Hello, Linuxers.

Last Saturday, some strange thing happened to me:

I plugged the printer cable out of my linux box (to test the
printer with another computer). Since then, no mdir/mdel/mformat etc.
did work. The shell hung, and with top I could`t see a mdir etc. process.
The drive LED did not light, either.

However, the fdformat command worked fine.
After rebooting, everything worked fine.

Now, is this a bug, or is it a feature?

Whishing you a nice day,
Maximilian
--
                                             / /
                                            |__| 
                                           ( ,, )
#--------------------------------------oOO--(__)--OOo----------------------#
|  DG5NER@DB0BOX   |"Die Freiheit, die wir meinen, ist frei von jeder      |
|ibel@informatik.  | Meinung!"                                             |
| uni-wuerzburg.de | --- Der "Atlantis-West-Chor"                          |
#--------------------------------------------------------------------------#


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

From: babb@rapnet.sanders.lockheed.com (Scott Babb)
Subject: Re: What is JAM? (Re: What tools would you use on Linux for business applications?)
Date: Mon, 13 Dec 93 20:26:27 GMT

Guru Aleph_Null (spj@ukelele.gcr.com) wrote:
: In article <1993Dec8.223434.12433@porthos.cc.bellcore.com>,
: Martin Zam <marz@cococay.NoSubdomain.NoDomain> wrote:
: >If you were to attempt this on Linux, what tools would you choose and why?
: >I'm looking (hoping) for JAM-like functionality in the development tools.
: >This ought to make for a lively discussion!  Have at it!

: It ought to, because my first question is: What is JAM?

Since the topic is development tools, I suspect that Martin was
referring to Jyacc's JAM (Jyacc Application Manager?).  Which is
a tool for developing windowed applications.

--
   Lockheed Sanders may disagree so these are solely the opinions of:
             Scott L. Babb - babb@rapnet.sanders.lockheed.com
              "We didn't inherit the Earth from our parents,
                   we are borrowing it from our children."

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

From: eric@julian.uwo.ca (Eric Cartman)
Subject: ftape-0.9.7 and older Jumbo QIC-40 
Date: Mon, 13 Dec 1993 22:39:41 GMT


Has anyone gotten ftape-0.9.7 to co-operate 
with older QIC 40s like the Jumbo DJ-10?

<6>module `driver' (38 pages @ 0x01002000) created
<6>initializing module `driver', 40100 (0x9ca4) bytes
<6>  init enty @ 0x010020c4, cleanup entry @ 0x010021e4
<6>kernel-interface.c (init_module) - installing QIC-117 ftape driver....
<6>calibr.c (calibrate) - starting calibration of function: `udelay'.
<6>calibr.c (calibrate) - time = 84940 usec for count = 6400.
<6>calibr.c (calibrate) - starting calibration of function: `fdc_wait'.
<6>calibr.c (calibrate) - time = 75056 usec for count = 25600.
<6>ftape-io.c (_ftape_open) - unknown drive type, no response.
<6>ftape-io.c (_ftape_open) - bad luck: unsupported drive !.
<6>kernel-interface.c (ftape_open) - _ftape_open failed.
 

-e

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

From: bruce@mdavcr.mda.ca (Bruce Thompson)
Subject: Re: getting message -- MARK --
Date: 13 Dec 93 20:53:13 GMT

Ruedi Kneubuehler (pingu@chg.imp.com) wrote:

: hi linuxers out there,

: is anybody here, that can tell me, what this message i get every 20 minutes
: does mean.    

:     -- MARK --


: thats all its write to the screen.


: thanks for your help.

: ruedi.

That is produced by syslogd. I cannot remember the precise details,
but the fact that you are seeing it has to do with your syslogd.conf
file. Check the man page for syslogd for more info.

        Cheers,
        Bruce.

--
.sig under construction.

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

From: gshin@kilby.elee.calpoly.edu (George Shin)
Subject: Has any one ported MAGIC v6 and SPICE3 to LINUX???
Date: Mon, 13 Dec 1993 21:17:02 GMT

hello,

Has anyone ported Berkeley's MAGIC (VLSI CAD software) version 6 or/and Berkeley's  
SPICE3 program to LINUX OS??? Currently I'm running those two programs under
DEC's ULTRIX and would like to know if anyone tried porting them under LINUX.
I thought it would be nice if we can port those programs (runs under X-server)
to PC environment for VLSI development...

thanks...

george


"when the only tool you have is a hammer, every problems you encounter tends
 to resemble a nail..."
                                - source unknown


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

From: ken@halcyon.com (Ken Pizzini)
Subject: fs/proc/fd.c bug(?) with patch
Date: 13 Dec 1993 14:34:48 -0800

The current (0.99p13 and 0.99p14 anyway) version of fs/proc/fd.c
fix some old bugs (0.99p10 and earlier) -- namely
        echo test | cat /proc/self/fd/0
now works.  (I never tested under p11 or p12, so I'm not sure
when this was fixed.)

However, it still behaves incorrectly (by my understanding) for
        (echo this; echo that >/procl/self/fd/1) >/tmp/foo

My understaning of the desired semantics for the fd/n files is
that they should behave the same as /dev/fd/n under Bell Labs
research v9, where a dup(2) of the named file descriptor is
returned.  Under Linux 0.99p14 the above test fragment leaves
/tmp/foo containing the one line "that", since the open of
/proc/self/fd/1 returns an independent file descriptor to
the stdin inode; the expected behavior under my assumption
would be for the file to contain two lines "this" and "that".

I've made a first-cut attempt at fixing this (enclosed in
the patch below), but I'm not understanding where the i_op
field should be set.  See the block of code mentioning an
"ugly hack" for what needs to be fixed.  I'd appreciate
any comments about whether this is actually a reasonable
solution, or suggestions as to how to do this better.
Or set me straight as to why the current behavior is desirable,
and suggest a new /proc/self/xxx name for my semantics.

(I have this patch running on my 0.99p14 kernel, and it works
fine.  I have done a "ln -s /proc/self/fd /dev/fd", and
"ln -s fd/0 /dev/stdin; ln -s fd/1 /dev/stdout; ln -s fd/2 /dev/stderr"
to set up a v9-like file descriptor "device".)

                --Ken Pizzini

--- linux/fs/proc/fd.c.orig     Sat Jun 26 10:28:06 1993
+++ linux/fs/proc/fd.c  Mon Dec 13 12:38:31 1993
@@ -15,6 +15,7 @@
 
 static int proc_readfd(struct inode *, struct file *, struct dirent *, int);
 static int proc_lookupfd(struct inode *,const char *,int,struct inode **);
+static int proc_openfd(struct inode *, struct file *);
 
 static struct file_operations proc_fd_operations = {
        NULL,                   /* lseek - default */
@@ -24,7 +25,7 @@
        NULL,                   /* select - default */
        NULL,                   /* ioctl - default */
        NULL,                   /* mmap */
-       NULL,                   /* no special open code */
+       proc_openfd,            /* open */
        NULL,                   /* no special release code */
        NULL                    /* can't fsync */
 };
@@ -59,12 +60,12 @@
        int i;
 
        *result = NULL;
+       if (!dir)
+               return -ENOENT;
        ino = dir->i_ino;
        pid = ino >> 16;
        ino &= 0x0000ffff;
        ino -= 7;
-       if (!dir)
-               return -ENOENT;
        sb = dir->i_sb;
        if (!pid || ino > 1 || !S_ISDIR(dir->i_mode)) {
                iput(dir);
@@ -120,6 +121,10 @@
        }
        if (!(*result = iget(sb,ino)))
                return -ENOENT;
+       if (ino & 0x0100) {
+           /* ugly hack to get proc_openfd on this inode: */
+           (**result).i_op = &proc_fd_inode_operations;
+       }
        return 0;
 }
 
@@ -195,4 +200,37 @@
                return j;
        }
        return 0;
 }
+
+
+/*
+ * proc_openfd by Ken Pizzini (ken@halcyon.com)
+ * Placed in the Public Domain
+ *
+ * Fixes semantics to be equivalent to a dup(2) of the designated
+ * file descriptor.
+ *
+ */
+
+#include <linux/fs.h>
+
+/* from fs/fcntl.c: */
+extern int sys_dup2(unsigned int, unsigned int);
+
+static int
+proc_openfd(struct inode * inode, struct file * file)
+{
+    unsigned int oldfd = inode->i_ino & 0xff;
+    unsigned int curfd;
+    int error;
+
+    if (file->f_mode > current->filp[oldfd]->f_mode) /* Should this be == ??? */
+       return -EACCES;
+    for (curfd=0; curfd<NR_OPEN; ++curfd)
+       if (current->filp[curfd] == file)
+           break;
+    /* we let sys_dup2 deal with any remaining error conditions */
+    if ((error = sys_dup2(oldfd, curfd)) < 0)
+       return error;
+    return 0;
+}

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


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