Subject: Linux-Development Digest #302
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 13 Oct 94 14:13:12 EDT

Linux-Development Digest #302, Volume #2         Thu, 13 Oct 94 14:13:12 EDT

Contents:
  Re: Term blocks modem, switching to VT and back restores? (Bill C. Riemers)
  Re: Linux SLIP interactive response (Modus Operandi)
  Re: A badly missed feature in gcc (Anselm Lingnau)
  Re: 8-bit colour ANSI and ncurses (Andries Brouwer)
  Re: A badly missed feature in gcc (Ian McCloghrie)
  Re: 3c505 driver ? (Tall Sword)
  WARNING Re: code coverage tool for c (Ralf W. Stephan)
  Linux on a IBM PS/2 (Carlos Irigaray)
  Re: Improving SLIP latency under Linux (Michael Callahan)
  Re: Improving SLIP latency under Linux (Michael Callahan)
  Re: Improving SLIP latency under Linux (Michael Callahan)
  Re: What is the Status of the Adaptec 2940W SCSI-3 support? (Phil Andrew)
  question about the kernel (Dongxiao Yue)
  Re: 8-bit colour ANSI and ncurses (Andries Brouwer)
  Re: LINUX Logical volumes (H. Peter Anvin)
  Re: A badly missed feature in gcc (Tom Wilson)
  Re: A badly missed feature in gcc (Alan Braggins)
  Re: Practical experience with Gravis Ultrasound Max? (Shannon Hendrix)
  Re: 3Com 509 Driver Problems - Any fixes - Help (Stanley Owen Jester)

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

From: [email-masked] (Bill C. Riemers)
Crossposted-To: comp.windows.x.i386unix
Subject: Re: Term blocks modem, switching to VT and back restores?
Date: 11 Oct 1994 16:27:00 GMT
Reply-To: [email-masked]

>>>>> "Rafal" == Rafal Kustra <[email-masked]> writes:

    Rafal> OOps forgot to mention. Using term2.0.1 on both ends.
    Rafal> Rafal

I'm fairly certain this isn't a problem related to term versions.  It
sounds like you have a hardware problem that only manifests itself
when both the modem and the video card are in high gear at the same
time.  You mentioned your attempts to change the jumpers on your 
video card.  Have you attempt to change the jumpers on your serial
port, or switching which com port you connect your modem to?

                               Bill
--
<A HREF="    http://physics.purdue.edu/~bcr/homepage.html                  ">
<EM><ADDRESS>  Bill C. Riemers,  [email-masked]   </ADDRESS></EM></A>
<A HREF="           http://www.physics.purdue.edu/                         ">
<EM>          Department of Physics,   Purdue University            </EM></A>

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

From: [email-masked] (Modus Operandi)
Subject: Re: Linux SLIP interactive response
Date: 12 Oct 1994 15:19:54 -0400

John Richardson ([email-masked]) wrote:
: I finally got Trumpet winsock and installed it with the same SLIP
: parameters that linux uses.  The result:  interactive winsock 
: performance during ftp sessions is just as bad as linux!
: In addition, under the same parameters, linux (stock slackware 2.0.0)
: ftp outperformed windows ws_ftp by about 100 to 200 bytes/sec.
: Of course, this could be due to line noise etc...

: this means two things:

: o we aren't any worse than MS-Windows
: o we may be better than MS-Windows :)

There is currently a patch available on ftp.linux.org.uk (actually, a
replacement dev.c) that should solve some of the current ftp session
problems.

Please download it and try it out if you would like to see an improvement to
interactive performance. (NOTE: THIS IS ALPHA CODE).

Patrick Kane
<[email-masked]>

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

From: Anselm Lingnau <[email-masked]>
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 1994 20:08:36 +0100

In article <[email-masked]>, Bruce Thompson
<[email-masked]> wrote:

> I know of no other language than C++ which has multiple comment syntaxes.

Pascal. Fortran.

Anselm
-- 
Anselm Lingnau ......................... [email-masked]
If man could be crossed with the cat, it would improve man but deteriorate the
cat.                                                             --- Mark Twain

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

From: [email-masked] (Andries Brouwer)
Subject: Re: 8-bit colour ANSI and ncurses
Date: Thu, 13 Oct 1994 12:00:29 GMT

[email-masked] (H. Peter Anvin) writes:

: Followup to:  <[email-masked]>
::  
::  Do you have suggestions for improvement?
::  In a sense I feel that we are bound somewhat by the desire to
::  emulate a VT100, i.e., font changes really are Esc ( * and Esc ) *.
::  A good thing would be to throw out mapscrn and to encode the mapping
::  information in the font, especially now that we have Unicode.
::  But that would make it less trivial to borrow fonts from other sources.
::  

: Yes; I posted a bit about this to the KERNEL channel recently.
: Basically my idea is to split the kernel tables into two set of
: tables: terminal charsets -> Unicode and Unicode -> font.  The latter
: table would be loadable with a font.  This way, a loadable font could
: contain any arbitrary subset of Unicode, and the VT220 emulation modes
: would still work as intended (ISO 8859-x -- there are 10 of them,
: KOI-8, DEC VT graphics, and IBM codepages would all be in
: font-indenpendent tables mapping them to Unicode, after which Unicode
: would be mapped to the font.  The Unicode -> font table would be
: page-mapped since it would in general only by a sparse table.

And the terminal charsets -> Unicode would still be indicated by
Esc ( X.  Yes, sounds like that would work.  I hope to make that
change tonight.

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

From: [email-masked] (Ian McCloghrie)
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 1994 12:56:57 -0700

[email-masked] (Jeff Kesselman) writes:

>Very true, he said, quickly jotting notes for the next inevitble 
>super-set argument.

Even more fun is the difference between NULL.  Used to be, in K&R,
that NULL was defined as "0".  In ANSI, it's defined as "(void *) 0".
In C++, it's back to being "0", because "(void *) 0" can't be
automatically converted to another type in an assignment,
and thus "int *foo = NULL;" won't work with ANSI NULL, you need
"int *foo = (int *) NULL;".  Which, I think you'll agree, is ugly :)

--
Ian McCloghrie    work: [email-masked]     home: [email-masked]
  ____   GCS d-- H s+:+ !g p? au a- w+ v- C++$ UL++++ US++$ P+>++
  \bi/   L+++ 3 E+ N++ K--- W--- M-- V-- -po+ Y+ t+ 5+++ jx R G'''
   \/    tv- b+++ D- B-- e- u* h- f+ r n- y*

The above represents my personal opinions and not necessarily those
of my employer, Qualcomm Inc.

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

From: [email-masked] (Tall Sword)
Subject: Re: 3c505 driver ?
Date: Thu, 13 Oct 1994 11:04:04 GMT

Zheng Huang ([email-masked]) wrote:
: Hi,

: I tried to config my linux(slakware 2.0) to work with my 3c505 network card,
: but I can't find the 3c505.c file in linux src directory under drivers.
: For some reason, the 3c505 is been commented out from the config file. Could
: someone tell me how I can make 3c505 work with linux.
Try get the update kernel and compile again. For me, I am running 1.1.53 and
the 3c503 works fine on my system.

--
* Origin: TallSword, Computer Science Year 2, HKUST
      internet: [email-masked], [email-masked]
                [email-masked], [email-masked]
                [email-masked]
      fidonet:  Raymond Ko, 6:700/[email-masked]

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

From: [email-masked] (Ralf W. Stephan)
Subject: WARNING Re: code coverage tool for c
Date: Sun, 9 Oct 1994 14:26:29 GMT

Bob Horgan writes:
> The code coverage tool, ATAC, is available via ftp from Bellcore.

Warning.  This package, when installed, creates a script that
sends mail about installation and usage (this every 30 days)
on your system to bellcore.com.  It doesn't tell you.

If you don't want this, remove the file 'loguse' after
installation or don't install atac at all.

ralf
--
## CrashJoint v9.99 ##
You are in a different little article, all maze.

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

From: [email-masked] (Carlos Irigaray)
Subject: Linux on a IBM PS/2
Date: 9 Oct 1994 20:14:58 -0400

Hi, does anyone know how to create a "boot disk" and a "root disk" as in 
the Slackware distribution?
I'm using Slackware 2.0.1 and my runnning kernel is 1.1.52 (I've compiled 
it). What I need is to make those diskettes from my system because then I 
should be able to have my IBM PS/2 booting. (the new kernel support the 
MCA architecture!)

Thanks for the help!

 ____________________________________________________________
|                                                            |
| Carlos Irigaray - [email-masked] - [email-masked] |
|                                                            |
|____________________________________________________________|

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

From: [email-masked] (Michael Callahan)
Subject: Re: Improving SLIP latency under Linux
Date: Thu, 13 Oct 94 13:37:28 BST

In article <[email-masked]>,
Al Longyear <[email-masked]> wrote:
>[email-masked] (Eric J. Schwertfeger) replies to someone:
>>: Actually, I guess there is one thing you could do.  You could set
>>: things up so that if an interactive packet gets queued while a bulk
>>: packet is in the middle of transmission, you immediately interrupt
>>: the bulk packet (by sending an end-of-frame character and relying
>>: on the remote end to discard the incomplete frame) and start the
>>: interactive one instead.  Ugly, and I don't recommend it for SLIP
>>: (which has no link error detection).  It would improve latency
>>: somewhat.

Actually, I wrote that.

Michael
---
Michael Callahan
[email-masked]

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

From: [email-masked] (Michael Callahan)
Subject: Re: Improving SLIP latency under Linux
Date: Thu, 13 Oct 94 13:46:27 BST

In article <[email-masked]>, Rob Janssen <[email-masked]> wrote:
>According to Al Longyear:
>> For this to work the best, you need to implement IP_TOS on both sides
>> of the link. If you are doing an ftp transfer to read a large file,
>> then it the remote side (the one running ftpd) which is doing the
>> majority of the transmission. Their frames need to have a background
>> (7) priority.
>
>Note in my application Linux on one side is used only as a router.
>I cannot change the ftpd.  So, if it does not use another than the default
>TOS, I will not have this advantage when using TOS based queueing.

OK, if you really can't get the remote end to do TOS correctly,
and you want to do the TCP-port-number hack, put an appropriate
hook in the ip_forward routine in net/inet/ip.c just before it 
examines the TOS field to decide what queue to use.

Michael
---
Michael Callahan
[email-masked]

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

From: [email-masked] (Michael Callahan)
Subject: Re: Improving SLIP latency under Linux
Date: Thu, 13 Oct 94 13:53:01 BST

In article <[email-masked]>,
John Richardson <[email-masked]> wrote:
>In article <[email-masked]>,
>Matthias Urlichs <[email-masked]> wrote:
>>The reasonable thing to do here is to increase the baud rate you use when
>>talking to the modem. Remember that with error-corecting modems, every data
>>packet (which has no relation to the IP packets it carries) has to arrive
>>completely before being forwarded because the checksum must be verified,
>>and on a serial line there's no "Oops, discard the last fifteen characters"
>>command.
>
>Increase the baud rate?  Huh? How?  It is already at spd_hi.  With
>round trip times of 2000 to 3000ms I don't think I'm just waiting for
>30 characters...  I don't know if you realize this, this thread
>was started by someone complaining about the abnormal interactive 
>responce times /during background ftp transfers/.  If you use
>SLIP or PPP can you say that you don't get 2-3 sec delays (you
>can modify ping to get this) for interactive traffic.

Actually, what you would really like is to have a SLOW baud rate
for transmitting to the modem, and a FAST baud rate for receiving
from it.  The problem with having a FAST baud rate for transmitting
to the modem is that the Linux host can fill up the modem's 
transmit buffer rapidly, at which point the modem has a couple
seconds of data to send, so _no matter what the Linux host does_,
a new interactive packet will have to wait a couple of seconds
for delivery.

If instead you transmit to the modem more slowly, you'll never fill
up the transmit buffer (much).

On the other hand, you lose bandwidth, obviously.

I wouldn't be surprised if a 9600 baud connection to a 14.4
modem session gave the best latency results for interactive
traffic with simultaneous bulk traffic.  On the other hand,
it's slow.

Michael
---
Michael Callahan
[email-masked]

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

From: [email-masked] (Phil Andrew)
Crossposted-To: comp.os.linux.help
Subject: Re: What is the Status of the Adaptec 2940W SCSI-3 support?
Date: 13 Oct 1994 14:34:41 +0100

In article <[email-masked]>,
        [email-masked] writes:
>In comp.os.linux.development, Wigs ([email-masked]) wrote:
>
>> Could the people in the know please forward any information they have on
>> this.
>
>-> Projects-Map on sunsite.
>

Well, since Adaptec will not even release details of the lowly 2940, I do
not think they will be too pleased about doing so for the 2940w.

I really do not think that there is a lot of demand for support at the
moment.

However, if I am wrong on this, and anyone has written a driver for either
card, I would be most grateful to know about it,

Phil Andrew

>-- 
>Zounds!  I was never so bethumped with words
>since I first called my brother's father dad.
>               -- William Shakespeare, "King John"
>-- 
>Harald Milz ([email-masked])      WWW: http://www.ix.de/editors/hm.html
>iX Multiuser Multitasking Magazine     phone +49 (511) 53 52-377
>Helstorfer Str. 7, D-30625 Hannover    fax   +49 (511) 53 52-378
>Opinions stated herein are my own, not necessarily my employer's.

+--------------+-------------+----------------------+----------------------+
|Philip Andrew | Warwick Uni.| Dept. of Engineering | [email-masked]  |
+--------------+-------+-----+----------------------+----------------------+
|                   http://www.csv.warwick.ac.uk/~esveg/                   |
+--------------------------------------------------------------------------+
|   *********  P       |    W W W   AAA   RRRR   W W W  III   CCCC  K   K  |
|    *     *    R      |    W W W  A   A  R   R  W W W   I   C      K  K   |
|     *   *      I     |    W W W  AAAAA  RRRR   W W W   I   C      KKK    |
|      * *        D    |    W W W  A   A  R  R   W W W   I   C      K  K   |
|       *          E   |     WWW   A   A  R   R   WWW   III   CCCC  K   K  |
+----------------------+---------------------------------------------------+
|        First respect yourself. Respect for others will then follow.      |
+--------------------------------------------------------------------------+

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

Crossposted-To: comp.unix.internals,comp.os.linux.help
From: [email-masked] (Dongxiao Yue)
Subject: question about the kernel
Date: Thu, 13 Oct 1994 14:35:14 GMT

Hello, folks,

I am reading the Linux kernel source code, and have some difficulty
understanding one crucial point. Usually before the a process try
to manipulate some global data structures ( like the free buffer list),
it will disallow interrupts in some critical section. But as I read the 
source for linux, I can not find where this is done, for example
in file buffer.c there is a inline function  put_last_free() which
alters a linked list, but there is no code to protect the critical
 section there. getblk() calls put_last_free(), but I can not found the
protection code in it either. 

Can someone tell me how and where the critical sections are protected?
I have spent quite some time to trace back and forth the calling
sequences and found nothing(btw, is there a program that can serach the
calling sequence?).  I would greatly appreciate your help. 

Dongxiao

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

From: [email-masked] (Andries Brouwer)
Subject: Re: 8-bit colour ANSI and ncurses
Date: Thu, 13 Oct 1994 13:51:45 GMT

[email-masked] (Rasmus Lerdorf) writes:

: I looked through the console driver source and noticed that 
: <ESC>]11m  does what I want.  ie. show the chars for ascii codes
: < 32 and also switches to the first alternate character set.  
: From within ncurses it appears as though attrset(A_ALTCHARSET)
: does the trick.  <ESC> ] 11m  along with 10, 12, 21,22,24 and 27
: are mode codes I haven't seen before.  They are not in the
: ANSI spec, and they don't look like VT100 sequences to me.

No, slowly there are coming more and more non-VT100 features
in the console driver. I don't know who wrote that code.
ISO 6429 (ECMA 48) says about <ESC> ] N m:
N=10: primary font
N=11: first alternative font
N=12: second alternative font
N=21: doubly underlined (but here the Linux source identifies
        N=21 with N=22, must be a bug)
N=22: normal colour/intensity
N=24: not underlined
N=25: not blinking
N=27: positive image
N=38: reserved for setting character foreground color
N=39: default display color (the change in underline here seems a bug)
N=49: default background color

That N=10,11,12 do sth with disp_ctrl and toggle_meta seems
unjustified by any standard I know of. Anybody care to comment?

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: LINUX Logical volumes
Reply-To: [email-masked] (H. Peter Anvin)
Date: Thu, 13 Oct 1994 14:41:03 GMT

Followup to:  <[email-masked]>
By author:    [email-masked] (Werner Almesberger)
In newsgroup: comp.os.linux.development
> 
> Also, 3) requires some good understanding of failure patterns. Since
> nowadays, the electronic parts of a disk drive tend to be more likely
> to fail that the mechanic parts, you also have to be concerned about
> disk controller or (very common !) bus problems. Of course, an easy
> but probably adequate solution to the latter would be to declare them
> as something that's beyond the scope of such a concept. Let's also
> not talk about drive firmware bugs (and yes, you see more of those in
> large, less common setups).
> 

... which they pretty much are, since they don't cause data loss per
se, just temporary inaccessibility.  Personally, I feel that if you
want RAID, get a hardware implementation of RAID, since those tend to
be incredible much better (they can do spindle synchronization etc)
anyway.

        /hpa
-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
ld error:  wallet.c:  _money not found

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

From: [email-masked] (Tom Wilson)
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 1994 23:13:00 -0400

In article <[email-masked]>,
Bruce Thompson <[email-masked]> wrote:
:H. Peter Anvin ([email-masked]) wrote:
:: Followup to:  <[email-masked]>
:: By author:    [email-masked] (Jeff Kesselman)
:: In newsgroup: comp.os.linux.development
:
[CHOMP}
:
:As a postscript, I find the notion of supporting multiple comment
:syntaxes as unusual in the extreme. I know of no other language than
:C++ which has multiple comment syntaxes. I have yet to encounter a

Well, (URP!) VMS Pascal supports both (* *) and { } .....for what
*that* piece of silly trivia is worth...

At any rate, breaking strict ANSI compliance to follow Mickeysoft
(I believe they did it first.. // , that is) just ain't worth it
IMNSHO...

-- 
/-----------------------------------------------------------------------\
|  Tom Wilson                      |  "I can't complain, but sometimes  |
|  [email-masked]       |   I still do."                     |
|                                  |                -Joe Walsh          |

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

From: [email-masked] (Alan Braggins)
Subject: Re: A badly missed feature in gcc
Date: Tue, 11 Oct 1994 10:30:03 GMT

In article <[email-masked]> [email-masked] (Jeff Kesselman) writes:
   >This would break perfectly correct C code, like
   >
   >    a = b//* Comment here */ c;
   >--

   And this is the cannonical case of why c++ is NOT a true super-set of 
   ANSI c.  (Thanks, I'm going to save the exampel for the next time I have 
   THAT argument.)

That "int function();" declares a function with no arguments in C++
and an unknown number of arguments in C is far more common.
So are variables called "class" or other new reserved words.
--
Alan Braggins  [email-masked]  [email-masked]
"Any technology distinguishable from magic is insufficiently advanced"

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

From: [email-masked] (Shannon Hendrix)
Subject: Re: Practical experience with Gravis Ultrasound Max?
Date: Tue, 11 Oct 1994 01:03:06 GMT

[email-masked] (Jon Lasser)  writes:

>Does anyone have practical experience with the Gravis Ultrasound Max
>under Linux?

>I have three primary questions:
>(1) Does the CD-ROM interface for the Panasonic drive work
>properly under Linux (I have a Panasonic 563b drive, which currently
>runs with my Sound Blaster 16).

>(2) Are there any general incompatibilities between the board
>and Linux? Any specific known problems?

>(3) I'm currently using a Sound Blaster 16. IsGravis
>Ultrasound Max considered an upgrade from the Sound Blaster? I mean, I
>know that the digital audio is about the same, but is the WaveTable that
                       ^^^^^^^^^^^^^^^^^^^^^^^
Hardly.  The SB has one or two channels.  The Gravis has 32 digital
channels.

>much better?

Far better.

>Frankly, I'm lusting over the board, but I want to make sure that it
>works before I buy it, because I don't know enough to hack the kernel.
>(yet).

What I'm most interested in knowing is what happened to the Ultrasound
Max *UPGRADE* for the original Gravis Ultrasound.  I am happy with the
Ultrasound (has everything the Max has except no 16-bit recording, CD-ROM
interfaces, and a couple of other things).  All I see in the stores is
this $200 thing and that, IMHO, is a ripoff as an upgrade which barely
adds anything to my current board.

However, if there is an upgrade board that is much lower than $200
then OK.

>Replies by e-mail are appreciated, although I do try to keep up with
>this group.

>Thanks in advance,
>Jon Lasser

-- 
csh
===========================================================================
[email-masked]      | Linux... that's it for the moment
===================================+ 

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

From: [email-masked] (Stanley Owen Jester)
Crossposted-To: comp.os.linux.help
Subject: Re: 3Com 509 Driver Problems - Any fixes - Help
Date: 13 Oct 1994 10:37:32 -0500

Will  a 3c501 card work with Linux sllackware 2?
I know it is old, but it is for home, so I won't need much horsepower.

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

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