Subject: Linux-Activists Digest #90
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 21 Apr 92 17:00:15 EDT

Linux-Activists Digest #90, Volume #2            Tue, 21 Apr 92 17:00:15 EDT

Contents:
  ALT key under GNU Emacs ([email-masked])
  Re: expr (GNU shellutils), gcc 2,1 and libc.a (Mika Pekka Liljeberg)
  ash shell script parameter bug (Jaakko Hyvatti)
  Re: init, respawn (Peter Orbaek)
  Information on linux ? (Anthony Murdoch)
  Re: Question about svga preset patch (Dennis Flaherty)
  Re: Oddities with MCC Release (0134)
  Re: 0.95c+ console and gcc 2.1 problem. (Scott Silverstein MD)
  Re: If not SCSI, why not floppy? (Scott Silverstein MD)
  Re: generic scsi support in OS/2 (Timothy F. Sipples)
  Re: A new game port, and mtools problems... (Timothy L. Nali)
  Re: problems booting (Michel Eyckmans (MCE))
  Re: IDE drive performance with linux (Kees J. Bot)
  Where can I get pfdisk-0.92? (n.h.chandler)
  Thread (Philippe Backouche)
  SCSI Adaptec 1522 (M. Saggaf)
  Re: GCC2.1 (Wonderful !) (Kevin Cummings)

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

From: [email-masked]
Crossposted-To: alt.os.linux
Subject: ALT key under GNU Emacs
Date: 21 Apr 92 10:28:25 GMT

Dear all,

before I radically rearrange my hard-drive to fit the GNU Emacs sources :-)
Has anyone out already got GNU Emacs to work properly with the ALT key
so that ALT-<key> produce M-<key> just as if ESC <key> had been typed?

        Andrew

        Andrew Stevens                  
      Programmming Research Group       JANET: [email-masked]
     11 Keble Road, Oxford, England     UUCP:  ...!uunet!mcvax!ukc!ox-prg!as
     OX1 3QD   +44 0865 272563

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

From: [email-masked] (Mika Pekka Liljeberg)
Subject: Re: expr (GNU shellutils), gcc 2,1 and libc.a
Date: 21 Apr 92 09:20:48 GMT

In article <[email-masked]> [email-masked] (Hongjiu Lu -- Graduate Student) wrote:
> BTW, I tried to fix malloc(0) in stdlib.h. It will work with ANSI code.
> Take a look at it. Be sure they work right. I strongly suggest to use
> -Wall during compilation.
> 
> H.J.

Talking about malloc(), malloc.h uses the macros PTR and FEXPR
(or something like that) from ansidecl.h to declare functions.
Malloc.h doesn't include ansidecl.h, however, and this can cause
a lot of spurious "parse error before '('" errors, if you include
malloc.h straight.

I just added an #include <ansidecl.h> to the start of malloc.h.
This fixed quite a few little problems.

        Mika
--
Mika Liljeberg                  Email:  [email-masked]
Helsinki University                     [email-masked]
Dept. of Computer Science

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

From: [email-masked] (Jaakko Hyvatti)
Subject: ash shell script parameter bug
Date: 21 Apr 92 09:27:09 GMT

  Seems to me that ash inserts a '\201' character before every equal
sign '=' in shell script parameters $1, $2, $3 etc. Run the following
shell script named 'foo':

  cat > bar <<EOF
  $1
  EOF
  od -c bar

with:

  ash foo a=b

and you'll get the following output:

  0000000   a 201   =   b  \n
  0000005

This caused me trouble while compiling groff with ash as /bin/sh.
-- 
Jaakko Hyv{tti                          [email-masked]
Lapinrinne 1 B 608                      [email-masked]
00180  Helsinki, Finland                +358-0-6958 5368

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

From: [email-masked] (Peter Orbaek)
Subject: Re: init, respawn
Date: 21 Apr 92 10:34:45 GMT

[email-masked] (Daniel Hagan) writes:

>1.     I would like to know if there is a version of the init program which 
>supports  the standard system V inittab format (i.e.  states, labels, 
>run levels, actions ) which exists for linux or which can be ported to linux.

Actually, I have one that is pretty SysV compatible. Someone (I forgot the 
name, sorry) from Holland wrote it for Minix and sent it to me. I have made
it work with Linux, but I don't use it because I don't really need it and 
I also have real work to do. 

I really intended to include it with a new release of the poeigl stuff, but
with the current C compiler mess that may be some months from now.

I will go home and get what I have and release it with no guarantees what so
ever.

>2.     Is it possible to defragment a linux partition
>3.       Relating to (1), is there a simple way of permanently  allowing a login through a modem attached to a serial port.

If you don't want to be able to dial out with that modem, it is just a matter
of putting the right line in /etc/inittab and initialising the modem 
properly.

Otherwise, it is rather tedious...

>       Any help or pointers to these questions would be greatly appreciated since I am new to the unix world.
>       Thanks,
>                       Daniel

        - Peter. ([email-masked])
--
Peter Orbaek ----------------- [email-masked]  |      ///
Hasle Ringvej 122, DK-8200 Aarhus N, DENMARK     |     ///
                                                 | \\\///
"Strong typing is for people with weak memories" |  \XX/

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

From: [email-masked] (Anthony Murdoch)
Subject: Information on linux ?
Date: 21 Apr 92 12:14:24 GMT

Howdy,

I was wondering if there was anywhere I could find some general information
on linux ?  I've been reading this news group and I'm getting interested in
it.  But I haven't seen any form of faq.

Questions I want answers to are;

1)  Where do I get it ?
2)  What format is it in ?
3)  How do I install it ?
4)  What hardware does it support ?
5)  What standard utilities are available ?

Thanx in advance
ant

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

From: [email-masked] (Dennis Flaherty)
Subject: Re: Question about svga preset patch
Date: 21 Apr 92 13:08:53 GMT

In article <[email-masked]> [email-masked] (Joe Waters) writes:
> Okay, I got the 0.95c+ kernel patched and compiled with no problem,
> and have lp and ps working, and I've nearly got a completely working
> Unix system that's faster than just about anything I've seen for an
> 86-based machine...  Kudos to all working on the project...
> 
> Now, a question of whoever (I lost his address) the guy is who wrote
> the svga-preset patch. 

That's me, they guy with a paper bag over his head...

>    I patched my source with the patch, and it
> compiled and ran fine, with one problem.  My desired svga mode is mode
> zero on my machine (paradise video card) - 132x25.  Anything higher
> than that (my only other choice is mode one, 132x43) is too fuzzy on
> my cheap crummy monitor...  The patch works fine with the video mode
> set to one and compiled, but if I set it to zero (my preferred mode),
> it compiles and runs, but defaults to standard 80x25 VGA mode.  Is
> there any fix available, even if it means patching other sources?
> Thanks for any help...

No, the problem is that when I updated my patch, I took the # sign
out of the makefile and put it in the setup.S file so that I could
get 80x25 VGA mode preset to work.  Otherwise the assembler chokes.
Now setting SVGA_MODE=0 might as well #undef it.  I'll fix it and
send yet-another version to tsx-11.

Hey, I said I wanted feedback, didn't I?  Nice to see people are 
using my patch.

BTW, I won't be making a patch to let you go back and forth between
modes after bootstrap-- "I already have a job."

-- 
Dennis T. Flaherty     [email-masked]
Miles, Inc.            [email-masked]
Diagnostics Division
My doctor says Mylanta, but my boss says Alka-Seltzer!

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

From: [email-masked] (0134)
Subject: Re: Oddities with MCC Release
Date: 21 Apr 92 13:18:03 GMT

after installing the mcc interim version (0.95c+) our mg bombed !!!
even recompiling it led to no results. is there a version that runs under
mcc 0.95c+ ???

we had the same shell problem.

folker

p.s.: What is the state of tcpip + a driver for wd8003e cards ???
      i am trying to set up a linux 386 as a printer server and also
      to offer mail service. 
      Plus we have a 386 with 8-12 serial ports
      plus a bunch of old vt100-vt230 terminals !!!!! 
      Has anybody tried this out before ???

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

From: [email-masked] (Scott Silverstein MD)
Subject: Re: 0.95c+ console and gcc 2.1 problem.
Date: 21 Apr 92 12:38:14 GMT

> I used to run DKBtrace under MS-DOS, and then i ran it under AT&T
> SVR4 (my last enviornment. yuuuck)

A bit bloated, huh?
 
> *KABOOM!* gcc got very angry and spit this
>error message at me:
>
>gcc: Internal compiler error: program cc1 got fatal signal 6
>make: *** [parse.o] Error 1
>
>Correct me if i'm wrong, but that's not supposed to happen, is it? :-)
>

Sure it is.  What are computers and new software for, if not for
internal errors?

I once had the supposedly robust PL/I-optimizing compiler on an IBM370/185
mainframe do that to me.  See, it happens to the best of us.

--S.

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

From: [email-masked] (Scott Silverstein MD)
Subject: Re: If not SCSI, why not floppy?
Date: 21 Apr 92 12:41:44 GMT

>DOS 5, OS/2 2.0, WINDOWS 3.1, WIN32NT (soon!), and LINUX:
>   life was much easier when DOS 3.3 was the only OS!
>
And *even* easier when TRSDOS was the only OS...

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

From: [email-masked] (Timothy F. Sipples)
Crossposted-To: comp.os.os2.programmer
Subject: Re: generic scsi support in OS/2
Date: 21 Apr 92 14:19:50 GMT
Reply-To: [email-masked]

In article <[email-masked]> [email-masked] (Tim Tsai) writes:
>  I asked this before in comp.os.os2.misc but got no answers, so
>I'm going to give it another shot.  On OS/2 2.0 GA, IBM has
>built-in support for scsi controllers that intercepts INT13.
>Does anybody have comments on how this works?  My guess is that
>OS/2 uses the virtual-8086 mode to call the controller's BIOS
>routines and pass data back to protected mode through some sort
>of share memory.  While there probably is a degradation in
>performance, a much broader range of devices are now available.
>Thoughts?

Bingo -- correct.
-- 
Timothy F. Sipples       Keeper of the OS/2 Frequently Asked Questions
[email-masked]  List, available via anonymous ftp from
Dept. of Economics       128.123.35.151, directory pub/os2/faq, or via
Univ. of Chicago  60637  netmail from [email-masked].

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

From: [email-masked] (Timothy L. Nali)
Subject: Re: A new game port, and mtools problems...
Date: 21 Apr 92 16:02:55 GMT

Excerpts from netnews.comp.os.linux: 19-Apr-92 A new game port, and
mtools.. Adam Justin Thornton@owl (1460)

> I'm using the mtools.a supplied with DLE.tar.Z in the gcc2.1 distribution,
> and I have C defined as /dev/hda1 and D as /dev/hdb1, which is where they
> are.  However, when I try mtools <anything> it gives me mtools: command not
> found error message.  What am I missing?  Is there some syntax I should be
> aware of?

In the readme file, there is a long ld line (ld mtools mdir mread ....) 
You have to type that in.  It links mtools to commands like mdir, dir
command, and mread, copy a dos file to linux.  then you type in mdir c:,
mread foo.ext, etc.

_____________________________________________________________________________
 
 Tim Nali            \  "We are the music makers, and we are the dreamers of
 [email-masked]  \   the dreams" -Willy Wonka and the Chocolate Factory

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

From: [email-masked] (Michel Eyckmans (MCE))
Subject: Re: problems booting
Date: 21 Apr 92 10:32:44 GMT
Reply-To: [email-masked]

In article <[email-masked]>, [email-masked] (H. Peter Anvin N9ITP) writes:
|> In article <[email-masked]> of comp.os.linux,
|>   [email-masked] (Richard Alan Brown) writes:
|> > 
|> > I used rawrite to make a bootable disk and a rootimage disk. When I 
|> > boot my pc with the floppy in, I get the loading............
|> > and the SVGA mode question. 
|> > when I press any other key, the system simply reboots, and cycles through
|> > this same process.
|> 
|> I experience exactly the same phenomenon on a 486/33 ISA with the OPTI
|> 

I've had exactly the same problem. After uncompressing the 0.95c+ 
bootimage under 0.12, I used cp to put it onto a floppy. This
resulted in the behaviour described above. It turned out that my
copy of uncompress was corrupt. After switching to the 0.95a
uncompress, all worked well.

                                             MCE

PS : Anybody know where to get "mvdir"?

                                             MCE

-- 
=============================================================================
#include <std/disclaimer>

M. Eyckmans (MCE)                                            [email-masked]
=============================================================================

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

From: [email-masked] (Kees J. Bot)
Subject: Re: IDE drive performance with linux
Date: 21 Apr 92 15:02:22 GMT

[email-masked] (Guido Kueppers) writes:

>Greetings,
>thanks to all who have replied to my IDE drive problem. From the responses I
>got so far I gather that the drive's poor performance is specific to my drive
>and possibly due to inappropriate configuration (translation vs. native mode).
>If there is any interest I will post my newly accquired wisdom on IDE drive
>setup when the problem is solved (Or should I rather spare you the details?)

I don't think the problem is with your drive, I think it's better to
send the device driver writer back to the drawing board.

I am currently rewriting the Minix hard disk driver to increase its
performance, because it also has problems with IDE drives.  I've got
access to three IDE drives, of 100Mb, 120Mb and 200Mb.

The current Minix HD driver reaches reading speeds of 250, 60, and
500 kbps on them.  Note the slow speed for the 120Mb.  At the usual
rotational speed of 3600rpm, this is exactly 1k per rotation!  (The
native Minix block size).

I have got another HD driver that precomputes a lot of data in advance,
programs the controller to read/write a lot of sectors and then goes to
work at the interrupt level.  It can make 450, 500, and 600 kbps on each.

My guess is that the first two disks do not have a track cache and the
third one does.  The current Minix HD driver can't keep up with the
120Mb disk.

I am trying to make a device driver that works like the second one but
does not use the ugly interrupt routine (it seems to hang sometimes),
but uses message passing instead at the expense of a few context
switches.  Early results (the paint is still wet) show speeds within 5%
of the ugly driver.

Further comments:
- I don't know what the Linux AT disk driver looks like, a Linux
  enthousiast should check it out to see if I'm right.  (I don't have
  any Linux code, I would probably label everything as "ugly". :-)

- Using a raw device and reads of 127kb it is possible to reach
  800 kpbs on the 200Mb disk using the "ugly" driver.  Getting the
  controller to transfer many sectors at once seems to be the trick.

- The drive doesn't have to translate the parameters as often for large
  transfers.  (Not that I think that the "translate" vs. "native" mode
  thing is very important.)

- The file system must be able to send large read-ahead requests to the
  driver, so it has something to work with.  Writing speed is not as
  important, but must be looked at too.  (Minix writes all dirty blocks
  for the same device at once if it must write one.)

[Back to making to floppy driver go 30% faster reliably, slow devices
seem to give more trouble than fast ones!]
--
                                Kees J. Bot  ([email-masked])
                      Systems Programmer, Vrije Universiteit Amsterdam

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

From: [email-masked] (n.h.chandler)
Crossposted-To: alt.os.linux
Subject: Where can I get pfdisk-0.92?
Date: 21 Apr 92 17:22:03 GMT

Where can I locate pfdisk-0.92 and fdisk-0.92?  I'd
prefer that they were not wrapped up with 2 megabytes
of other stuff that I'd have to discard.

Neville H. Chandler
nhc\@mtdcc.att.com

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

From: [email-masked] (Philippe Backouche)
Subject: Thread
Date: 21 Apr 92 18:09:49 GMT
Reply-To: [email-masked] (Philippe Backouche)

   Could someone explain what threads are ? What is the difference between 'forking'
   a new process and making a thread ?

   Do threads exist in Linux ??? 

                                 Thanks for any help,

                                     Philippe Backouche
                                     [email-masked]

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

From: [email-masked] (M. Saggaf)
Subject: SCSI Adaptec 1522
Date: Tue, 21 Apr 1992 19:32:29 GMT

Does anybody know if the current SCSI version of Linux supports the
Adaptec 1522 host adapter? I'm looking into buying that controller and
I'd like to know if Linux can use it. It's about $100 less expensive
than the Adaptec 1542 since it is not bus mastering. Please let me
know. Thanks

-- M. Saggaf ([email-masked])

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

From: [email-masked] (Kevin Cummings)
Subject: Re: GCC2.1 (Wonderful !)
Date: Tue, 21 Apr 1992 19:00:07 GMT

Sorry folks, but I can't pass this one up.  Those who don't wish a lesson in
PRIMOS style dynamic linking should go on to your next article now.

In article <[email-masked]>, [email-masked] (John Plevyak) writes:
> 
> Concerning the various kinds of dynamic linking.
> 
> As I remember (from long ago) the Primos (the Prime operating system)
> replaced all dynamic calls with calls to illegal addresses.  A table in

Let's see if I can re-interpret this correctly.  A link from one routine
to another in the Prime Segmented architecture is called an IP (indirect pointer).
It is a pointer to the target object.  A Dynamic Link is a SPECIAL pointer
to a name.  The FAULT bit in the pointer is set.  This causes the hardware
to raise a POINTER_FAULT$ condition (PL/I style condition, similar to a
C signal).  The POINTER_FAULT is caught by any available condition handler
(ON UNIT in PL/I terms) currently on the stack, including those buried in
the operating system.  If the condition gets through to the OS, the OS
checks to see that the pointer less its fault bit is a valid pointer
to a character string in memory.  If so, it passes the pointer off to
the dynamic linking routines which methodically search (via a search list)
the dynamically linked libraries and OS entries.  Due to software compatibility,
three types of libraries are searched:  OS entries, EPF libraries, and
old static mode shared libraries that might be installed in our LIBTBL.
The entrypoint names are just a name.  Currently they are not qualified by
a library name and therefore the ENTRY$ search list specifies the order of
libraries to search looking for a name match.  If the name cannot be resolved
in ANY of the libraries in the search list, a new error condition is raised
(signalled): LINKAGE_FAULT$, and the name is a part of the information
associated with the error.

> the image mapped the index of the illegal address to a filename/symbol
> pair.  The filename was found or loaded and the address was patched.  This

If the name is found in a library, the library routine passes the address of
the routine back to the dynamic link handler which then REPLACES the faulted
pointer (which we call a DYNT) with the runtime address of the routine.  This
IP is now considered SNAPPED (resolved), and further references through this
IP are direct to the resolved routine.  In some respect this is doing the
final linking stage at runtime.

> has the advantage that you could dynamically replace the library without
> relinking (the linker was in the OS).  This could be used on a 386 class
> machine.

Yes, it probably could, but I don't know enough about 386 pointers to know
how to do something similar.  But, given that a 386 32-bit pointer consists
of a 16 bit segment number and a 16-bit byte offset, you would probably have
to make use of some kind of "missing memory" error or page fault to a
special non-existent page in order to do something similar, and tie the
dynamic linking support into the page fault handler in the kernel, which is
not as clean as having its own special fault handler.

> The disadvantages were:
> 
>       1) your program could suddenly fail if the new library (installed by
>               someone else) had a bug

Isn't this a problem with ANY new library that has to be re-linked to?

>       2) you could not page directly off the executable

Yes you can.  You just have to seperate the code part from the data part.  IPs
are a part of the data segment.  You can page the machine code part just fine.
This is what a segmented architecture is all about.

>       3) your operating system was forced to intervene on  the first of
>               every dynamic call... thus slowing startup time.

Yes again.  But see some of the advantages below.

Another disadvantage is that if you wish to remain upward compatible, you can never
remove an entrypoint from a library, lest some program which currently uses it
starts to fail.  At Prime, this is the "Compatibility Shall Reign Forever" syndrome.

> The advantages were:
>       1) no need to relink shared library programs

Unless the library entrypoint name changes.  But if that happens, you have
bigger problems anyways.

A side point here is that you don't need to keep around old compiled binaries
or pre-linked files either.  AND you will only ever have one copy of a shared
library installed on your system at any one time.  Saves on file system disk space.

Further more, you can still staticly link some programs if you really need it
if you have both shared and unshared copies of the libraries available on your
development system.

>       2) no need to link to libraries that this execution of the program
>               did not require... finer grain linking could be a win here.

Possibly cuts down on working set.  You don't have to drag along unused baggage!

> In general I don't think that you will find an obvious clean and simple winner
> in a war of dynamic linking strategies if you ask more that a few people.

Probably true, however, if you carry around multiple versions of a library just
because it is no longer possible to re-link some old programs which were linked
with a previous version of the library, I don't see what you are saving!  Your
savings are being diminished by the "extra" libraries you have on disk, and code
that is not being shared at runtime!

> The simplest solution is usually the best though, and (not intending to start
> a war here) while Primos did dynamic linking which was nice, the lack of
> child processes, memory protection of 'shelled' programs, the segmented
> architecture, system calls with a mix PL1/G and FORTRAN interfaces and assorted
> other goodies made me wish for Unix with or without dynamic linking
> (perhaps it has changed, this was 1986).

Probably not dramatically enough for your tastes.  The Prime 200 and 300 was a FORTRAN
machine.  And we used FTN-66 as our systems programming language at that time.
When we released the 400 (and every subsequent machine), it was really a PL/I machine.
And we changed our system programming language (and our operating system) to reflect that.

Compatibility left us with the result you saw.  (Go ahead, and tell me UNIX doesn't have
compatibility problems from rev to rev.  It is its WORST problem.)

> john ([email-masked])

Sorry to drag this out, but every point made here needs to be considered when
we do dynamic linking for LINUX.  I am interested in hearing other's
points of view, and listening to the way others have implemented
dynamic linking.  But I beleive that Prime made "all the right decisions"
in their impe
=================================================================
Kevin J. Cummings                       Prime Computer Inc.
20 Briarwood Road                       500 Old Connecticut Path
Framingham, Mass.                       Framingham, Mass.

Work:  [email-masked]
Home:  [email-masked]

Std. Disclaimer: "Mr. McKittrick, after careful consideration,
                  I've come to the conclusion that your new
                  defense system SUCKS..."   --  War Games
=================================================================

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

** 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) 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
    tupac-amaru.informatik.rwth-aachen.de	pub/msdos/replace

The current version of Linux is 0.95a released on March 17, 1992

End of Linux-Activists Digest
******************************