Subject: Linux-Development Digest #891
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:     Wed, 6 Jul 94 01:13:04 EDT

Linux-Development Digest #891, Volume #1          Wed, 6 Jul 94 01:13:04 EDT

Contents:
  Re: tcsh bug: more information (Albert D. Cahalan)
  1.1.24 and bi-directional lines (Clayton Haapala)
  Re: Serial Driver/Callback Problems (John Lellis)
  async file IO on linux? (Mike Harm)
  building a PCMCIA SCSI adaptor (sidney hellman)
  Re: High performance graphics under Linux (or lack thereof) (Jonathan Magid)
  Re: System lock ups: NCR 53c810 driver problem? (E.C. Loyd)
  Re: NCR-Driver Bug with Fdisk (E.C. Loyd)
  Re: tcsh bug: more information (Roth Mark Daniel)
  what is AF_MAX for Linux? (Gautam Thaker)
  Re: Dedicated SCSI swap drive? (Beverly J. Brown)
  Comined atdisk2 and ide performance 2 patch (David Monro)
  Re: DosEmu suggestion (James B. MacLean)
  Re: (?) C64 disk drive interface and file system? (Russell Alphey)

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

From: adc@bach.coe.neu.edu (Albert D. Cahalan)
Subject: Re: tcsh bug: more information
Date: 05 Jul 1994 19:06:43 GMT

In article <2vc2jl$21r@glitnir.ifi.uio.no> kjetilho@ifi.uio.no (Kjetil Torgrim Homme) writes:
   +--- Roth Mark Daniel:
   | On the flip side, it's trivial to do string pattern matching under
   | csh, whereas sh uses test for all it's expression evaluation, and is
   | a bit limited.

   Nonsense. "test" isn't even a builtin in the original V7 shell, but
   "case" is. Besides, "expr" is just as good a tool for expression
   matching. If sh doesn't have good enough data manipulation for your
   task, write (perhaps just parts of it) in awk or Perl.

   (Okay, Bourne shell lacks modifiers amd arrays, but you can do a lot
   of cool tricks with IFS and set :-)

What about C?  There is a point where you have to give up using shells.
--

Albert Cahalan
adc@meceng.coe.neu.edu

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

From: clay@haapi.mn.org (Clayton Haapala)
Subject: 1.1.24 and bi-directional lines
Date: Tue, 5 Jul 1994 22:15:16 GMT

I recently brought up 1.1.24 as an alternate kernel, having been a long-time
happy customer of 1.0.9.  Running getty_ps2.0.7e on my serial port hooked
to my modem, I find that the line rarely reinitializes correctly after
dialing-out with uucico.  This works fine under 1.0.9.  From what I can
see of the modem lights, DTR doesn't wiggle at the end of the call, and
the getty process (not uugetty in my box) doesn't re-init and turn
auto-answer back on in the modem.

Anybody seen this?  Please feel free to rub my nose in any docs that indicate
that I have to change my getty, etc. setup for the new kernel. :-)
-- 
Clay Haapala                    "Well, there was the process of sitting around
clay@haapi.mn.org                and wishing I had more computer stuff."
                                        -- Dilbert

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

From: lellis@dmccorp.com (John Lellis)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Re: Serial Driver/Callback Problems
Date: 5 Jul 1994 19:12:58 GMT

In article <2us1gc$of1@uuneo.neosoft.com> John Lellis wrote:
> I've e-mailed this question to Karel Kubat, author of callback-1.21, Kris
> Gleason, author of getty_ps-2.0.7e, and Ted Ts'o, author of the serial port
> drivers, but I am open to suggestions from anyone with a bright idea as to
> how to solve this problem:

> The callback-1.21/getty_ps-2.0.7e combination works great under kernel 1.0.9
> (I now have four lines coming into a kind of "modem server" here at work).
> I've been trying out the 1.1.x kernels as they are issued and would like to
> migrate to one of them (faster SCSI access, networking improvements, etc.)
> except that when I test them, the callback setup always malfunctions.

I have pretty much the same problem: With the new kernels, I can get
the modem only once to answer the phone correctly for incoming calls.
Subsequent calls fail: The modem goes offhook, but the waiting getty
never wakes up.
The only difference is, that I have seen no difference, whether I quit
by hanging up the phone or bei typing 'exit'.

If you get any help on this, could you please drop me a line, since
I'm also stopped from upgrading.

Thanx,

JanO

ps: This is with agetty, libc-4.5.21, kernel 1.1.18-23.
--
Jan-Olaf Droese   | email: jano@layla.RoBIN.de (home) |   o
Gluckstr. 6       |        zdjod@lif.de (work)        |  _>\ _
60318 Frankfurt   | phone: ++49-69-552167             | (_)<(_)




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

From: mharm@gizmo.usc.edu (Mike Harm)
Subject: async file IO on linux?
Date: 5 Jul 1994 17:27:01 -0700

Hi.  I have an application which I wrote for suns, and I've
been having trouble porting it to linux.  It shells
a subprocess which talks to the parent through a socket.
I use something like this on the socket handle:

signal(SIGIO,io_handler_proc);   /* call this proc when IO happens */
fcntl(sock,F_SETOWN,getpid());   
fcntl(sock,F_SETFL,FASYNC);     /* use async IO */
/* and then it drops into an xwindows event loop */

this works swell on the sun, I can't find any flag that
does what FASYNC does, namely, tell the stupid socket
to use asynchronous IO.  the header files say that the
flag O_SYNC is not supported, and don't even mention an
async flag.

Is there another way to do asynchronous socket IO under linux?
I figure there has to be... X works, after all...

Any help would be greatly appreciated.  Please email replies
to me if its not too much trouble.  I can post a summary if
people request it.

Cheers,


Mike Harm
mharm@gizmo.usc.edu
Cognitive Science / Psycholinguistics Lab
Univ. of Southern California
===============================================================

   "Never drive a car when you're dead."     - Tom Waits




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

Crossposted-To: comp.os.linux.misc
From: sid@ldgo.columbia.edu (sidney hellman)
Subject: building a PCMCIA SCSI adaptor
Date: Tue, 5 Jul 1994 18:19:59 GMT



        A few months ago I posted some questions about SCSI pcmcia
adaptor for linux, and discovered that as of now there is nothing
available.  We are about to give up on getting the programming info
from Adaptec and their not-so-cooperative competitors, and are
considering making up our own SCSI pcmcia adaptor.  WE ahve two
questions at this point.

        1) Who would be interested in picking up such a board, if we
develope it. 

        2) what SCSI controller chips do people prefer.  We are
thinking about using the WD3393A because our Engineer is familiar with
it, but are there other chips that are preferred by Linux? (i.e.
Fujitsu or NCR perhaps)

        We really didn't want to go down this road, but we don't have
much of a choice, as we see it.


                        Sid Hellman

-- 
Sid Hellman at the Passcal Instrument Center |          
Lamont-Doherty Earth Observatory             |  "There is a fine line between 
of Columbia University                       |      Clever and Stupid."
sid@ldeo.columbia.edu    (914)365-8728       |          - David St. Hubbins

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

From: jem@bittyblue.oit.unc.edu (Jonathan Magid)
Subject: Re: High performance graphics under Linux (or lack thereof)
Date: 5 Jul 1994 19:31:16 GMT

In article <Jul.5.01.14.04.1994.22405@crab.rutgers.edu>,
William Hoffman <wmhoffma@crab.rutgers.edu> wrote:
>Hi.
>
>I've been having some trouble porting my DJGPP (DOS 32-bit port of
>GCC) graphics code to Linux and svgalib.  I've been able to get all
>the functionality ported, but the speed has been left behind.  I was
>getting about 10 fps with my test program using DJGPP in DOS, and by
>contrast I'm getting about 1 fps under Linux.

I don't know much about graphics, but have you looked at wt? Its a free
3d graphics engine that can use svgalib- it gets quite decent performance
out of it (15 fps on my 486-66 if i remember currectly).

You might want to look at it for suggestions... It can be found in
magoo.uwsuper.edu:/pub/wt

Also one thought I just had was the keyboard... Is the application
interactive?  If you are using the normal linux keyboard mode
it will be SLOW. You want to use the raw keyboard routines and
get the scancodes and handle them yourself..

jem.

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

From: ecldco@ultb.isc.rit.edu (E.C. Loyd)
Subject: Re: System lock ups: NCR 53c810 driver problem?
Date: Tue, 5 Jul 1994 18:15:55 GMT

For those that want a Linux 1.1.19 kernel with the NCR drivers patched
in succefully, ftp to tronic.rit.edu, look in /pub.

-- 
Eric C. Loyd                        "I've got a [Roland U-110 preset 2] to prop
Operations Coordinator II           up my mortal remains."
ISC/Data Center Operations                                      -Pink Floyd
Rochester Institute of Technology   Phone:  (716) 475-7320

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

From: ecldco@ultb.isc.rit.edu (E.C. Loyd)
Subject: Re: NCR-Driver Bug with Fdisk
Date: Tue, 5 Jul 1994 18:17:39 GMT

In article <1994Jun30.171838.360@wagner.muc.de> richard@wagner.muc.de (Richard Schmid) writes:
>
>Hi!
>
>The new NCR 53c810-driver is working nice and pretty fast 
>except fdisk which doesn't work properly.
>It works on my IDE-disk and it works with my adaptec but it doesn't 
>with the NCR cotroller.
>

[stuff deleted]

>Richard

Richard:  You're not reading.  :-)  You must specify the cylinders,
sectors per track, and number of heads with fdisk using the x-pert
command menu.  On my Seagate, I have 16 heads, 63 sectors per track,
and 1023 cylinders.  After specifying this, fdisk works just fine.

-- 
Eric C. Loyd                        "I've got a [Roland U-110 preset 2] to prop
Operations Coordinator II           up my mortal remains."
ISC/Data Center Operations                                      -Pink Floyd
Rochester Institute of Technology   Phone:  (716) 475-7320

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

From: roth@ux4.cso.uiuc.edu (Roth Mark Daniel)
Subject: Re: tcsh bug: more information
Date: 5 Jul 1994 19:36:33 GMT

adc@bach.coe.neu.edu (Albert D. Cahalan) writes:

>In article <2vc2jl$21r@glitnir.ifi.uio.no> kjetilho@ifi.uio.no (Kjetil Torgrim Homme) writes:
>   +--- Roth Mark Daniel:
>   | On the flip side, it's trivial to do string pattern matching under
>   | csh, whereas sh uses test for all it's expression evaluation, and is
>   | a bit limited.

>   Nonsense. "test" isn't even a builtin in the original V7 shell, but
>   "case" is. Besides, "expr" is just as good a tool for expression
>   matching. If sh doesn't have good enough data manipulation for your
>   task, write (perhaps just parts of it) in awk or Perl.

>   (Okay, Bourne shell lacks modifiers amd arrays, but you can do a lot
>   of cool tricks with IFS and set :-)

>What about C?  There is a point where you have to give up using shells.

Couldn't have said it better myself!

Whenever you're coding something, you have in mind robustness,
efficiency, configurability, and other sexy features in mind.  But
when the task is either only going to be needed once, or is too trivial
to really think about, these aspects get sacrificed to the quick+dirty
factor.  Shell scripting is the answer here; it is completely
inelegant, but so much easier for some things than coding in C.

But in a case where you have to think pretty hard about how to do
something in a shell script, why would you EVER not code in C?  The
script is no longer the quick+dirty solution, and it *still* has none
of the advantages of REAL code.

In other words: shells are easy for some tasks, and those they should
be used for.  But if you can't do something easily in a shell
script...DON'T.

Just my $0.02.

-- 
   Mark D. Roth <roth@uiuc.edu>     | "Why's the network being so slow?"
GCS d-- p c++ l++ u+ e+(*) m+ s++/- | "Maybe someone sneezed on a router."
  n+(---) h f+ g+ w++@ t++@ r- y?   |             - Mike Blumenthal
  <a href="http://www.cen.uiuc.edu/~mr4342/mark.html">My Home Page</a>

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

From: gthaker@polyphony.sw.stratus.com (Gautam Thaker)
Subject: what is AF_MAX for Linux?
Date: 06 Jul 1994 00:41:38 GMT


AF_MAX is 21 under SUN OS. I can't find this value defined to be
any thing under Linux. What should it be? I have some code that
uses this.

ANy hint welcome.

Gautam

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

From: bjb@shore.net (Beverly J. Brown)
Subject: Re: Dedicated SCSI swap drive?
Date: 5 Jul 1994 22:51:00 -0400
Reply-To: bjb@shore.net

In article <CsCxs5.5LB@pe1chl.ampr.org>, rob@pe1chl.ampr.org (Rob Janssen) wrote:
> In <1994Jul2.192418.1075@light-house.uucp> las@light-house.uucp writes:
> 
> >Scott A. Laird (lair@kimbark.uchicago.edu) wrote:
> >: In article <WAYNE.94Jun30000433@backbone.uucp>,
> >: Wayne Schlitt <wayne@cse.unl.edu> wrote:
> >: >In article <2uqr31$hpm@library.erc.clarkson.edu> komarimf@craft.camp.clarkson.edu (Mark 'Enry' Komarinski) writes:
> >: >> Would I get better performance getting an additional 40-50MB SCSI
> >: >> drive and use that as swap space, or just make a 32MB partition out 
> >: >> of the 1G drive?
> >: >
> >: >
> >: >It is almost always better to have a bunch of small drives vs one
> >: >large drive.  Adding a swap disk isn't a bad idea.  If you get a disk
> >: >that is say 60-80MB, you might want to put /tmp and /usr/tmp on the
> >: >drive too.
> 
> >On my two drive system (IDE), putting the swap on the second (slower) drive
> >didn't help at all. SO i put it back to the 8ms main drive, and now I use
> >the second drive for infrequently accessed files.
> 
> It is not amazing at all that it does not affect IDE systems.
> Remember, the original post was about a SCSI system, which is an entirely
> different thing.
> 
> Remember, on your IDE system the two drives share a single controller
> (on the master drive), so adding drives will not at all increase the
> throughput.  This leaves only the effect of seek locality.
> 
> Rob

Maybe I'm missing something here, but the last time I checked all my SCSI 
drives were connected to the same controller :)


Beverly J. Brown
bjb@shore.net
beverly@datacube.com

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

From: davem@extro.ucc.su.OZ.AU (David Monro)
Subject: Comined atdisk2 and ide performance 2 patch
Date: Wed, 6 Jul 1994 00:14:23 GMT


Ok, announcing: the complete patch to take a stock kernel to a kernel
capable of controlling 4 ide drives, all running with the performance
enhancing multimode patches.

It is available from:
sunsite.unc.edu:/pub/Linux/kernel/patches/diskdrives/atdisk2-ide2.diff.gz
tsx-11.mit.edu:/pub/linux/patches/atdisk2-ide2.diff.gz

This is a combination of V2 of the IDE Performance package from Mark Lord
<mlord@bnr.ca> and the atdisk2 package from Delman Lee
<delman@mipg.upenn.edu>, plus a little bit of judicious hacking from me to
get the ide performance hacks to apply to the hd1.c produced by the atdisk2
package.

Ther result has been running on my machine for a while, in fact since about
two days after IDE V2 was released (late April?). It has yet to cause me
any problems. However, I make no claims that it won't hose your system. In
fact:

 THE ABOVE LISTED AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 FITNESS, IN NO EVENT SHALL THE ABOVE LISTED AUTHORS BE LIABLE FOR
 ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
 RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
 CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
 CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

OK?

The patch was generated with respect to a clean 1.1.23 kernel,
and patches cleanly for 1.1.24. It may not patch cleanly on anything before
1.1.22, but with a couple of tweaks it ought to work back to at least 1.1.9
and possibly right back to 1.0.0.

I suggest you get the atdisk2-0.9.tgz and linux-ideperf.patch packages
from sunsite.unc.edu:/pub/Linux/kernel/patches/diskdrives in order to read
the original readmes. This particularly applies to the atdisk package!

In the above directory you may also find the file atdisk-ideperf.patch.
Ignore this, as it is my merger of the atdisk9 and IDE V1.0 packages. This
supercedes it.

Thanks very much to Mark Lord for the IDE performance package,
and to Delman Lee for the atdisk2 package.

        David Monro

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

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: DosEmu suggestion
Date: 5 Jul 1994 22:06:28 -0300

In article <CsGJoG.2yD@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
>From: rob@pe1chl.ampr.org (Rob Janssen)
>Subject: Re: DosEmu suggestion
>Date: Tue, 5 Jul 1994 08:02:39 GMT

>In <1994Jul4.142703.11656@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:

>>In article <2v6gbk$p7q@solaria.cc.gatech.edu> byron@gemini.cc.gatech.edu (Byron A Jeff) writes:
>>>Well consider this: If Linux and DOSEMU share the same Enet card for TCPIP
>>>then essentially you're putting a network in a single box. Mui confusing
>>>if you have the same IP for both.

>>Much better would be to find the dos interrupt interface to one of the DOS
>>tcp/ip packages, and make that work in DOSEMU as calls to the 'real' kernel
>>TCP/IP linux side.

>I have digged up the "PC/TCP" kernel interface, but it seems like too much
>work to be worth the trouble for me.
>I will probably do some more work on the packet driver interface in DOSEMU
>so that you can at least access all the cards and loopback.  Of course you
>need different IP addresses for all the dosemu's.

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

I know you can see me smiling Rob :-). But at any rate, note that the 
interrupt calls are now pointers to functions as you required (as of pre53_2.
tgz).

Later,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

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

From: rja@dce.vic.gov.au (Russell Alphey)
Crossposted-To: comp.emulators.cbm
Subject: Re: (?) C64 disk drive interface and file system?
Date: 6 Jul 1994 11:00:49 +1000

Greg Alt <galt@asylum.cs.utah.edu> wrote:

>A while back someone mentioned wanting to work on writing a file system
>for a C64 disk drive (and the reverse, making a Linux file server for a
>C64).  I was wondering what became of that, and how much work has been 
>done so far if any.

There is a file system emulator that runs on a PC as a server for a C64,
called 64NET.  I can send you the PD version if you like.  It hasn't been
ported to Linux at this stage, as it's written in BASIC!  When it gets
converted to C, I imagine it will be an easy port to Linux.

>(also, where can I get a C64 emulator for X Windows under Linux?)

x64 is available on the usual ftp sites - this is in the FAQ.

-- 
| You are now the proud recipient of a genuine Ralphey .sig!       |
| Accept no imitations!  Keeper of the comp.emulators.cbm.FAQ!!    |
| R.Alphey@dce.vic.gov.au : Ph. +61-3-651-3057  Fax +61-3-651-4073 |

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


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