Subject: Linux-Development Digest #412
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:     Thu, 27 Jan 94 17:36:54 EST

Linux-Development Digest #412, Volume #1         Thu, 27 Jan 94 17:36:54 EST

Contents:
  Re: Upper Memory Blocks ?? (Charles E Meier)
  16/24 bit color under Linux? (berg@wvnvms.wvnet.edu)
  Re: TCP/IP Jobs List (was: IP Multicasting) (Don Holzworth)
  Re: Version control systems... (Superuser)
  Re: DAC ADC device driver (Donald Jeff Dionne)
  Re: Which is better? 680x0 or 80x86? (Geert Coelmont)
  NCR 53C700 SCSI card driver? (Mario Camou)
  Re: Upper Memory Blocks ?? (Rob Janssen)
  Re: Which is better? 680x0 or 80x86? (Rob Janssen)
  Re: PPP ? (Rob Janssen)
  Re: ELF binaries (Rob Janssen)
  Re: Atari port (Rob Janssen)
  Re: Block size setting for SCSI-Tape not working? (Klaus Herrmann)
  Re: ELF binaries
  Re: ELF binaries (Brandon S. Allbery)
  Adaptec aha1522 driver broken? (HELP!) (kelly r brown)
  Re: ELF binaries (Eric Youngdale)
  Re: Backspace at login prompt only works till pl14m (Andries Brouwer)

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

From: cemeier@magnus.acs.ohio-state.edu (Charles E Meier)
Subject: Re: Upper Memory Blocks ??
Date: 25 Jan 1994 22:10:33 GMT

In article <1994Jan25.190556.10523@engr.engr.uark.edu>,
>
>Boy oh boy ooh boy oh boy...... They just don't teach them like they used too.
>
>Wow, what a misconception.....   The memory between 640 and 1024 has only two
>address spaces allocated always...  Thats video memory and BIOS...  
>Unfortunately there is nothing you can do about Video mem.. BIOS has less that
>64K address space allocated to it, BIOS shadowing is simply moving the BIOS
>that is using that address space in to the RAM that is there.  Almost totally
>software transparent.
>

I have a VLSI Topcat chipset.  I can set the area between 640 and 1024 to be
read and/or write accesses to the system board memory or bus/rom.  This 
means that it is possible to access the system ram located where the video
is rather than the video ram.  Pain in the ass though since I've got to write 
three bytes of info to the chipset to make the switch.

>Linux or DOS dosn't care if you enable BIOS shadowing.   Secondly, Linux uses
>the address space in that region (except Vid and BIOS) for general memory
>pool allocation...  There are NO hardware devices that map into those location
>without having a supplied driver, even then, the mapping is not fully 
>complete without driver setup...  Linux will work fine reguardless of DOS
>designed hardware...  

The chipset also has all of the hardware for LIM 4 EEMS.  Means that I can
put up to 32Meg on a 386sx.  Nice, except that the bios sets the 640-1024
region to be EEMS memory.  No prob for dos, except that I only boot dos about
10% of the time now.  Linux, on the other hand reports at boot time that there
is a 384k area that is "reserved."  Free/top bears this out, Linux doesn't
seem to use it and I haven't figured out how to tell Linux its available.
I tried a simple fix by setting each 4k page (except for the video area) to be 
a read/write to system ram.  This was done in the kernel somewhere close to 
where the "bogoboost" patch goes, but no luck.  When I do this with QEMM, it 
thinks the ram is memory mapped by an unknown device but there is a simple 
override switch.
 
How does Linux figure out how much ram exists above 640K. Does Linux ask the 
bios how much memory there is at boot?  

>
>Even still.... with Video Memory mapped out, BIOS mapped out, there is only
>less than 256K left....  That wont do you much good with most Linux apps...
>

Lets see... $40/Meg = $10/256K = a couple of six packs of good German beer -
A fact that Linux reminds of each time it prints Reserved [384K].

>My two cents worth... Alan..
>

My two six packs worth...

--
        Charles E. Meier     <cemeier@magnus.acs.ohio-state.edu>

- "Once in a while you get shown the light in the strangest of places if you 
   look at it right." - Hunter/Garcia 


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

From: berg@wvnvms.wvnet.edu
Subject: 16/24 bit color under Linux?
Date: 25 Jan 94 19:26:20 -0500

I'm interested in getting Linux support for either  16 or 24 bit color.
Does anyone have a clue if this is under development. If not, does anyone
have an idea of how complex it would be to develop the driver for either
16 or 24 bit support at different resolutions? I have no experience with
such development and would appreciate any comments (least I go down a path
that bears no fruit).

Thanks

Mitch Berg
West Virginia University

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

From: donh@gcx1.ssd.csd.harris.com (Don Holzworth)
Subject: Re: TCP/IP Jobs List (was: IP Multicasting)
Date: 25 Jan 1994 21:26:21 GMT
Reply-To: donh@gcx1.ssd.csd.harris.com (Don Holzworth)

In article <1994Jan25.190049.4210@swan.pyr>, iiitac@swan.pyr (Alan Cox) writes:
|> In article <TERJEVE.94Jan24195142@gymir.ifi.uio.no> terjeve@ifi.uio.no (Terje Vernly) writes:
|> >
|> >Has anyone added the IP Multicast extensions (described in rfc1112)
|> >to Linux yet?
|> >
|> Multicasting is in the device drivers but no higher currently. I have to admit
|> its one of the more esoteric things well well down the jobs list unless
|> anyone cares to contribute code..
|> 
As a point of information, what is on the "jobs list"?

Thanks,
==============================================================================
 donh@travis.csd.harris.com        |  Don Holzworth
 All opinions are mine alone.      |  (305) 977-5563
                                   |
  "Efficiency is doing things right. Effectiveness is doing the right thing."
==============================================================================

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

From: root@bsd.coe.montana.edu (Superuser)
Subject: Re: Version control systems...
Date: 25 Jan 1994 19:06:26 GMT

In article <Jan25.043228.59499@acs.ucalgary.ca>,
Michael David Henders <mdhender@acs.ucalgary.ca> wrote:
>Can anyone point me to a good version control system for Linux?
>Some associates of mine and myself are developing some new
>software and running into the problem of multiple people editing
>the same file at the same time.  Preferably a vcs where the files
>are signed out (and locked), and the signed back in.  I would
>also appreciate a shareware (ftp site) version, but commercial
>will do.

Both FreeBSD and NetBSD folks use CVS (Concurrent Version System)
successfully for their version control system.  (It's quite a large
software repository we're dealing with)

It works quite well and is based on RCS.  However, you do not have the
locking capability you asked for above, but everyone I've introduced to
CVS has found out that it's a non-issue once you used it for a little
while.  (Of course there is some fear and trepidation at first, but it
goes away quickly)

Highly recommended.


Nate



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

From: jeff@ee.ryerson.ca (Donald Jeff Dionne)
Subject: Re: DAC ADC device driver
Date: 25 Jan 1994 20:35:44 GMT

HENRY WONG (hwong@ee.ryerson.ca) wrote:
:       Regarding the Voice capabilities for 386 under UNIX ... 

: Does anyone know anything about the AM79C30A DAC ADC chip used in the
: audio card in the SUN workstations ?  And is it possible to sue in on
: the 386 PC's ?  

:               Info regarding device drivers for the DAC ADC would be most
: appreciated ...
I think you would be better off looking at one of the new 16bit Deta Sigma
CODEC chips from Analog Devices and second sourced from Crystal Semiconductor

we've used the serial version of it in an instrument, and it has excellent 
performance, both signal to noise, and dynamic range.  Also, it requires 
no anti-alias filters, where the AMD part you mention requires significant
effort in this regard if you are to achieve good results.  As for the
device driver, have look at the code for I think it is the GUS card.
The new ones use the same chip I think, and if not, look at the 
code in the patch for the pc sound driver.  pc-snd0.4-pl14.tar.gz I think.

I notice that you are in my department, so send me mail, and I'll give you
the data sheet if I can find it, since it's a new part, and you will not
find it elsewhere.

: Thanks in advance.

you're welcome!

: Henry
: hwong@ee.ryerson.ca

73!  de Jeff / VE3DJF

Internet Jeff@EE.Ryerson.Ca
AMPRnet  VE3DJF@bbs.VE3RPI.ampr.org
AX25bbs  VE3DJF@VE3RPI.#SCON.ON.CAN.NOAM

Linus is a code poet, Bill Gates is a bean counter....

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

From: gc@tyana.denkart.be (Geert Coelmont)
Subject: Re: Which is better? 680x0 or 80x86?
Date: 25 Jan 1994 18:32:52 +0100

La Monte Yarroll (piggy@hilbert.maths.utas.edu.au) wrote:
:>The one thing needed to support a multi-tasking OS is memory
:>management.  The 68000 did not have an MMU, but neither did the 80286.
:>The 68010 included some minimal MMU support, and could thus run a fair
:>version of Un*x.  The memory segmenting hardware of the 80286 allowed
:>some MMU-like operations, and so it was possible to run decent toy
:>versions of multi-tasking OS's like COHERENT 3.0.  The 80386 and 68020
:>both have real MMUs and so are capable of running full versions of
:>Un*x-like OS's.

One small remark: MMU is needed for multiUSERing, NOT for multiTASKing.

But to answer the original question (Which is better? 680x0 or 80x86?)
there is no doubt really... life starts at x40 and ends at x86  ;-)

--
Geert Coelmont,                         email:   gc@denkart.be

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

From: camou@csid.gmeds.com (Mario Camou)
Subject: NCR 53C700 SCSI card driver?
Date: 25 Jan 1994 17:30:51 -0500

Hi,
I've got a Scale brand box (built by Intel). It's got a built-in SCSI
controller on the motherboard. The Scale people tell me it's compatible
with the NCR 53C700 board. Is anybody working on support for this board?
Thanx in advance,
-- 
Mario Camou / EDS Mexico Client-Server Integration Team
From Mexico City, the smog capital of the world
==============================================================================
My opinions are only mine, mine, MINE!

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Upper Memory Blocks ??
Date: Tue, 25 Jan 1994 18:18:31 GMT
Reply-To: pe1chl@rabo.nl

In <1994Jan24.180843.5433@swan.pyr> iiitac@swan.pyr (Alan Cox) writes:


>Before people get confused here. UMB's in DOS are implemented by 386 page
>mapping not by hardware. Linux just uses the memory as it finds it. I normally
>turn off video rom shadowing and bios rom shadowing to get the last few K
>on the 4Mb machine here.

This actually depends on the chipset in the machine.
There *DO* exist chipsets that do shadowing without using the 386 features.
(actually I think most systems can do this)

Often you can select whether you want the 'lost 384K' appended to the end
of the RAM area when you have no shadowing enabled.  Then, Linux can use it.
When your chipset can't do that, you won't gain much by tweaking the
remapping anyway, as you will have to leave room for the VGA card, ethernet
card and other things that map in high memory and you want to be visible.
(VGA BIOS (for dosemu), SCSI BIOS (for some driver's autodetect))

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Tue, 25 Jan 1994 18:23:21 GMT
Reply-To: pe1chl@rabo.nl

In <2i1va2$63f@diemen.utas.edu.au> piggy@hilbert.maths.utas.edu.au (La Monte Yarroll) writes:

>Compiler writers like CPU's with lots of interchangable registers, but
>that's because it makes register allocation easier--this has little to
>do with multi-tasking.

In fact, lots of registers is a disadvantage to multitasking, as you will
have to swap them all on a task switch...

>On-chip cache, fast bus, and high clock speed all make most things go
>faster, but they are just icing.  You can run a full-fledged Un*x on
>a 386SX16, or a 10Mhz 68010--you just have to spend a little more time
>waiting.

Now you are comparing apples and oranges...  the 68010 would need external
memory management hardware to reasonably run UNIX.
In fact, a 80286 is better equipped to run a multitasking system than
the 68010 is.  The memory management may suck, but on the 68010 it does
not exist at all...

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: PPP ?
Date: Tue, 25 Jan 1994 18:26:12 GMT
Reply-To: pe1chl@rabo.nl

In <1994Jan24.202831.18201@super.org> becker@super.org (Donald J. Becker) writes:

>While PPP didn't make the code freeze for Linux 1.0, the hooks are there so
>that it's trivial to add it to the distributed kernel.
                                ^^^^^^^^^^^^^^^^^^^^^^

When I wrote this and got a stupid remark about distributed systems back,
I thought it might have been caused by my limited knowledge of english idiom.
However, now it seems I am in good company :-)

>Donald Becker                                         becker@super.org
>IDA Supercomputing Research Center
>17100 Science Drive, Bowie MD 20715                       301-805-7482
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: ELF binaries
Date: Tue, 25 Jan 1994 18:28:07 GMT
Reply-To: pe1chl@rabo.nl

In <CK5Int.7Gs@claircom.com> rob@atlantis.claircom.com (Rob Kenny) writes:

>I have looked through all the FAQ's, HOWTO's and source code at sunsite,
>and I cannot find out the latest status of ELF binaries running under
>Linux.  I've looked at fs/binfmt_elf.c and sure enough, my ELF binary
>gets loaded, but /usr/lib/libc.so.1 doesn't work.  The only one
>I could find was in /pub/Linux/distributions/SLS.old/a3/elfabi.tgz,
>but it only prints:
>Interpreter: 10b 3000 2000
>lcall 7,xxx:eax = 00000036
>lcall 7,xxx:eax = 00000004
>lcall 7,xxx:eax = 00000004
>lcall 7,xxx:eax = 00000004

That is correct, it can load ELF binaries, but to run binaries you got
from other systems is something different.  For that you need IBCS2
compatibility, which isn't there yet.  (it is in ALPHA)

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

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Atari port
Date: Tue, 25 Jan 1994 18:31:59 GMT
Reply-To: pe1chl@rabo.nl

In <1994Jan24.234259.2931@radar.demon.co.uk> richard@radar.demon.co.uk (Richard Hodson) writes:

>Is anyone out there porting Linux to the Atari TT? I heard rumour of
>such a port ages ago, but have seen no evidence. The 680x0 mailing list
>seems very quiet.

There has been some work on Amiga, as far as I know

>I am currently running Linux on a 386/40, and have a TT and all the
>Atari developer docs.

Then maybe you should start to work on it yourself?

>Seems a shame to have all that CPU sitting next to
>me, and having to run Linux on a little 386 box.

Is there so much difference between an 386/40 and the TT?  I would not
think it is that spectacular...

Rob (who considered buying a TT but dropped the idea because Atari dropped UNIX)
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: root@aladin.seicom.de (Klaus Herrmann)
Subject: Re: Block size setting for SCSI-Tape not working?
Date: Sun, 23 Jan 1994 16:51:18 GMT

Martin Cracauer (cracauer@wavehh.hanse.de) wrote:
: I want to read tapes written with of blocksize of 1024 byte.

: Linux' default is 512 byte, so this does not work. The error message
: is "I/O error" to the terminal running the application and "st0:
: Incorrect block size" to the console.

I also found no way to read tapes with 1024 Bytes/blocksize, so I write my
tapes on a SUN with the following command:

  tar cfb - 2 . | dd of=/dev/rst0 obs=2b

With such a written tape I can read it on my Linux-box

Hope what helps

  Klaus
-- 
*******************************************************************
Klaus Herrmann                |      klaus@seicom.de
7302 Ostfildern 1             | or   klaus@aladin.tynet.sub.org
Germany

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

From: balister@maddog.async.vt.edu ()
Subject: Re: ELF binaries
Date: 26 Jan 1994 04:05:07 GMT
Reply-To: pbaliste@vt.edu

Rob Kenny (rob@atlantis.claircom.com) wrote:
: I have looked through all the FAQ's, HOWTO's and source code at sunsite,
: and I cannot find out the latest status of ELF binaries running under
: Linux.  I've looked at fs/binfmt_elf.c and sure enough, my ELF binary
: gets loaded, but /usr/lib/libc.so.1 doesn't work.  The only one
: I could find was in /pub/Linux/distributions/SLS.old/a3/elfabi.tgz,
: but it only prints:
: Interpreter: 10b 3000 2000
: lcall 7,xxx:eax = 00000036
: lcall 7,xxx:eax = 00000004
: lcall 7,xxx:eax = 00000004
: lcall 7,xxx:eax = 00000004
: ..


: So, could "someone in the know" please, please, please help me?

I think I know something ...

I think your ELF binary is really a SVR3 binary not an ELF binary. Try the
ibsc2 emulator. Join the IBCS2 channel of the list or mail me for more
info. (I can't keep the acronym straight)

Philip
--
Linux: The choice of a GNU generation!

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: ELF binaries
Date: Wed, 26 Jan 1994 22:54:50 GMT

In article <2i4q5j$a9v@solaris.cc.vt.edu>, pbaliste@vt.edu says:
+---------------
| I think your ELF binary is really a SVR3 binary not an ELF binary. Try the
| ibsc2 emulator. Join the IBCS2 channel of the list or mail me for more
| info. (I can't keep the acronym straight)
+------------->8

Someone typoed when setting up the channel; it's called "IBSC2".  Made it hard
for me to send mail for a while...

ELF and COFF are file formats.  Linux binaries in ELF and COFF format work.  I
think Eric Youngdale is already using Linux executables in ELF format; when
the GNU utilities properly support ELF (shared libraries are a sticking point
right now, I believe) ELF will become a "preferred" object file format,
because it handles many object file constructs automatically that the ancient
BSD a.out format needs help to deal with (C++ global constructors in
particular).

iBCS-2 is an ABI (application binary interface; in essence, it defines the
system calls).  iBCS-2 is not yet working fully; we're working on it.  The
"released" iBCS-2 kernel module does nothing more than print out the "lcall
7,0" instructions that iBCS-2 compliant programs use for system calls.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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

From: uk09242@mik.uky.edu (kelly r brown)
Subject: Adaptec aha1522 driver broken? (HELP!)
Date: 26 Jan 1994 06:25:48 GMT

Hello,

I've got a problem with the aha1522 driver and my Maxtor 7245S SCSI drive.

My setup:

486dx/33 (intel)
16MB RAM
Adaptec aha1522 SCSI Card (address 340H, IRQ 11, DMA 0 (not used), SCSI ID 7)
Fujitsu SCSI Drive (340MB, SCSI ID 0)
Maxtor SCSI Drive (245MB, SCSI ID 1)
PAS-16,
other goodies that are of no relavance...

Anyway, when trying to install Slackware 1.1.1 (0.99.pl14), using either the
uniboot disk, or the 2-disk boot/root disks, it will find the PAS-16 (which 
nothing is attached to...I just use it for sound), and find the aha1522 host 
adapter.  It also finds my Fujitsu drive.  However, it will NOT find the Maxtor
drive.  It reports only 1 disk drive, no tape, no CD.  (I have a chinon cdx-435
that has its own card, so i don't expect it to unless i put it on the adaptec).

So...what I'm left with is:

The 1522 itself has no trouble finding the drive.
DOS has no trouble finding the drive.
SCSICNTL.EXE (from ftp.uu.net:vendor/adaptec/) finds the drive.

Linux does not find the drive, therefore I cannot install it.
(this is from the install disk, so I can't do any hacking on it, since I
can't get it on my box!)


I *NEED* to install Linux on this drive.  I cannot mess around with my first
drive for several reasons.  I also cannot switch drives around on the cables
due to a short in the Fujitsu's power cable adapter block.  The termination is
correct.  I've verified this several times in the past.

Can anyone come up with a fix for this so that I can have Linux on my box?

I would appreciate replies either in this group, or via email.

I'd REALLY appreciate some help, as I've been banging my head against the
wall since Friday night.  I'm at the end of my rope...

Thanks in advance,

mark->
(Kelly's Husband)


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

From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: ELF binaries
Date: Wed, 26 Jan 1994 06:06:09 GMT

In article <2i4q5j$a9v@solaris.cc.vt.edu> pbaliste@vt.edu writes:
>Rob Kenny (rob@atlantis.claircom.com) wrote:
>: Linux.  I've looked at fs/binfmt_elf.c and sure enough, my ELF binary
>: gets loaded, but /usr/lib/libc.so.1 doesn't work.  The only one
>: I could find was in /pub/Linux/distributions/SLS.old/a3/elfabi.tgz,
>: but it only prints:
>: Interpreter: 10b 3000 2000
>: lcall 7,xxx:eax = 00000036
>: lcall 7,xxx:eax = 00000004
>: lcall 7,xxx:eax = 00000004
>: lcall 7,xxx:eax = 00000004
>
>I think I know something ...
>
>I think your ELF binary is really a SVR3 binary not an ELF binary. Try the
>ibsc2 emulator. Join the IBCS2 channel of the list or mail me for more
>info. (I can't keep the acronym straight)

        Perhaps it is a static linked ELF binary.  I just tried a hello world
program, compiled and static linked on a SVr4 machine and it ran just fine
proided that I have the ibcs2 stuff in my kernel.  It gives messages like the
above without the ibcs2 patches.

        FWIW, the correct name is IBCS2 (Intel Binary Compatibility
Specification 2).  The mail channel is IBSC2, which I can only explain by
saying that my fingers slipped when I created the channel :-).

        Note that SVr4 has some syscalls which are not yet in the ibcs2
emulation module, but this sort of thing would be relatively easy to add.
(Hint: If someone is really interested in getting involved with ibcs2, an extra
set of hands would come in handy.).

        A little bird told me that a COFF libc shared library is well underway,
and I suspect that this could just be compiled under SVr4 to provide a ELF
shared library for SVr4 programs.  The elfabi package that was referred to in
the original post was a bit of a kluge - I was hoping to avoid generating my
own version of a library, so I came up with an interface between the linux libc
and the SVr4 ABI.  While it was an interesting exercise, there were some issues
which could not be cleanly solved in that framework.  A proper ibsc2 library
would be much cleaner I think.

-Eric
-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

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

From: aeb@cwi.nl (Andries Brouwer)
Subject: Re: Backspace at login prompt only works till pl14m
Date: Thu, 27 Jan 1994 00:54:23 GMT

Bernd.Landorff@arbi.informatik.uni-oldenburg.de (Bernd Landorff) writes:

>It's no big thing but since pl14n or 14o when you type
>backspace the character will be erased but it stands 
>still on the screen. This happens only when getty is
>running, with login (the second time and so on) everything
>works ok. I haven't changed the configuration on compiling.
>Can anybody tell me what's going wrong?

Yes. In the old console driver printing a \177 would erase the previous
character. However, the console driver tries to simulate a vt100, and
this is contrary to vt100 behaviour, so I deleted that fragment of code.
Thus far the only reports about programs that changed behaviour have
been about getty. Most getty's I know about are correct and not affected,
but I think the one that came with SLS 1.01 is not and is.

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


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