Subject: Linux-Development Digest #138
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 8 Sep 94 10:13:08 EDT

Linux-Development Digest #138, Volume #2          Thu, 8 Sep 94 10:13:08 EDT

Contents:
  Re: Non-ANSI constructs in the kernel (was Re: Unicode...) (Yonik Seeley)
  PS/2 ESDI and Token Ring patches available for anonymous ftp (Peter De Schrijver)
  Re: Non-ANSI constructs in the kernel (was Re: Unicode...) (Harald T. Alvestrand)
  Re: Future of linux -- the sequel (Kjetil Torgrim Homme)
  SyQuest removable SCSI driver? (Aaron Turner)
  Diamond Stealth 64 graphics accelerator (Matti Hallivuori)
  Why I cannot mount a PhotoCD on Mitsumi ? (Tamas Badics)
  Strange net behaviour, any hints ? (Dr. Ernst-Dieter Klinkenberg)
  Re: Digi Intelligent Boards? (Alan Cox)
  Re: Multiprocessing Pentium Systems (Rajesh Raj)
  Re: News Spool File System - new filesystem type?? (Lennart Regebro)
  Re: DOSEMU 0.53 notes (Rob Janssen)
  Re: Bug in c-lib (ftell) ? (Rob Janssen)
  Re: cat /proc/interrupts doesn't show printer ints. (Rob Janssen)
  Re: Alpha Linux (Steven Youngs)

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

From: [email-masked] (Yonik Seeley)
Subject: Re: Non-ANSI constructs in the kernel (was Re: Unicode...)
Date: 7 Sep 1994 18:26:03 GMT

In article <[email-masked]>,
Richard L. Goerwitz <[email-masked]> wrote:

[ stuff deleted ]

>****************************  quoted material ******************************
>
>If you write a program which supports international use, you should
>use the available standardized functions, as only these will be
>influenced by the setlocale call. Thus, if you want to convert a
>capital letter in c to a lower case letter in l, _don't_ write:
>
>l = c - 'A' + 'a';
>
>While this will work for characters in the US-ASCII character set, it
>will not work with German, French, or Spanish characters. The
>following, standard-conformant code will:
>
>#include <ctype.h>
>
>....
>
>l = tolower(c);
>
>Also note that the second code is FASTER (for most implementations),
>as it replaces arithmetic by a simple table lookup!

I highly doubt that it is faster in any implementation.  The 'A'+'a' will be 
performed at compile time, so you get one subtraction (or addition).
A table lookup would involve an addition and a dereference.

- Yonik Seeley
  [email-masked]

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

Date: Wed, 7 Sep 1994 20:32:25 +0200
From: [email-masked] (Peter De Schrijver)
Subject: PS/2 ESDI and Token Ring patches available for anonymous ftp

Hi,

I have put my second alpha version of the Token Ring driver and the PS/2
ESDI driver for anonymouts ftp at aix13ps2.cc.kuleuven.ac.be in pub/Linux.
There 4 files :

PS2-ESDI.patch.1.1.49.gz  patches for Linux 1.1.49 for PS/2 ESDI drives. This
                          driver doesn't seem to work on a PS/2 Model 80. I
                          don't know why yet. I am using it on Model 70.

vmlinuz.PS2-ESDI          Bootable kernel image of 1.1.49 with the ESDI driver.

TokenRing.patch-1.1.49.gz patches for Linux 1.1.49 for IBM token ring adapters.
                          This driver works on most IBM ISA and MCA token ring
                          adapters that use shared memory.

vmlinuz.TokenRing         Bootable kernel image of 1.1.49 with the TR driver.

If there is interest I can put my kernel source tree as well.

Peter.

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

From: [email-masked] (Harald T. Alvestrand)
Subject: Re: Non-ANSI constructs in the kernel (was Re: Unicode...)
Date: 8 Sep 1994 07:37:14 GMT

The HPFS code is admissible if HPFS has its own builtin assumptions
about what character sets stuff is stored in. Indeed, it would *have*
to be coded that way if the HPFS charset was in any way different from
the one Linux is "natively" using.

The toupper() and tolower() macros are IMHO broken.
Here is what SUN did to bail out of a similar speed vs correctness problem
(from the Sun 4.1 ctype(3V) man page):

  Character Conversion Macros
     The macros _toupper() and _tolower()  are  faster  than  the
     equivalent functions (toupper() and tolower()) but only work
     properly on a restricted range of characters, and  will  not
     work  on  a  LC_CTYPE  category  other  than the default "C"
     (ASCII).

The isupper() macro is, for instance,

#define isupper(c)      ((_ctype_+1)[c]&_U)

I have my doubts that this will work for a variable-length encoding
like UTF-8.

Also, table lookups are NOT The Solution; the uppercase equivalent
of the ß (German double-s character) is SS (two letters), and it is
not possible to write code that guarantees that tolower(toupper(c)) is
the same thing in such a context.
Not all languages *have* the upper/lower distinction, either.

Internationalization is *hard* - but defining the tolower() and toupper()
stuff as functions rather than macros is a beginning. Then I can at least
relink them instead of having to recompile the programs every time the
world gets a little bit better.

Keep up the good work!
-- 
                   Harald Tveit Alvestrand
                [email-masked]
      G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
                      +47 73 59 70 94
My son's name is Torbjørn. The letter between "j" and "r" is o with a slash.

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

From: [email-masked] (Kjetil Torgrim Homme)
Subject: Re: Future of linux -- the sequel
Date: 7 Sep 1994 19:26:04 GMT

+--- Rob Peich:
| The Indy is mentioned several times, like in
| 
|       "Indy: an Indigo without the 'go'"
| 
| It also repeatedly states that an Indy is unusable with 16M RAM.  As the
| proposed configuration for the Indy earlier in this thread included 32M RAM,
| I suppose this is still more or less the case...

"Suppose" is the key word here. An Indy with 16MB RAM running IRIX 5.2
performs roughly the same as a Linux box if you just use twm, emacs
and a couple of xterms on either machine.

However, people using an Indy will generally want to take advantage of
the Indigo Magic desktop, and with Insight/MediaMail/CodeVision/Mosaic
etc. running, you'll soon want to upgrade to 32 MB.

BTW, the entry level Indy used to be the Indy 4400PC, and the 4400's
performance without a secondary cache is pretty poor. It's still at
least as fast as a DX66.

+---
| Disclaimer: I have no Indy and I have seen them only in a demo setup.

I have used Indy PC with 16MB running IRIX 5.1 and 5.2. The difference
is phenomenal. (Of course we have more powered machines as well.) I've
also tried using a 486/66 with 16MB running 1.0.9+cluster+ide+lx10
interactively while one person remote logged ran a heavy compilation.
It was intolerable, swapping performance really sucked (it was
swapping to IDE, probably a bad idea). We've upgraded it to 32MB now,
and things run a lot smoother.

Kjetil T.

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

From: [email-masked] (Aaron Turner)
Subject: SyQuest removable SCSI driver?
Date: Thu, 8 Sep 1994 01:26:35 GMT

Hi all,
I have a SyQuest 3720S (270MB SCSI removeable HD) running off a SB16 
SCSI-2.  I was wondering if someone has written a driver for it like the 
one SyQuest provides for DOS that allows automatic recognition of a new 
cartridge when I swap cartridges.  (without the driver you can't swap 
cartridges without rebooting.)  Is there one for Linux?  If not could one 
be written?  If so could someone point me the way?  I can get any spec I 
might need about the drive (how it reports swapping, etc.) since I work 
at SyQuest.  Or would someone be willing to write it?  I'm very new to 
Linux and have a little programming background, but nothing like this.  I 
could get you anything you might need- I might even be able to con one of 
my friends who programmed the DOS version to give you some info.  BTW, 
yes, I do know that I can just umount & then mount the new cartridge, but 
since I swap cartridges so much this is becoming a pain.  TIA for anyone 
who can give me some insight!
   
Aaron Turner             *****************************************************
aka: [email-masked]  * --Hanlon's Razor:  Never attribute to malice that *
[email-masked] * which is adequately explained by stupidity. *
finger for more info & PGP   *********************************************

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

From: [email-masked] (Matti Hallivuori)
Subject: Diamond Stealth 64 graphics accelerator
Date: 08 Sep 1994 10:11:14 GMT

Is it possible to use Stealth 64 graphics card with Linux and X11 and if so
what are the restrictions (my slackware distribution says no Diamond
cards are supported!)

The card has Vision 86C964-p S3 chip. 

Thanks
Matti Hallivuori

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

From: [email-masked] (Tamas Badics)
Crossposted-To: comp.os.linux.help
Subject: Why I cannot mount a PhotoCD on Mitsumi ?
Date: 7 Sep 1994 15:32:43 -0400

Hi Again,

I asked the above question once, but had no positive answer. 
The problem is the following:

I'd like to mount a PhotoCD using Linux 1.0.9 and a Mitsumi doublespeed 
CD drive. I guess the "mount -t iso9660 /dev/mcd /cdrom" command should
do it, but it doesnt. It gives the usual 
"mount: wrong fs type, /dev/mcd already mounted, /cdrom busy, or other error"
error message.

Is the PhotoCD compatibility missing from the mcd.c driver? 

I CAN mount regular data CD-s on the same drive with the same command.
Also, the same drive CAN read PhotoCD-s under MS-DOS, so it is not a hardware
problem.

Anoybody knows the solution to this?

Thanks,
        Tamas

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

From: [email-masked] (Dr. Ernst-Dieter Klinkenberg)
Subject: Strange net behaviour, any hints ?
Date: 8 Sep 1994 08:51:43 GMT

While the the network behind our gateway was physically under repair it was
in our inhouse net impossible to telnet to a linux-box. I got a connect, but
no login. This was anoying me because this didn't happend to our
HP-workstation and not to a FreeBSD-box, which my colleague favours.

The normal behaviour restored after the repair.

Is this bug ?

Greetings

Dieter

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

From: [email-masked] (Alan Cox)
Subject: Re: Digi Intelligent Boards?
Date: Thu, 8 Sep 1994 09:33:53 GMT

In article <[email-masked]> [email-masked] (Simon Park) writes:
>AFAIK there are no Linux drivers available for any of the
>intelligent serial cards. But there projects in hand working on
>drivers for the Digiboard COM/Xi and PC/Xe cards.

Cyclades driver is out and about. I'm still trying to beat some sense
into someone about letting me do an ISDN driver for one of the nicer
UK isdn cards...

Alan

-- 
  ..-----------,,----------------------------,,----------------------------,,
 // Alan Cox  //  [email-masked]   //  GW4PTS@GB7SWN.#45.GBR.EU  //
 ``----------'`----------------------------'`----------------------------''

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

From: Rajesh Raj <rxr401@huxley>
Subject: Re: Multiprocessing Pentium Systems
Date: Thu, 8 Sep 1994 08:16:41 +1000 (EST)

On Tue, 6 Sep 1994, David Williams wrote:

> 
> I've just seen some new dual processor pentium systems in Computer
> Shopper.  They look swell for the money, but there isn't a single OS
> that can take advantage of them.                           ^^^^^^^^^  
 
I have seen OS/2 SMP running on many dual Pentium processors. In fact, it 
can run on a system upto 16 processors. The system (two pentium 
processors) I tried didn't seem to be faster than a single processor 
system, but it would maintain its speed while multi-tasking. A feature of 
OS/2 that I like most is multithreading.

As for Linux, I would rather like to see it to be ported to PowerPC.

Raj

[email-masked]

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

From: [email-masked] (Lennart Regebro)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 8 Sep 1994 15:00:04 -0000
Reply-To: [email-masked]

In <[email-masked]> [email-masked] (Rob Robertson) writes:

>I don't think this would work, as so many words in usenet postings are
>misspelled that looking them up in a dictionary, probably won't buy
>you anything, cuz they won't be found!
>              ^
>               c whut i meen?

The very common words 'Newsgroups:', 'Subject:', 'References:', 'alt.sex'
and 'cuz' would still be common enough to be in a common directory.

-- 
Lennart Regebro                    [email-masked] (Try this first)
Galactic Guide Field Researcher    [email-masked] (Spare address)

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

From: [email-masked] (Rob Janssen)
Subject: Re: DOSEMU 0.53 notes
Reply-To: [email-masked]
Date: Wed, 7 Sep 1994 16:24:05 GMT

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

>Rob Janssen ([email-masked]) wrote:
>: In <[email-masked]> [email-masked] (Mark Krischer) writes:

>: what patchlevel?
>I am using 1.1.42 dosemu0.53pre17

That sounds reasonable...

>: I don't think so.  Only ET4000, S3, trident for now.
>I to wish they supported ATI.  I have one (weird card) and DOSEMu stops
>when I try to use the graphics mode.  Do I need to make a copy of the 
>BIOS for the video card?  Any strange thing to get graphics mode.  Character
>mode works great.  The old DOSEMu 52 worked with the ATI.  Cursor looked 
>funny but it worked.  

There is definately some problem with the video card access, I have
a system at work that crashes when I start DOSEMU with direct video access.
And it worked before (I think that was with 0.49)

However, as I don't want to solve it myself, I don't complain...

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: Bug in c-lib (ftell) ?
Reply-To: [email-masked]
Date: Wed, 7 Sep 1994 16:35:57 GMT

In <[email-masked]> [email-masked] (root) writes:

>Hi,
>I recently upgraded my system from libc 4.5.21 to libc 4.5.24. Some of my 
>programs which are running without any problem with 4.5.21 and on a lot 
>of other machines (Unix and  aah Dos) don't run any more.
>I tracked it down to a call of ftell. After running in that problem I upgraded
>to libc 4.5.26 in the hope of, well ya know.
>But the same. I attached an example program where I isolated the interesting 
>parts.
>I compiled it on our Ultrix, Sun and messy dos and on every system I got the
>same results for first size and second size as I assumed. Only on my linux 
>box I got different sizes. It turned out that ftell seems to reset the 
>filepointer of the filehandle to zero. And so beneath the wrong fileposition,
>the formerly written data gets overwritten.
>Any clues?

You should not intermix FILE operations with operations using fd's.
Use fwrite() instead of write() and all will be OK.

POSIX.1 describes a few special cases that are allowed, but in general
the behaviour of programs like you have written is undefined.  That it
works on some systems does not mean that it is an error when it does
not work on Linux.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: cat /proc/interrupts doesn't show printer ints.
Reply-To: [email-masked]
Date: Wed, 7 Sep 1994 16:44:11 GMT

In <[email-masked]> [email-masked] (David Hinds) writes:

>Glenn Moloney ([email-masked]) wrote:

>: Some drivers only request interrupts when they are opened, and release
>: them when closed. An example is the floppy driver, which uses interrupt
>: 6, but only requests the interrupt (request_irq()), while a floppy is
>: open. Hence IRQ 6 does not appear in /proc/interrupts (except whil
>: accessing the floppy). I have not
>: checked if this is the case with the lp driver.

>: This is a good thing, in that it allows different
>: devices to use the same interrupts (if used at different times).
>: However, it reduces the usefulness of the /proc/interrupts file.

>: There may be some usefulness in device drivers registering with the
>: kernel what resources (irq,dma,port addresses,shared memory) the
>: software and hardware use. This useful system config information could
>: then be made available in the /proc filesystem. I have several cards and
>: device drivers installed on my system, and it would be nice to find a
>: /proc entry to find free irqs, dma channels and port adresses for
>: instaling new cards on the system. It would make managing many Linux
>: boxes in a laboratory type situation a lot easier (particularly if you
>: have device drivers which auto detect the hardware, but don't
>: permanently grab the IRQ).

>I agree that this would be a good thing.  Sharing interrupts is a good
>thing, but if you've got interrupts to spare, it is better to avoid
>it, since it prevents simultaneous use of the sharing devices.

>One option would be to have a mechanism for "reserving" resources like
>ports and interrupts.  Other drivers could still allocate a reserved
>resource, but a driver for a device with programmable interrupts could
>try to find a line that isn't reserved.

Yes, it may also permanently solve an erratic problem that I have seen
(and someone else has reported it as well...):

Since the time the FLOPPY driver no longer permanently grabs the IRQ #6,
it has happened that the ethernet driver (for my NE2000) sometimes
misdetects the IRQ of that card as #6.  The card is jumper-configured,
so when this happens both my floppy and the network fail to operate.

I have been able to fix this by playing with a delay in the ethernet
driver, but I feel it is generally unreliable now.

What would be nice, is to have all the "autodetect" code moved to a common
place (other drivers use autodetect as well, each with their own code)
and then add some mechanisms to somehow protect certain interrupts
according to parameters passed to this autodetect function.

like: "I am going to autodetect an interrupt that I will permanently
grab afterwards, so don't return an interrupt that has been claimed
by another driver on a temporary basis".

It looks like one would like to be able to categorize IRQ's into classes
like "unallocated", "permanently allocated", "claimed for temporary use"
and maybe others.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Steven Youngs)
Subject: Re: Alpha Linux
Date: Wed, 7 Sep 1994 15:21:29 GMT

In article <[email-masked]>, [email-masked] (Peter Holzer) writes:
|>Path: ncgrafix.demon.co.uk!betanews.demon.net!demon!news.sprintlink.net!uunet!news.tuwien.ac.at!hp
|>From: [email-masked] (Peter Holzer)
|>Newsgroups: comp.os.linux.development
|>Subject: Re: Alpha Linux
|>Date: Tue, 6 Sep 94 16:40:03 BST
|>Organization: University of Technology, Vienna, Dept. for Realtime Systems, AUSTRIA
|>Lines: 25
|>Message-ID: <[email-masked]>
|>References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
|>NNTPPostingHost: quasi.vmars.tuwien.ac.at
|>XNewsreader: NN version 6.5.0 #7 (NOV)
|>
|>[email-masked] (Anton Ertl) writes:
|>
|>>In article <[email-masked]>, [email-masked] (Douglas Ambrisko) writes:
|>>|> The biggest task with the
|>>|> Alpha is making everything 64 bit clean and this will apply to the EISA
|>>|> drivers.
|>
|>>Only if Linux on the Alpha will be a 64bitOS. 
|>
|>I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|>
|>>If it will be, I hope
|>>that they do not repeat the OSF/1 idiocy of having only 32bit ints.
|>
|>Then you have to drop either the 16 bit or the 32 bit int type. Both
|>options may make some people unhappy. The 32 bit int is a reasonable
|>compromise. It also breaks all those programs which assume that a
|>pointer and an int are just the same thing, which is a good thing IMHO.
|>

The other option of course is to to provide a compiler flag which forces the
code to be loaded into the low 32 bits of memory, and then your program will
not break (generally !!). I personally do not like this idea but the DEC 
C compiler for OSF/1 has such a flag and I know of projects where this falg has
saved a tremendous amount of reworking of existing code.

           ___  ___                                                        
      |\  |    |                                     Steve youngs          
      | \ |\   \   |                                 N.C. Graphics,        
      |  \| \__ \__|                                 Waterbeach, Cambridge 
  N.C. Graphics (Cambridge) Ltd.   Tel:(0223) 861539 UK, CB5 9NN           

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

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