Subject: Linux-Development Digest #240
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 29 Sep 94 02:13:06 EDT

Linux-Development Digest #240, Volume #2         Thu, 29 Sep 94 02:13:06 EDT

Contents:
  Adaptec 1542/SCSI under Linux (Jason Malaure)
  Re: Alpha Linux (Chris Bitmead)
  Re: Korn Shell '93 Now Available from AT&T (Chris Bitmead)
  e2100.c(driver for cabletron) broken? (Michael Zoran)
  Re: Multiprocessing Pentium Systems (David Monro)
  Driver for PDMA16 16 bit digital I/O board (Jim Leven)
  An idea: Weighting the cache per device (Gary Paul Gortmaker)
  getopt in libc broken? (David Martin)
  Re: LOOK FIRST-- FORGED SPAM (Michael E. Mendis)
  is syscall(SYS_select,...) broken? (Gautam Thaker)
  security hole with /proc/**/mem ?? (Walter Wolfgang)
  IF YOU HAVE A MAGNETO-OPTICAL DRIVE... (James Jurach)
  HELP: Linker won't recon constructor (K.B. van Benten)
  Re: Could TCP/IP be implemented over SCSI? ([email-masked])
  Re: [STATUS] Linus Floppy Driver Development (Walter Wolfgang)
  Re: Does Quicken work under DOSEMU? (Charles Hubbert)
  Re: Linux Floptical Disk Driver? (Gareth Webber)

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

From: [email-masked] (Jason Malaure)
Subject: Adaptec 1542/SCSI under Linux
Reply-To: [email-masked]
Date: Tue, 27 Sep 1994 10:31:49 +0000

I would like to know how reliable SCSI generally is under Linux. I have
had some problems witj my Fujitsu floptical but I am quite prepared
to accept that lies with the way the drive behaves, however I would
be very interested to find out how people have been getting with 
large SCSI drives (>1 gig or so) as I am thinking of buying one!

Many thanks

Jason.

-- 
Jason Malaure

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

From: [email-masked] (Chris Bitmead)
Subject: Re: Alpha Linux
Date: 28 Sep 94 17:16:06

In article <[email-masked]> [email-masked] (Andrew Bulhak) writes:

>Jay Ashworth ([email-masked]) wrote:
>: [email-masked] (Andrew Bulhak) writes:
>: >: Only if Linux on the Alpha will be a 64-bit-OS. If it will be, I hope
>: >: that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
>
>: A posting in cola about a week ago said that it would be a 32-bit os, with
>: access to long-longs.
>
>Is that Linus' Alpha Linux or the DEC port?

Linus' port is 64 bit. The DEC port is 32 bit.

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

From: [email-masked] (Chris Bitmead)
Subject: Re: Korn Shell '93 Now Available from AT&T
Date: 28 Sep 94 17:32:19

In article <[email-masked]> [email-masked] (James J. Yorton) writes:

>     "The Labs raised some software packaging and porting issues
>     that may make it impractical for us to license source code.
>     
>     Prices for the binary version of K-shell '93 are $99 per copy
>     (per cpu) until December 31, 1994. Orders placed after that date
>     will be licensed at $149 per copy. We will also write a site
>     license, for a variety of platforms, without restriction as to
>     the number of users or cpus, for $10,000."

$149 just for a shell? Forget it!

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

From: [email-masked] (Michael Zoran)
Subject: e2100.c(driver for cabletron) broken?
Date: 29 Sep 1994 00:35:31 GMT

    Is the driver for 16-bit cabletron cards broken in the developmental 
kernels?  This used to work in the v1.0 kernels, but now it doesn't. BTW, the 
e2100.c driver wasn't standard in v1.0, but had to be added.
    I used to use v1.0, but I have decided to try out the newer kernels.  
I am trying v1.1.51.  The driver appears to be tring to use the secondary  
interface (?) to the card.  The old version used the primary interface and 
worked fine.
If someone has gotten the newer one to work, please let me know.
    BTW, I don't post much, so I may have placed this in the wrong section. 
I'm not sure if this should go in help, development, or the net mailing list.
If I'm posting in the wrong section, please send me a flame via E-Mail. 
(to reduce the load on news bandwidth)

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

From: [email-masked] (David Monro)
Subject: Re: Multiprocessing Pentium Systems
Date: Wed, 28 Sep 1994 06:07:55 GMT

Assuming the hardware is fairly standardized, how hard would it be to do
a hack along the lines of what I believe Sun did (don't flame me too hard
if I am wrong!) to support MP machines under SunOS 4.1.3 - I hear there
is simply a mutex around the whole kernel, so the kernel doesn't have to
be multi-threaded. Of course, this results in a godawful performance hit
on a machine with lots of processes doing syscalls - it degrades to the
performance of a single processor machine. However it works fine if
processes spend most of their time executing in user mode (my SO uses a
dual processor Sparc in her Physics department running 4.1.3 - half the
processes do nothing but compute for a week, so it works quite well).

I am not suggesting this as a real solution, but it might do as a half
way house until such time as the kernel is fully threaded.

As an aside, are there any really good MP OSs out there? Considering the
things I've heard people say about Solaris, SCO and WinNT, I'm beginning
to wonder... (mind you at university I work on a 6 processor Sparc running
Solaris 2.3 supporting >140 X terminals, and it is a lot better than
the 6 Mips R3000 boxes supporting rather fewer terminals last year, so I
don't see what's so bad about Solaris - apart from the bugs, and the
mutexes around the lock and process tables.. still it works OK)

Whatever, if Linux is going to run on MP hardware (whether it be 486s,
Pentiums, DEC Alphas, Mips R4x00s, PowerPCs, 680x0s or anything else you
care to dream up), we should probably better do our homework pretty
thoroughly first. Any good texts out there on how to write an MP OS :-?

        David Monro

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

From: [email-masked] (Jim Leven)
Subject: Driver for PDMA16 16 bit digital I/O board
Date: 29 Sep 1994 00:33:07 GMT

I am looking for a UNIX driver for the PDMA16 digital I/O board.
The PDMA16 is a 16 bit DMA interface board capable of transfer rates 
up to 250 kbytes/s in blocks of 64 kbytes.  I wish to interface this 
to an eavesdropping data acquisition system to read 3.2 Mbyte records
at a rate of 175 kbytes/s.

Can anyone help me with a Linux (or other PC UNIX) driver for the PDMA16
(or even another digital I/O board).

Thanks

Jim Leven
Australian Geol Survey
[email-masked]

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

From: [email-masked] (Gary Paul Gortmaker)
Subject: An idea: Weighting the cache per device
Date: 29 Sep 1994 01:55:26 +1000

        I was thinking that a lot could be gained by putting some sort of
sysop-configurable weighting factor on block devices with respect to
file system caching. (via an ioctl() or whatever seems appropriate...)

Consider this example. 

        A user with a reasonably quick IDE drive and an average
CD-ROM upgrades his 8MB system to 20MB. Seeing as he can't use
the remaining four 1MB SIMM modules, he sticks them in a VLB-IDE cache
controller card. Now, just forget the weighting factor for the time
being, and assume that we just had a simple ALLOW/DISALLOW_CACHE
for each block device, so that Joe User could set the IDE drive as 
non-cacheable. In this case, the user still has a substantial (4MB) cache
on the IDE drive (in hardware) and the VFS/software cache is concentrated
on the slower CD-ROM device. Even without the external IDE cache controller,
having the VFS cache concentrated on the slow CD-ROM, and taking the
seeks on a 10 --> 12ms IDE drive would be desirable for intensive CD-ROM
usage. This might be a major plus for those users who run Linux directly
off a CD-ROM. (No, I don't own an IDE-cache card, _or_ a CD-ROM.)

Another example could be a SCSI disk shared between two Linux boxes
(one host ID#7 and the other ID#6) where one is generating large
amounts of data (and writing it to the shared disk) and the other
box has the disk mounted "ro" and is analysing the data. This can only
be done if the "ro" mount also has the fs marked as non-cacheable,
to get NFS-like behaviour. (...without the sad NFS xfer rate ;-)

Of course, the default value for each block device would be equal at
boot-up, and the user could tune it on the fly, or add it to his rc
files. This value would be used in conjunction with the things that
the kernel takes care of already, such as most recent access, number 
of accesses, age, etc.

$ cat /etc/blk.cache

# Sets priority level of each block device with respect to buffer cache.
# Parsed by /sbin/setcache at boot time.
# A value of zero means "don't cache this device" and a maximum value
# of 10 means "hold onto cached blocks from this device". In general,
# give low numbers to fast devices, and high numbers to slow devices.
# Default value is 5, assigned by the kernel.

/dev/hda        4       # Fast IDE
/dev/hdb        5       # Slower IDE
/dev/sda        2       # Barracuda SCSI disk, faster than hda
/dev/sdb        6       # Old SCSI disk, slower than hdb
/dev/sr0        8       # Slow SCSI CD-ROM
/dev/mcd        9       # Mitsumi CD-ROM, slower than the SCSI CD-ROM
/dev/fd0        10      # Try to keep 3.5" floppy info (until ejected :-)
/dev/fd1        0       # I only read 5.25" disks once, and then eject them.

# End of /etc/blk.cache
$

Too difficult?  Is buffer.c already to ugly?  Featur-itis? 

Opinions welcome.
Paul.

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

From: [email-masked] (David Martin)
Subject: getopt in libc broken?
Date: 28 Sep 1994 11:50:44 -0400

I have libc 4.5.26.  I've noticed a strange behavior with the getopt()
function.  getopt() doesn't terminate when it encounters a string (a
non-argument) in the argument list.  Most noticeably, the rsh command:

rsh machine ls -l /etc/motd

The code for rsh is correct and it compiles and runs correctly on my
AIX system.  On Linux, getopt() examines the entire list, rather than
stopping at the first non-argument (in this case "machine").  So Linux
will interpret the -l option as being for rsh, and try to run the ls
command on machine as the user "/etc/motd".

Are there any plans to change/correct this behavior?  Please send
comments through e-mail ([email-masked]).

From the `man 3 getopt` on my AIX system:

  Return Values
  
  The getopt subroutine returns the next flag letter specified on
  the command line.  A value  of  -1  is  returned when all command
  line   flags  have  been  parsed.    When  the   value   of   the
  ArgumentV [Optind] parameter is null, *ArgumentV [Optind] is not
  the - (minus) character, or ArgumentV [Optind] points to the "-"
  (minus) string, the getopt subroutine returns a value of -1
  without changing the value.  If ArgumentV [Optind] points to the
  "- -" (double minus) string, the getopt subroutine returns a
  value of -1 after incrementing the value of the Optind parameter.

-- 

# David Martin   System Administrator   NASA Lewis Research Center
# [email-masked]   (216) 977-7014   Cleveland, Ohio

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

From: [email-masked] (Michael E. Mendis)
Crossposted-To: comp.os.linux.help,comp.os.minix
Subject: Re: LOOK FIRST-- FORGED SPAM
Date: 29 Sep 1994 01:52:40 GMT

   If you have the time and ability to help us trace this, we can give you 
   info on who is doing it and maybe try to pressure HIS site to drop him.

Now, lets be PC in this world.  And I am not talking about Personal computers,
or Providence College.  It should say IT'S.

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

From: [email-masked] (Gautam Thaker)
Subject: is syscall(SYS_select,...) broken?
Date: 29 Sep 1994 01:53:58 GMT

I had asked this question to c.o.l.help and even though a kind
soul or two had nice suggestions to look at various things
no one ever confirmed if this is indeed a bug or not.
(The same pgm work fine under SUN OS).

I am willing to go down an try to hunt down the problem,
but it would be nice if someone would agree first that it
is indeed an indication that something is broken.

Gautam
=================================================================
#include <stdio.h>
#include <unistd.h>
#include <linux/time.h>
#include <sys/varargs.h>

#include <sys/param.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/syscall.h>
#include <sys/socketcall.h>
#include <sys/ioctl.h>
#include <netdb.h>
#include <errno.h>

#ifdef __linux__
#include <sys/socketcall.h>
#include <linux/unistd.h>
#endif /* __linux__ */

int main() {
  int s, s2, n;
  fd_set fdset;
  char buf[80];

  FD_ZERO(&fdset);
  FD_SET(0, &fdset);
/*   n = select(1, &fdset, 0, 0, 0);      WOrks ok.*/
  n = syscall(SYS_select, 1, &fdset, 0, 0, 0);  /* gets segmentation fault */
  printf("n = %d\n", n);
  return 1;
}

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

From: [email-masked] (Walter Wolfgang)
Subject: security hole with /proc/**/mem ??
Date: 27 Sep 1994 11:25:23 GMT

I noticed that /proc/xxx/mem has read permission for the effective user.
Isn't this a security whole ? If a process of root switches his eid to one of a
normal user, wouldn't this user be able to read the whole memory of this process,
maybe some secret data ? I also noticed that if I cd /proc/xxx i am still able to 
read mem even if the process switched his eid back.
(I used the nfs-server for these experiments).

Wolfgang Walter

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

From: [email-masked] (James Jurach)
Crossposted-To: comp.os.linux.help
Subject: IF YOU HAVE A MAGNETO-OPTICAL DRIVE...
Date: 28 Sep 1994 16:52:46 -0500

Help.

If you have a SCSI magneto-optical drive or have seen one that "works" 
under Linux-1.1+  please let me know.  I need to purchase one of the 
1.3 Gb variety, but at this point, I am open to suggestion.

These are the only ones I am aware of at this point:
=========================
Fujitsu M2511A  (128 Mb)
Ricoh 5030E-II  (???)

I know that without serious tweaking, this drive does _not_ "work":
=========================
HP C1716T (1.3 Gb) 

As this information is not privided in the SCSI-Howto, if there is
much of a response, I will share it with anyone else who is interested.
However, from my previous request (about a month ago) I received only
1 response.   :-(

I'd appreciate model #, disk capacity, dimensions, and approximate cost.
However, I need mainly the model # and capacity.  Thanks in advance.      

                With fingers crossed and eyes to the skies,
                James Jurach
                [email-masked]

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

From: [email-masked] (K.B. van Benten)
Subject: HELP: Linker won't recon constructor
Date: Wed, 28 Sep 1994 21:52:50 GMT

Hi there,

I installed Linux yesterday, and today i tried to
compile/link one of my progs, but g++ gave me this:
"unresolved external List<int>::List(void) in text segment"
or something close to that.
What can I do?

Thanx, 

Kasper van Benten

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

From: [email-masked]
Subject: Re: Could TCP/IP be implemented over SCSI?
Date: Wed, 28 Sep 94 11:51:07 PDT

<[email-masked]> writes:
> 
>       I read in the SCSI FAQ that two SCSI hosts can share SCSI peripherals
> on the same bus.  Is it possible for these two hosts to send commands to each
> other?
>       I am asking because I would like to know how viable it would be to add
> support to Linux for TCP/IP over SCSI, which might be practical for two or
> three machines which already have SCSI support.
> 
We did something like this about 7 years back at one company I worked for.... 
Passing messages over the SCSI bus.... so here goes...

1. Each host on the SCSI bus must have a separate SCSI ID.. The more hosts the 
less devices... only 7 ID's available (i.e. host1=7 host2=6 cdrom1=5 hd0=0)

2. The Linux SCSI driver would have to be hacked to accept async command 
message from the bus (just like an HD does.. but most drivers don't support the 
capability by default)... whats worse.. it takes an inteligent SCSI card to do 
this efficiently (Adaptec 154x or better, 1520 wont handle it). Next, the SCSI 
card needs to interrupt when a packet arrives (1520 works in polled mode so it 
would take buku cpu time to monitor for messages)... Thats the Physical Layer.

        (?? Or am I lying and the Linux SCSI DRIVERS will accept ASYNC CMDS ??)

3. Treat the interface just like an ethernet card.. but with no broadcast 
capability, and fixed ARP tables on each machine.. Assign the SCSI bus its own 
IP Network or SubNet.. then the ARP tables tell you the SCSI ID of the target 
host... Sending a packet is just like issuing a command to a HD... and if the 
target device times out responding to the command... drop the packet on the 
floor... Just like ENet does if the target host is not available...

Voila... 5 MByte per second TCP/IP! (or more for SCSI-2)

That should cover the essentials.. NOW:
        HOW MANY SCSI DEVICE DRIVERS NEED TO BE HACKED TO SUPPORT THIS ??

        I'm not a kernel guru.. but I'll take a look at the SCSI drivers over 
the next week or so and see if there is any hope... I've already looked at the 
network driver interfaces, and they appear to be no problem...

So as final answer to Lincoln's question:
        Yes its is POSSIBLE to run TCP/IP over SCSI...
        Ready to get to work writing it ???

        John Barrett <[email-masked]>

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

From: [email-masked] (Walter Wolfgang)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 27 Sep 1994 11:53:02 GMT

Alan Cox answered to David Holland:
>Install amd. That will happily do the job. As to identifying file system
>types thats also a ten line user program.

I did this some month ago for floppy and cdrom.
Just use the program filesystem of amd.
I wrote a little programs to determine the filesystem-type of the disk.
It works rather good.

Problems:
-       amd tries to unmount a mounted filesystem after some time,
        which seems to configurable only for all mountpoints managed by an
        amd process (I read the manual and couldn't find a way)
        So if you use amd for nfs, too, start an extra amd process for
        the "quick to unmount" devices. (i use 15 seconds).
-       I found no way to determine the user causing the mount request, so
        amd internaly should know him.
        So you have to give rw permissions for the floppy to all users, if you
        use the same mountpoint for all of them.

Wolfgang

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

From: u4944@walter (Charles Hubbert)
Subject: Re: Does Quicken work under DOSEMU?
Date: 27 Sep 94 06:47:10 CDT

Justin Edmond Zaglio ([email-masked]) wrote:
: The title pretty much says it all: doe any of the DOS flavors of
: Quicken work under DOSEMU?  If not, are there any financial packages
: that *do* work under it?

Related Q: Does Quicken for Windows run under WINE?

Thanks,
Chuck H.
[email-masked]

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

From: [email-masked] (Gareth Webber)
Subject: Re: Linux Floptical Disk Driver?
Date: 27 Sep 1994 12:08:05 GMT

: Have anyone out there any informations or experiences about these 
: drives? Are they suported by Linux or have a device driver to be 
: developed? do they require a special controller?

I have an instite floptical which is a scsi drive. I bought the kit which
includes a non-standard TMC850M (future domain 8bit) card which will work
with linux if you alter the accepted signatures and remove fast32 from the 
defines in the code. I can send you exact details if you get the same.

The drive is fine. As soon as the card was working the drive appeared as 
/dev/sda and 20Mb floppies were mine :-)

gary...

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

** 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: [email-masked]

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

    Internet: [email-masked]

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