Subject: Linux-Development Digest #179
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 15 Sep 94 21:13:15 EDT

Linux-Development Digest #179, Volume #2         Thu, 15 Sep 94 21:13:15 EDT

Contents:
  Re: A thought to improve security (Jim Finnis)
  Re: Driver for NCR 53C825 on the horizon? (Janne Sinkkonen)
  Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Peter Onion)
  Re: need developer! (Don Garrett)
  Re: HELP: How to patch Slackware 2.0 to 1.1.44 Kernel (Mark P. Nelson)
  Re: DOSEMU 0.53 notes (Dan Maynard)
  Re: inb(),outb()--help? (Wolfgang Jung)
  Re: Linux v1.0 SMAIL problem (Neal Becker)
  Re: IDEA: Energy saving features for harddisks (Pete Deuel)
  Need a hand from C programmer... Please? (Bart Kindt)
  Status of Token Ring? (Todd B. Templeton)
  Re: RFD: Linux and end-users (Was: Don't use Linux?!) (Alan Cox)
  Re: 320x200 X resolution? (Andreas Matthias)
  Re: Alpha Linux (Mike Haertel)
  Re: Multiprocessing Pentium Systems (Hugh Emberson)
  Re: ET4000 and X-Windows (Jan Nicolai Langfeldt)
  Re: Don't use Linux?! (Jeff Kesselman)
  Re: File locking--gurus please read. :) (Alan Braggins)
  Re: Future of linux -- the sequel (Ken Latta)

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

From: [email-masked] (Jim Finnis)
Subject: Re: A thought to improve security
Date: Thu, 15 Sep 1994 13:57:31 GMT

In article <[email-masked]>
   [email-masked] (Alan Cox) burbled:

>
>Presumably the pyramid ones or the draft Posix (did these end up the same
>?). B2 security would be fun too.
>

I'd love to see GECOS ACL's..

Jim

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

From: [email-masked] (Janne Sinkkonen)
Crossposted-To: comp.os.linux.help
Subject: Re: Driver for NCR 53C825 on the horizon?
Date: 15 Sep 1994 16:54:24 +0300

In article <[email-masked]>,
Drew Eckhardt <[email-masked]> wrote:

>>The NCR53c810 driver works after one (minor) bug is corrected,
>>namely the removal of the [2] which had been used to dimmension
>>the pci_chip_ids[] array -

I started the driver included in 1.1.49, and the following was
required in addition to what you told:

> To: Drew Eckhardt <[email-masked]>
> Subject: Re: Driver for NCR 53C825 on the horizon?
> Date: Wed, 14 Sep 94 22:10 EET DST
> 
> 
> I got it working! A little fiddling was required, however:
> 
> - in bios32.c, bios32_init():
> 
>    for (check = (union bios32 *) 0xe0000; check <= (union bios32 *) 0xefff0; ++check) {
> 
>   The change of the upper address limit was necessary to prevent
>   it finding double signature.
> 
> - And in 53c7,8xx.c, the "case 825" line was missing:
> 
>       switch (hostdata->chip) {
>     case 810:
>     case 815:
>     case 825:
>         hostdata->dstat_sir_intr = NCR53c8x0_dstat_sir_intr;
>         hostdata->init_save_regs = NULL;
>         hostdata->dsa_fixup = NCR53c8xx_dsa_fixup;
> 
> This was with an Inter Premiere 2, P5/90

--
Janne

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

From: [email-masked] (Peter Onion)
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
Date: 15 Sep 1994 16:15:18 GMT

In article <[email-masked]>, [email-masked] (Mark 
Evans) says:

>Have you tried recompiling tin with the NNTP extensions disabled?

The problem is a bit more fundamental than that!  The WNOS NNTP server 
seems incapable of dealing with some basic requests.  I cant remember 
exactly the commands but it revolved around WNOS not taking any notice of 
parameters to command like HEAD, TAIL, BODY etc......

I don't think its the NNTP extensions that are the problem (but I may be 
wrong!)

Peter Onion G0DZB.

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

From: [email-masked] (Don Garrett)
Subject: Re: need developer!
Date: 14 Sep 1994 04:20:17 GMT

Humenberger Edmund ([email-masked]) wrote:
: You should implement for a phone interface card
: an device driver.
: You will get the card, all support from the
: manufactor and money from me. the driver will
: be free.

: email your answer. ed

  Can you nail down just what you mean by 'phone interface card'? Do
you mean voice mail? And what card? Do you get to pick our favorite,
or do you have a particular one in mind?

  I don't have much free time. But if you're not in a big hurry, I'm
game. 

--
Don Garrett                                                   Louisiana Tech
[email-masked]                                      University
                  http://info.latech.edu/~dgarrett/

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

From: [email-masked] (Mark P. Nelson)
Subject: Re: HELP: How to patch Slackware 2.0 to 1.1.44 Kernel
Date: 15 Sep 1994 21:33:20 GMT
Reply-To: [email-masked]

Chris Wong (chris@helser54) wrote:

: Is the following right?

: cd /usr/src/linux
: patch < $patchFileDir/patchfile

No.

cd /usr/src

patch -s -p0 </patchpath/patchfile

--
Mark P. Nelson ([email-masked])
                         While I'll admit that anyone can make a mistake once,
                         to go on making the same lethal errors century after
                         century seems to me nothing short of deliberate.--V.

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

From: [email-masked] (Dan Maynard)
Subject: Re: DOSEMU 0.53 notes
Date: Wed, 14 Sep 1994 01:59:48 GMT

: >: 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.  

with the ATI GUP - 

ports { 0x1ce 0x1cf }

cleared up my lock-up problem in FULL graphics mode

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

From: [email-masked] (Wolfgang Jung)
Subject: Re: inb(),outb()--help?
Date: 15 Sep 1994 13:37:23 +0200

Steve Larsen ([email-masked]) wrote:
: Hi:
:   I would like to write a modem diagnostic program for Linux of the sort
: I used to write for DOS in assembler.  But I don't want to write in assembler.
: I want to use C, and am admittedly no wiz. Anyway, I 'ioperm' the correct
: ports, then go to use inb(), and get the "undefined reference to __inb_p()"
: message, or something to that affect, so I know it's tracing it back to
: asm/io.h. Am I leaving out an include file, or do I have to fill out the
: port call w/some sort of define? A one or 2 line example of code would
: be greatly appreciated!

Do you really need to program the hardware for the modem diagnostics ?
If you just need to talk to the Modem, use open/read/write , termios, etc
(You can select everything without programming the hardware (The Kernel does
this for you....)

-- 
===============================================================================
| Gruss                 |ISO-8859-1 Mail: [email-masked]              |
|       Wolfgang        |                 [email-masked]               |
|       Jung            |                 [email-masked]                |
|                       |             [email-masked]       |
===============================================================================

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

From: [email-masked] (Neal Becker)
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,comp.os.linux.prog,dc.org.linux-users
Subject: Re: Linux v1.0 SMAIL problem
Date: 15 Sep 1994 03:13:11 GMT

Did you really want uucp_neighbors?  How about removing the offending
router?

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

From: [email-masked] (Pete Deuel)
Subject: Re: IDEA: Energy saving features for harddisks
Date: Wed, 14 Sep 1994 02:29:11 GMT

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

>  And wouldn't it be great to be able to proudly say "Linux supports
>the EPA (or whatever the latest three letter acronym is) specification."

And don't forget the "The EPA doesn't officially endorse any product." 
slogan...

Catchy, eh?   ;)

Pete
===================================================
     "Actually, I'm a lab mouse on stilts..."

     E-mail:  [email-masked]
===================================================

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

From: [email-masked] (Bart Kindt)
Subject: Need a hand from C programmer... Please?
Date: Fri, 16 Sep 1994 16:53:16 GMT

Hi. I need a bit of help from somebody with C (and Kernel) experience.
For the last 3 months I have been trying to fix a serious (for me) problem 
with a tiny wee program called "sliplogin". The program is used here for a 
multiline dial-in server.  It works fine, *except* that it sometimes does not 
*kill* itself after the dial-in user has disconnected. This especially seems 
to happen when there is still traffic going over the SLIP line.  The problem 
is, that the sliplogin program 'hangs' in the " close(0) " function.

That part of the source looks like this:

system(.....);  execute the slip.logout script; This takes the Route/ Arp out.
close(0);  The program does sometimes *not return* from this function!
exit(1); This kills the program, but is often not reached!

Now I have been told that the close(0) function is not properly implemented in 
Linux. It does not flush the buffers, but only waits 60 seconds before it 
returns. I don't know if this is true, but what I would like to do, is 
manually *flush* all data in the buffers, send reset commands to all open 
TCP/IP connections, and *then* close the port.  Is this possible? Or is there 
an other way to solve this problem?

If you can help me, please reply by E-Mail, and I will send you the complete 
source (which is only 300 lines).  

This is very important to me, because every time it happens, the dial-in line 
does not answer anymore, and if it is the 'master' line, due to the Telecom 
Stepping system, my entire Internet Server is down until I mannualy KILL the 
hanging Sliplogin program.

If you can do anything to help me, please do!

Greetings, Bart.

==============================================================================
Bart Kindt, System Supervisor, Efficient Software NZ LTD, Dunedin, New Zealand
Amateur Radio:  ZL4FOX / PA2FOX
==============================================================================

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

From: [email-masked] (Todd B. Templeton)
Subject: Status of Token Ring?
Reply-To: [email-masked] (Todd B. Templeton)
Date: Thu, 15 Sep 1994 21:39:14 GMT

What is the status of the project to support Token Ring NICs?  Is this 
progressing?  We have just loaded up Linux and are *VERY* impressed but our
LAN is strictly Token-Ring.  We would be very glad to participate in this
effort as a beta test site--i.e., volunteer--aaaaaghhh!  :-).  Seriously,
if test sites are needed, we are more than willing to help out.

Our network has approximately 300 nodes, running IPX and TCP/IP with an 
Internet connection (if that's not obvious) via a Livingston router and
several wide-area network connections via Wellfleet routers.  We can 
probably give the driver a fairly good stress test.  If interested, please
E-Mail me at [email-masked]

Thanks...

-- 
<------------------------------------------------------------------------------>
Todd Templeton         | All opinions are solely my own and do not reflect the
Lead Software Engineer | views of Phelps Dodge Corporation or its management.
<------------------------------------------------------------------------------>

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

From: [email-masked] (Alan Cox)
Subject: Re: RFD: Linux and end-users (Was: Don't use Linux?!)
Date: Thu, 15 Sep 1994 16:29:23 GMT

In article <[email-masked]> [email-masked] (Michael Schumacher) writes:
>versions of the C library. If a customer purchases your database and is
>not able to get things running, he will definitely make YOU responsible
>for that, even though the problems are not caused by your database code.

Vendors are used to this. Most are very good. We had numerous no longer
works with windows 3.1 software (and a load of networking stuff win 3.11
really took out). Most vendors seem to expect this and were helpful, others
were not 8). I don't see it as a Linux problem.

On stability. Except for a few bugs that were faults in the program
concerned (old route etc) everything I have from Slackware 1.1 runs
faultlessly under libc4.5.26, most claims to be relative to libc 4.1. I
did some tests with even older incompatible stuff using libc2.2.2 and those
when libc2.2.2 is still installed also work fine.

That to mean says stable enough to work with. There is one counter example
which is the massive changes to the C++ libraries, which coupled with the
fact that g++ 2.5.8 is a bit of a bug hazard broke  the parc place stuff
as Warner Losh has explained.

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

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

Crossposted-To: comp.os.linux.misc
From: [email-masked] (Andreas Matthias)
Subject: Re: 320x200 X resolution?
Date: Thu, 15 Sep 1994 02:25:43 GMT

Stephen Collyer ([email-masked]) wrote:

: |> : "320x200"       25      320 344 376 400         200 204 206 225

: I don't see how these values work. With a 25 MHz clock, with total V. lines =
: 400, and total H. lines 225, we're looking at a refresh rate of roughly
: 25E6 / (400 x 1.1 x 225 x 1.05) = 240 
: This is way above the spec of any monitor I'm familiar with. Or am I missing 
: something obvious ? 

I posted a similar mode line a few days ago, and got similar comments.

I don't know why such modes work, but obviously they _DO_ on some monitors.
My AOC 17'' let me play for a whole night in that resolution, without
complaining or showing discomfort. It still works perfectly, and the AOC
is a very cheap monitor, nothing special.

I suppose that the monitor hardware detects the undisplayable refresh
rate and perhaps displays only every fourth frame or so.

Ciao,

Andreas

--
Andreas Matthias <[email-masked]>

Zehntenstr.9 
D-37120 Bovenden

Voice: +49/551/81377

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

From: [email-masked] (Mike Haertel)
Subject: Re: Alpha Linux
Date: 15 Sep 1994 20:22:45 GMT

In article <[email-masked]> [email-masked] (Toshiyasu Morita) writes:
>Nope, if I remember correcty the 68000 and 68008 technically have a 16-bit
>ALU. If you don't believe me, look at the cycle counts for the 68000 when
>doing 8/16 bit adds versus 32 bit adds...the 32-bit add takes an extra
>4 clock cycles because it has to run the data the high word through the
>ALU as well, even on register-to-register operatoions.

Sorry, this is bogus, you are wrong.

The 68000 and 68008 both have a 32 bit ALU.

The extra 4 cycles (on the 68000) come when loading 32-bit values
from memory, where the cost is 4 cycles per 16-bit word loaded.
I assume on a 68008 the cost would be an extra 8 cycles.

Thus: a 32-bit register->register add is just as fast as a 16-bit one.
But a 32-bit memory->register or immediate->register is 4 (or 8)
cycles slower.

Why the heck are we talking about this in comp.os.linux?
--
Mike Haertel <[email-masked]>
Not speaking for Intel.

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

From: [email-masked] (Hugh Emberson)
Subject: Re: Multiprocessing Pentium Systems
Date: 14 Sep 1994 02:30:56 GMT
Reply-To: [email-masked]

>>>>> "Don" == Don Waugaman <[email-masked]> writes:

Don> Spinlocks typically involve busywaiting - tying up the CPU that
Don> is spinning on the lock for an (often prolonged) period of time.
Don> This is why spinlocks are typically used for situations where the
Don> lock will be held for a short period of time.

Don> A mutex, on the other hand, guarantees mutual exclusion by
Don> placing threads waiting on the lock on a queue, then starting
Don> another thread that is ready to run.  Thus, useful work can be
Don> done rather than having the thread waiting on the lock taking up
Don> useless CPU (and bus) cycles by spinning.

Don> I would guess that Sun used a mutex (as you said) and not a
Don> spinlock (as Scott said).

Just a clarification:
        I said "spinlock".  
        Scott said "no can't be".  
        Local SunOS expert said "mutex", 
        so I silently changed it to "mutex" in my second post.

Actually I think that a mutex is anything that guarantees mutual
exclusion.  So a spinlock which busy waits, and a semaphore which
queues processes are both mutexes.  Thats my definition anyway, until
I find a better one :-)

I think 4.1.3 actually uses a spinlock, but I could be wrong.

Cheers,
        Hugh
-- 
Hugh Emberson              | ... from the end of the Information 
[email-masked] | Super-four-wheel-drive-track.

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

From: [email-masked] (Jan Nicolai Langfeldt)
Crossposted-To: comp.os.linux.help
Subject: Re: ET4000 and X-Windows
Date: 15 Sep 1994 19:46:43 +0200

In article <[email-masked]>, [email-masked] (Hubert Ertl) writes:
> Knows anyone out there how to set up a ET4000 card  for X-Windows?
> I get max. 1024x768 at 60 Hz out of it in Xconfig.
> 
> 
> How can i get the 1024x768 at 70 Hz mode?

This depends on what clocks your card has.  It would help
if you told us that.

BTW. This definitly does not belong in comp.os.linux.development,
followups directed to comp.os.linux.help.

Nicolai

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

From: [email-masked] (Jeff Kesselman)
Subject: Re: Don't use Linux?!
Date: Thu, 15 Sep 1994 03:00:56 GMT

In article <[email-masked]> [email-masked] writes:
>>>> On 13 Sep 1994 14:08:55 -0700, [email-masked] (Bill Hogan) said:
>
>
>I also suspect that there is yet another reason why DOS software is not ported
>to unices; such software is designed usually for naive users who have no
>inkling as to how their computer works, and would like to turn it on and off
>like a household appliance.  Linux is currently only available for a PC.  Most

In general Mike, I agreed with you.  it is not true, necessarily, though
that DOs software doesn't get ported to Unices (pl. of Unix?  neat!).
I have a terrific version of MS-WORD for SCO.  My copy is a little old, 
and i don't know if there are newer version, but it still has alot to 
recommend it.  It runs off of curses so any dial in user can use it, runs 
multi-user no problem, talks to the Unix print queue nicely, and otherwise 
is an almost exact replica of the same vintage OS version.

Its a terrific product, and I intend to install it on my new Linux system 
after IBCS becomes stable.

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

From: [email-masked] (Alan Braggins)
Subject: Re: File locking--gurus please read. :)
Date: Tue, 13 Sep 1994 11:21:34 GMT

In article <[email-masked]> [email-masked] (Ben Eng) writes:
>   if the process is able to deal with it properly.  Additionally, your
>   processes can always avoid deadlocks by agreeing on an ordering
>   convention when applying locks to multiple files.   (Say your
>   relations are identified by an internal numbering scheme, then you
>   would always apply non-blocking locks in ascending or decending
>   relation number order.)

This tends to mean either each transaction has to already know the
results of its queries, or it has to lock more stuff than necessary.
Optimistic strategies with deadlock detection give better concurrency
in most situations.
--
Alan Braggins  [email-masked]  [email-masked]
"Any technology distinguishable from magic is insufficiently advanced"

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

From: Ken Latta <[email-masked]>
Subject: Re: Future of linux -- the sequel
Date: Thu, 15 Sep 94 14:13:46 PDT

In article <[email-masked]>, <[email-masked]> writes:
> >>>>> [email-masked] (Shannon Hendrix) wrote:
> 
> Shannon> The IDE interface is not good for multiple drives but most of
> Shannon> my accesses come from one drive.  IDE is 16-bits, SCSI is 8
> Shannon> so unless you have multple drives and put them under a severe
> Shannon> load, the Sun's I use are slightly slower (a lot slower in
> Shannon> some cases).
> 
> Don't confuse the disk <-> controller speed with the controller <->
> memory/cpu speed.
> 
> I believe that IDE is *1* bit at a time between the controller and
> disk.

This is true only if you accept the idea that an IDE "controller" is 
actually embedded in the drive electronics. The data bus between the 
controller and the bus adapter is 8 bits wide. In the case of the common 
inexpensive devices, the bus adapter is just that, a bus buffering and 
level translation device. 
 
> SCSI is 8 bits at a time.
> 
> IDE is 16 bits at a time between the controller and memory/cpu.
> 
> SCSI depends on the controller (my controller transfers 32 bits at a
> time between the controller and memory).
> 

Many IDE adapters support only 8-bit ISA bus transfers, but more expensive 
ones use 16 and 32 bit bus transfers. Some even have logic to support 
multiblock transfers or caching to enhance performance.

SCSI can do much better than IDE on multidisk operations because it can 
issue commands to multiple disks for concurrent execution. IDE only allows 
one drive to be active at a time.

Ken Latta
UNIX Systems Consultant
[email-masked]

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

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