Subject: Linux-Development Digest #727
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:     Tue, 17 May 94 10:13:11 EDT

Linux-Development Digest #727, Volume #1         Tue, 17 May 94 10:13:11 EDT

Contents:
  Re: CD-ROM's do all read and write now? (Dinsdale Piranha)
  Re: Appletalk support? (Jeff Andre)
  Re: ADAPTEC 2740/2742 (Scott Ferris)
  Re: Linux 1.0.8 SLOWER than .99pl13 !! (Michael Ulbrich)
  The visual bell: patch and RFD (Alessandro Rubini)
  Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback. (Rob Janssen)
  linux, Mitsumi CD-ROM (& SB), & the TA CD-ROM - solved! (mark)
  Re: ET++ Application Framework (Harald Henkel)
  Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback. (Rob Janssen)
  Re: linux, Mitsumi CD-ROM (& SB), & the TA CD-ROM - solved! (Rob Janssen)
  Re: LOGISCAN V0.0.1 released (Henning Holtschneider)

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

From: erik@peewee.chinalake.navy.mil (Dinsdale Piranha)
Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware.misc
Subject: Re: CD-ROM's do all read and write now?
Date: 16 May 1994 22:18:42 GMT

Neal W. Miller (millen3@rebecca.its.rpi.edu) wrote:
: richard@cogsci.ed.ac.uk (Richard Tobin) writes:

: >In article <2r1e1e$qi4@rainbow.sosi.com> stanf@rainbow.sosi.com (Stan Foy) writes:
: >>: Can someone tell me if all CD drives read and write now?  Which ones
: >>: are the "top of the line"?

: >>  Nope, your standard CD is read only.

: >It may also be worth pointing out that an MSDOS virus has been
: >distributed disguised as a program which converts conventional CD
: >drives to read-write.  No such thing is possible in software; don't
: >install anything which purports to do it.

:       Of course such software exists.  I've even got a cigarette lighter
: in my car that gives the vehicle underwater and aerial capabilities.

Hah, mine doubles as a T1 line internet connection.

CD = Compact Disc
ROM = Read Only Memory
as opposed to
WOM or Write Only Memory


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

From: andre@hoth.stortek.com (Jeff Andre)
Subject: Re: Appletalk support?
Date: Mon, 16 May 1994 21:44:11 GMT

Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
: In article <2r4q4r$44a@nnrp.ucs.ubc.ca> pdivine@unixg.ubc.ca (Patrik J. Divine) writes:
: >
: >does anyone know if there is, or will be any Appletalk support for Linux?  I
: >want to network several Mac's to a Linux machine but most of the Mac's are
: >older and do not have ethernet capability (or can you hook up external
: >ethernet devices to Mac SE's?) .. any help would be apperciated.
: >
: There is nothing stopping anyone writing a kernel or usermode appletalk handler
: for Linux. The kernel has all the code needed to write it in user mode, or you
: could build it in the kernel as a protocol layer like IP, IPX or AX.25. Since
: appletalk is relatively simple its a viable job for someone with the specs
: and plenty of time.

: Alan

I've always been interested in doing this project.  Besides the "plenty
of time" aspect, you need to program to the AppleTalk card.  I have both
an old TOPS PC card and a (more?) current DL2000 from Dayna.  In order
to support you'd have to get the vendors to release the specs for the
cards in order to write the drivers.  They may, I don't know, haven't
asked.

One of the real questions is how much of an interest is there in such
a capability.  Beyond sharing printers, AppleTalk isn't a steller performer.

I believe there is a way to attach Ethernet to old Macs; I believe there
are SCSI devices.  If you're interested, I'll find the product.  I think
we may have one or two here at work.

The other solution would be to get an IP <-> AppleTalk gateway.

Enjoy,

Jeff


--

Jeff_Andre@stortek.com             |   Aggressive - adj. - Optimistic
Storage Technology Corporation     |   
2770 S. 88th Street MS 4232        |   "We are developing the next
Louisville, Colorado  80028-4232   |    release on a very aggressive
(303) 673-3720                     |    schedule."

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

From: sferris@math.macalstr.edu (Scott Ferris)
Subject: Re: ADAPTEC 2740/2742
Date: 17 May 1994 05:45:35 GMT

Howie Grapek (howie@fc.hp.com) wrote:

> Is the AHA 2740/2742 supported? Are the drivers available? 

  No.  Not yet.

> I've seen mention of the 15xx/17xx (supported)
> and the 28xx (not yet), but no mention of the 27xx.

  The same driver will be supporting the 274x and 284x controllers.
The 284x is just a 274x with an EISA-VL converter on it.
They both use the same chip (aic-7770).   


--
Scott M. Ferris,             sferris@math.macalstr.edu
LaserMaster Inc,
Macalester College,
and points in between.


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

From: ulbrich@Informatik.TU-Muenchen.DE (Michael Ulbrich)
Subject: Re: Linux 1.0.8 SLOWER than .99pl13 !!
Date: 17 May 1994 09:44:28 GMT


In article <wpp.768130929@marie>, wpp@marie.physik.tu-berlin.de (Kai Petzke) writes:
|> daveh@texlin.minmet.mcgill.ca (Dave Hinz) writes:
|> 
|> >Hi :
|> 
|> >I was recently testing the floating performance of the Linux Slackware
|> >distribution using the clinpack.c source.  For my  486DX2-66  I had
|> >previously obtained around 3.1 Mflops DP under .99pl13 but now I get
|> >only 2.8 Mflops under 1.0.8 -- that's a 10% loss in performance!!!
|> 
|> It is very unlikely, that this is a kernel fault.  For the 486DX,
|> the kernel is not involved in doing floating point instructions.
|> 
|> Possible reasons for the drop in meassured performance could be:
|> a) You run a very short test (less than 1 second), so that the
|>    increased precess start up time matters.
|> b) FPU initialization has changed from double precision to
|>    extended (I do not know, whether it has happened, but it could
|>    have been).
|> c) Changes in GCC, which turn off certain optimizations, because
|>    they caused trouble elsewhere.
|> 
|> I do not know, what is true, and what not.  I am almost certain,
|> though, that it is not the kernel.
|> 
|> 
|> Kai
|> -- 
|> Kai Petzke                      | How fast can computers get?
|> Technical University of Berlin  |
|> Berlin, Germany                 | Sol 9, of course, on Star Trek.
|> wpp@marie.physik.tu-berlin.de   |

b) is indeed true. Solving a very ill-conditioned system of
linear equations by an QR-decomposition with double-precision under
Linux 1.0.0, I got totally different results then on other systems
(SUN SLC /w SUNOS4.1, Mips /w Irix, PowerMac, 486 /w Linux 0.99pl9),
which produced identical results. In contrast to the other Systems,
the result dpended also on the optimization-switches of gcc.

But don't worry, the reason is simple and harmless:
The mode-register of the floating-point unit under Linux 1.0.0 is set to
64 bit mantissa. This means, that all operations between operands on
the floating-point-stack are performed in extended precision. Rounding
to double precision is done *only* for operands written back to the memory.
This doesn't lower the performance (as far, as I know), because the floating-point unit of the 486 internal always computes with extended
precision.
Setting the mode-register to 53 bit mantissa (done by Linux 0.99pl9) forces rounding to double after *every* operation. Depending on the optimization-flag
of the gcc, operands are kept on the stack as long as possible. So in my
example more operations are performed without rounding to double than without optimization.
The matrix of my example M=(sqrt(i+j))_1<=i,j<=500 is so ill-conditioned, that
solving the system tests exactly the rounding-strategy of the machine.
After setting the mode-register to 53 bit mantisse by an assembler instruction
( fldcw ... , I believe) at the begining of main(), Linux 1.0.0 produced exactly the same result than all other machines independent of the optimization-flag.
The runtime was the same as before.

I don't know, why they changed the FPU-setting. It is more accurate than
rounding after every instruction. But using numerical algorithms, the last
digits almost all depend on round-off errors, and so the optimized code will
produce slightly different results. You'll never be sure, if it's possibly an
optimizer-bug. But it's often interesting, how strong the results depend on
this little difference in rounding.

But: You can trust your linux's floating point unit (it's indeed not a thing
of the kernel!). And - if the mentioned rounding-strategy heavily changes the results of an numerical algorithm:
Burn it and look for another !!!!!!!!!!!!!!


Stefan

Stefan Ulbrich
Technical University of Munich, Germany
ulbrich@statistik.tu-muenchen.de

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

From: rubini@unipv.it (Alessandro Rubini)
Subject: The visual bell: patch and RFD
Date: 17 May 94 10:30:33 GMT

(Sorry if this is a repost... the previous seems dead)

Hello linuxers,
   my own box doesn't have a loudspeaker, but now that I have access to a
full featured PC I had to turn off the bell from the linux console. It
has been very easy, and I include the patch below as I think the visual bell
is a good thing for all of us who go to bed late (most of us :-) and like
filename completion in the shell.

However, at times the bell is a good thing, so I wonder how to make it
dynamically switchable on and off. I thought of two ways, but I can't choose
between the two:

- modifying the setterm command is probably the best way, because it is the
        normal way to access console configuration, and it is already a
        linux-specific command.  However, it makes use of the escape
        sequences, which in turn are quite well standardized, and I won't like
        adding a non-standard escape sequence to the linux console.

- on the other way, addin an ioctl() of type TIOCLINUX is not useful to
        the final user without providing a command-line access, and it is not
        nice to mess setterm with ioctl()'s.

So I ask some suggestions to all of you who are interested in the matter.

Please reply by email to save bandwidth, and I'll post a
summary (and the patch) if there is enough interest.

==============

I took the patch against the 1.0 kernel, but it applies well (offset -1line)
to both the 1.0.9 and the 1.1.12. Midway kernels should be allright, too.

to apply:             cd /usr/src/linux/drivers/char; patch < __this_patch__

to re-enable the audible bell: "#define CONFIG_NO_VISUALBELL" at the beginning
        of console.c

---8<------8<------8<------8<------8<------8<------8<------8<---
*** console.c.audible   Fri May 13 18:07:21 1994
--- console.c   Sat May 14 18:18:16 1994
***************
*** 992,997 ****
--- 992,1014 ----
        }
  }
  
+ #ifndef CONFIG_NO_VISUALBELL
+ static inline void con_visualbell(const int currcons)
+ {
+     unsigned char *p; int i;
+     unsigned char *screenstart = (unsigned char *)(origin-
+                 (currcons==fg_console 
+                   ? ((__real_origin - __origin) << 1) 
+                   : 0));
+     unsigned char *screenend=screenstart+video_num_columns*video_num_lines*2;
+ 
+     for (i=0;i<2;i++)
+       for (p=screenstart+1;p<screenend+1;p+=2)
+                 *p = (*p & 0x88) | ((*p << 4) & 0x70) | ((*p >> 4) & 0x07);
+ 
+ }
+ #endif
+ 
  void con_write(struct tty_struct * tty)
  {
        int c;
***************
*** 1034,1040 ****
--- 1051,1061 ----
                 */
                switch (c) {
                        case 7:
+ #ifdef CONFIG_NO_VISUALBELL
                                kd_mksound(0x637, HZ/8);
+ #else
+                               con_visualbell(currcons);
+ #endif
                                continue;
                        case 8:
                                bs(currcons);
---8<------8<------8<------8<------8<------8<------8<------8<---


--
    __ o        alessandro rubini - rubini@ipvvis.unipv.it
   _`\<,
__( )/( )____           I am italian, but I didn't vote for them...

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback.
Reply-To: pe1chl@rabo.nl
Date: Mon, 16 May 1994 21:59:39 GMT

In <2r8fhhINNsaq@newsstand.cit.cornell.edu> bau1@cornell.edu               (Bogdan Urma) writes:

>Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
>: In article <2r3ith$q6f@brachio.zrz.TU-Berlin.DE> goldt@math.tu-berlin.de (Sven Goldt) writes:
>: >Alan Cox (iiitac@uk.ac.swan.pyr) wrote:
>: >
>: >: Already fixed as of 1.1.8
>: >: Alan
>: >
>: >Well,you should learn that there is the 1.0.x series and
>: >the 1.1.x series and it's no upgrade to use 1.1.x,but a
>: >risk.

>: I didn't say upgrade to 1.1.8 - I said fixed as of 1.1.8. I know the difference
>: I maintain the networking code!

>        Yeah, but if someone want the STABLE 1.0.9 + the fix then for those
>people, it doesn't matter if it's fixed in 1.1.8 !!

I think the original issue was only the existance of a bug and how it
could be fixed.  When the bug is fixed in an alpha version and you don't
want to upgrade to it, then so be it.  You still have your stable version
with the bug.

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

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

Crossposted-To: comp.os.linux.help
From: markbr@radian.com (mark)
Subject: linux, Mitsumi CD-ROM (& SB), & the TA CD-ROM - solved!
Date: Mon, 16 May 1994 22:00:54 GMT


Finally!

As I posted recently, I got the TA CD-ROM, and found that the setup kernel
recognized the CD drive, but the installed one didn't. I had trouble with
the recompile, as well.

The answer is:
    in (I think it's) /etc/include/linux/drivers/blocks, there are *two*
        makefiles. One is named Makefile, the other Makefile.orig. When
        I diffed them, I discovered Makefile.orig *had* conditions for
        compiling the Mitsumi driver, the Soundblaster driver, and one
        other driver, and Makefile *didn't*. I renamed both, and reran
        the compile. No problems, using lilo (after the usual moving & 
        /etc/lilo/install) I boot off my hard drive, I can mount the 
        CD ROM, etc.

I am emailing TA this, as well.

        mark

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

From: henkel@Informatik.TU-Muenchen.DE (Harald Henkel)
Crossposted-To: comp.os.linux.misc
Subject: Re: ET++ Application Framework
Date: 17 May 1994 07:31:17 GMT


In article <j.halar.3.000F6AAF@uow.edu.au>, j.halar@uow.edu.au (John Halar) writes:
|> I seem to remember a couple of months ago when I read an news article about 
|> somebody trying to adapt the ObjectWorks ET++ Application Framework for C++ 
|> to run on Linux under X11/R5.
|> 
|> A couple of questions:
|> 
|> 1) Is this software commercial or shareware/public domain??

ET++ was developed at the Eidgen"ossische Technische Hochschule (ETH) Z"urich
(Schweiz) (the same I think where Pascal, Modula & Oberon where developed)
and is free.

I've worked with it a year ago. (i think under HP-UX or SunOS).
With static libraries link times - even for small programms - are very high (>5
min).

But the concept of integrating static and dynamic class-browsers into the 
(debugging-) applications is very interesting.

|> 2) If it is, has anybody successfully compiled it and had it working 
|>    for linux??

Heaven't heard of it yet.

|> 3) Is there an ftp site from which I could get it from?

At least here in Munich

  ftp.informatik.tu-muenchen.de //pub/comp/programming/libraries/C++/ET++

Surely in the ETH Z"urich, too, but I don't know the email/ftp-address there.

Harald Henkel,

  student of computer science at Technische Universitaet Muenchen (Germany).

|> 
|> Any answer to these questions will be appreciated.
|> 
|> Cheers
|> 
|> John Halar
|> E-mail: j.halar@uow.edu.au
|> 
|> 

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.0.9 kernel bug (+ partial fix): when using non-loopback address to send to localhost, "from" address should also be non-loopback.
Reply-To: pe1chl@rabo.nl
Date: Tue, 17 May 1994 08:50:06 GMT

In <1994May17.003827.14965@emc.rvt.com> remco@emc.rvt.com (Remco Treffkorn) writes:

>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>: I think the original issue was only the existance of a bug and how it
>: could be fixed.  When the bug is fixed in an alpha version and you don't
>: want to upgrade to it, then so be it.  You still have your stable version
>: with the bug.

>: Rob

>Do your emotions run away from you? 
>What the heck is a "stable version with a bug"? An oxymoron?

How do you define "stable"?

1. it does not change

2. it does not crash

I think it is perfectly possible to have a stable version, under both
definitions, of some piece of software.  Even if it includes known bugs
that are nonfatal.

>If I remember correctly: The 1.0 version was supposed to be maintained
>to be a "stable" version, meaning only bug fixes would be applied.
>In fact nine bug fixes have been applied. This was ,inter alia, to acknolege
>the fact, that there are really people out there runing Linux in a production
>environment, not beeing interested in beein on 'the bleeding edge'.
>V1.1 was supposed to be the hackers heaven again. 

>If 1.0 has known bugs and they were not to be fixed, then to hell with it.
>Just delete it from the ftp servers and force everybody to paricipate in
>debugging the 'real' kernel. Anything else would at least be misleading.
>No different from using 99.13 when 99.15 was out (well, worse!).

I don't think you can exect all known bugs in 1.0 to be fixed.
For once, that would mean a lot of work which is unwarranted when the
reported bugs are nonfatal.
Second, changing the code to apply bugfixes always includes the risk of
breaking something else.  I have seen just too many cases of "lets include
this fix as it solves my problem and breaks nothing else".

>P.s.: If Alan feels it is too much to have to maintain the old 1.0.x stuff
>ontop of the current development branch, then we should really get rid of
>1.0.x, or maybe somebody is willing to fold back those fixes that would
>applay under Alans supervision? BTW: that goes for all the developers.
>I think the v1.0 branch only makes sense if the developers can support it.
>If not, let's kiss it goodby if it is too much of a drain. I at least
>consider the work on v1.1 more important, but then this is personal
>opinion.

I think the networking is definitely a part of 1.1 that should not be
merged back into 1.0 too much.  Some drastic changes have been made, and
merging them back into 1.0 is just telling the users they have a stable
version while in fact they run the ALPHA stuff.

(But then, I have been running 1.1.x from the time it became available.  I
don't think it is less stable than 1.0.x, and I am amused by people that
claim they "dont want to upgrade to 1.1 because it is soooo unstable")

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

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

Crossposted-To: comp.os.linux.help
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: linux, Mitsumi CD-ROM (& SB), & the TA CD-ROM - solved!
Reply-To: pe1chl@rabo.nl
Date: Tue, 17 May 1994 08:52:50 GMT

In <1994May16.220054.14777@radian.uucp> markbr@radian.com (mark) writes:


>Finally!

>As I posted recently, I got the TA CD-ROM, and found that the setup kernel
>recognized the CD drive, but the installed one didn't. I had trouble with
>the recompile, as well.

>The answer is:
>    in (I think it's) /etc/include/linux/drivers/blocks, there are *two*
>       makefiles. One is named Makefile, the other Makefile.orig. When
>       I diffed them, I discovered Makefile.orig *had* conditions for
>       compiling the Mitsumi driver, the Soundblaster driver, and one
>       other driver, and Makefile *didn't*. I renamed both, and reran
>       the compile. No problems, using lilo (after the usual moving & 
>       /etc/lilo/install) I boot off my hard drive, I can mount the 
>       CD ROM, etc.

It probably means something went wrong when you were patching things.
Try to re-build the source tree from a clean point.
(cd /usr/src; rm -rf linux; tar xvzf some.version.tar.gz; patch -p0 -s patches)

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

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

Crossposted-To: comp.os.linux.misc
From: hh@hhdo.ping.de (Henning Holtschneider)
Subject: Re: LOGISCAN V0.0.1 released
Date: Mon, 16 May 1994 18:05:10 GMT

CHRISTOPHER M MAY (cmay@titan.ucs.umass.edu) wrote:

> : [for those of you who don't understand enough: the author has written a
> : driver, based on the mustek driver, for the Scanman32 and Scanman+. He has
> : uploaded the file to tsx-11.mit.edu as logiscan.tar.gz]

> Hi, I have a scanman32 and it has just been collecting dust.  I was
> wondering if you knew a more exact location for this file, as I could 
> not find it on tsx-11, and 'archie logiscan.tar.gz' found no matches.

Unfortunately, I myself did not get the file by now :-( But it seems in
tsx-11's incoming because 'get incoming/logiscan.tar.gz' says "permission
denied"! Perhaps you might contact tsx-11's ftpadm?!

Greetings from Dortmund

                <-gninneH<-
-- 
      Henning Holtschneider * Bauernkamp 41 * 44339 Dortmund * Germany
          Member of OASE - European Shareware Authors Organization
  Internet: hh@hhdo.ping.de  Fidonet: 2:2444/1099  Telefax: +49 231 7285296

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


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