Subject: Linux-Development Digest #795
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:     Sun, 5 Jun 94 03:13:09 EDT

Linux-Development Digest #795, Volume #1          Sun, 5 Jun 94 03:13:09 EDT

Contents:
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Kevin Brown)
  Re: Frustrated with new k (Jim Robinson)
  assembly language & Linux... rep insw, esp. (David Young)
  Thanks to Alan Cox & NetCrew! (John Grosen)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Elaine Walton)
  VERY happy with 1.1.17!!! :) (Dances With Geeks)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Dances With Geeks)
  Re: Thanks to Alan Cox & NetCrew! (Blayne Puklich)
  Qlogic Scsi driver? (Adam Silverthorne)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Greg Patten)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Remco Treffkorn)
  Re: Frustrated with new kernels (Ron Smits)
  Re: Thanks to Alan Cox & NetCrew! (Jonathan Magid)
  Re: AHRGH: I forgot: patch application problems? (Rene COUGNENC)
  Re: AHRGH: I forgot: patch application problems?
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Erik Olson)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (H. Peter Anvin)

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

From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Reply-To: kevin@frobozz.sccsi.com (Kevin Brown)
Date: Sat, 4 Jun 1994 00:36:33 GMT

In article <FOX.94Jun3163636@first.cs.nyu.edu>,
David Fox <fox@graphics.cs.nyu.edu> wrote:
>In article <2snr8j$8jm@acmex.gatech.edu> gt8134b@prism.gatech.edu (Robert Sanders) writes:
>
>] Honestly, I don't see what everyone's crying about.
>
>I agree, but it is awefully hard to resist the nearly doubled
>disk speed that the 1.1 kernels offer.

So don't resist.  Instead, grab the cluster diffs in

        tsx-11.mit.edu:/pub/linux/ALPHA/scsi/cluster-1.00.tar.gz

and patch your kernel with them.  I think this also contains the bdflush
program (which replaces /etc/update).

I'm currently running 1.0.9 with the above cluster diffs installed.  You
have to know something about what you're doing (so you can resolve failed
patches), but I've got a system that works rather well, all things
considered.  I haven't had it crash on me yet, but there are certain
things about my setup (namely, the existence of a Fujitsu 2511 magneto-
optical drive) that I don't exercise very hard (with previous kernels,
I could crash my system very easily simply by accessing the serial ports
and the magneto-optical drive simultaneously.  Downloading directly to
the MO drive was a sure-fire way to crash the system).  The *reason*
I don't exercise these aspects of my system hard is that the cluster
diffs make the system a lot more prone to massive filesystem damage
upon a crash (I'm using xiafs for all my filesystems).  I completely lost
my root filesystem several times with 1.0 + cluster diffs.  So I don't
push it.

I should note, however, that I'm not doing any networking or anything like
that, so I can't say how stable this kernel is under a network load.



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

From: jimr@shorty.cs.wisc.edu (Jim Robinson)
Subject: Re: Frustrated with new k
Date: 4 Jun 1994 01:29:21 GMT

Note the redirection, this is not development, this is bitching.

In article <Cqu0r0.9MD@pe1chl.ampr.org> pe1chl@rabo.nl writes:
>In <2slqgh$6e@charm.magnus.acs.ohio-state.edu> ewalton@magnus.acs.ohio-state.edu (Elaine Walton) writes:
>
>>What I wanted was someone considerate enough to compile a package BEFORE
>>gzip'ing it into a package.  I know that these altruistic developers are
>>doing this on their own time--and I am truly grateful.  However, if they
>>want other developers--like myself, I suggest that a minimum set of
>>requirements be met before making it public.  Compilability comes to mind.
>>I mean, how am I supposed to test the work if I can't run it.
>
>I don't think anyone ever ships a package which cannot be compiled.
>However, there are so many things that can affect the success (e.g.
>version of gcc, version of include files, correctness of installation
>(symlinks), answers during "make config" etc etc) that it can easily
>happen that it won't compile.
>When someone just says "it won't compile" or "it bombs", there is very
>little that can be done.


Well, he says he posted a detailed message awhile ago.  The problem
was that in pl13 there was an undefined variable used in one of the
block driver codes.  That is something the compiler should have
caught.  Or maybe it broke during a patch, I don't know.

>Ah, you are my employer?
>Don't think anyone can answer all questions and other messages in this
>thread, especially not when the same thing comes up over and over again.
>One simply has to skip 90% of the messages and answer 10% or less to keep
>the time spent down to a reasonable level!

Very true, I have stopped reading c.o.l.h because of the amount of
*stupid* questions that are already in the FAQs.  Probably a lot of
people feel the same way, unfortunatly that means a few of the people
who have legit problems get skipped,


>- say "please answer by email because I don't have time to read this group".
>  he who has no time to read a newsgroup should not expect others to use
>  their time to answer his questions, especially not as they are usually
>  FAQ's.

I disagree about not emailing, but like I said before, some people
have legit problems not in the FAQs, and they get skipped.


>- are about a driver or piece of hardware I don't have personal experience
>  with.

Yup.

Jim

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

From: dyoung@superdec.uni.uiuc.edu (David Young)
Subject: assembly language & Linux... rep insw, esp.
Date: 4 Jun 1994 01:46:17 GMT

        I'm trying to port some assembly language written for DOS
assemblers to Linux to operate a video digitizer at high speed.

        I'm having a little luck in spite of having absolutely NO
documentation for the Linux assembler "as".

        First question: what's the syntax for "rep insw" for the
Linux assembler? It's something like rep insw %ax,%es:(%edi),
right? What is it exactly? rep insw %dx,%es:(%edi) doesnt' work....

        Where do I find documentation for the Linux assembler that covers
all of that and more?

Dave


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

From: grosen@toons.cc.ndsu.NoDak.edu (John Grosen)
Subject: Thanks to Alan Cox & NetCrew!
Date: Sat, 4 Jun 1994 01:56:20 GMT

Just a quick word of thanks to Alan Cox and all the other folks who have
done such a great job on the network code in Linux. It's been a rocky road
but it's been worth it. Tonight, I am sitting at home on my measly '386
running X, and reading news via slip from a '486 running Linux and acting as
a slip server/gateway. What more can you ask for! It's outstanding!

--
John Grosen                             grosen@toons.cc.ndsu.nodak.edu
Information Technology Services         (701) 298-1042 (Voice)
Room 208E, IACC Bldg.                   (701) 237-8541 (FAX)
North Dakota State University

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 5 Jun 1994 01:02:20 GMT

Suggestion: How about attaching a letter or a word in front of these
different versions?  For the Linux-Sabre (bleeding edge) versions use "a"
or "alpha" (e.g. 1.1.18a or 1.1.18alpha), and for the stable (but, not
completely stable (the difference between 1.0.0 ["completely stable"]
and 1.0.9 ["mostly stable"]) attach a "b" or "beta" on the version number.
For example, how about 1.0.9b or 1.0.9beta?

Another thing: I have read somethings that disturb me.  Some of the messages
in this thread imply that 1.0.* and 1.1.* is being developed/fixed/updated
in tandom.  Is this true?
-Sean

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

From: lilo@slip-2-28 (Dances With Geeks)
Subject: VERY happy with 1.1.17!!! :)
Date: 4 Jun 1994 02:30:59 GMT

Hi All,

I thought I'd put my two cents in on recent kernel development....Linux
1.1.17 is WONDERFUL!!!!  I am able to telnet in from the PC's at school for
the first time without things hanging.  The simple, easy-to-find,
easy-to-configure option to disable NAGLE is also very nice.

Thanks to everyone who has put in the usual hours on this wonderful,
wonderful kernel release!!!! :)


lilo

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

From: lilo@slip-2-28 (Dances With Geeks)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 1994 02:33:36 GMT

On Fri, 3 Jun 1994 15:08:36 GMT, Alex Frausin (alex@myhost.subdomain.domain) wrote:

> I have had my share of problems with different kerneluppgrades but by waiting
> and reading, most of the problems has been solved. My machine is filled
> with stuff (SCSI, SB16, 3Com509...) and it's sitting on the Internet.
> I have problems with SLIP at home with my machine but you don't see me whine
> about that here :-)

No, apparently you've found other things to whine about.  :(


lilo

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

From: blayne@toons.cc.ndsu.NoDak.edu (Blayne Puklich)
Subject: Re: Thanks to Alan Cox & NetCrew!
Date: Sat, 4 Jun 1994 03:19:38 GMT

John Grosen (grosen@toons.cc.ndsu.NoDak.edu) wrote:
> Just a quick word of thanks to Alan Cox and all the other folks who have
> done such a great job on the network code in Linux. It's been a rocky road
> but it's been worth it. Tonight, I am sitting at home on my measly '386
> running X, and reading news via slip from a '486 running Linux and acting as
> a slip server/gateway. What more can you ask for! It's outstanding!

> --
> John Grosen                           grosen@toons.cc.ndsu.nodak.edu
> Information Technology Services         (701) 298-1042 (Voice)
> Room 208E, IACC Bldg.                   (701) 237-8541 (FAX)
> North Dakota State University

I definitely agree with John!

My only little whine about this is related to the installation process
for dip and the net-3 stuff (and possibly other tools that aren't even
related to networking that use the same ideas).

Why can't the installation be left to the makefile?  I really would
rather deal with the usual make variables instead of having some install
script try to determine what kind of Linux I have.  In some cases things
are not installed where I'd like them to be installed using the
installation procedures that these packages come with.

Oh yeah, I could go modify the installation script.  That's the easy fix,
and I'm more than capable of doing that.

Maybe the current method is easier for those who need that kind if help.
But, for those who want things stashed in certain areas, it's a big pain
in the butt.

Why is this being done?  Am I missing something?

--
============================================================================
Blayne Puklich          I think I'm going bald...   puklich@plains.NoDak.edu
UNIX SysAdmin Leader      - Rush, 1975              ...!uunet!plains!puklich
North Dakota State U Information Technology Services   PUKLICH@PLAINS.BITNET
Fargo, ND 58105 701-237-7584
============================================================================

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

From: welkin@crl.com (Adam Silverthorne)
Subject: Qlogic Scsi driver?
Date: 3 Jun 1994 20:20:02 -0700


I heard that someone is currently working on a driver for the Qlogic
SCSI card... Does anyone know where I can find it?  Source, or whatever.


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

From: greg@loose.apana.org.au (Greg Patten)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 1994 15:32:06 +1000

bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:

>In article <1133@blox.se>, bj0rn@blox.se (Bjorn Ekwall) says:
>+---------------
>| Let us rename 1.0.9 to 1.2.0!
>+------------->8

>Only if we ever go back to fixing bugs in it.  The "stability" release is at
>the moment something of a joke.

Love those helpful, informative posts.
-- 
Greg Patten                                              Melbourne, Australia
greg@loose.apana.org.au       For information on APANA mail info@apana.org.au

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

From: remco@emc.rvt.com (Remco Treffkorn)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: Sun, 5 Jun 1994 01:45:12 GMT
Reply-To: remco@emc.rvt.com

What the heck are you talking about? There is *NO* confusion about what
kernel is the 'bleeding-edge' one. The problem is that some people can
not let their fingers off it. Remember how that thread got started?
No amount of good will can prevent people from doing 'the wrong thing'(tm)
and complaining to the net about it. 


-- 

Remco Treffkorn, DC2XT
remco@emc.rvt.com
(408) 685-1201

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

From: ron@draconia.hacktic.nl (Ron Smits)
Subject: Re: Frustrated with new kernels
Date: 03 Jun 1994 22:08:46 GMT

Sorry, but I would like to disagree, I'm now running 1.1.16 with a
fully functional network, 4.5.21 libraries and gcc 2.5.8, I havent
encountered any problems whatsoever.

The main trick is read, read and read again. All the information you
need is there. Granted you have to search abit, but it is here in the
col.* groups and it is in the different files in the kernel source
tree.

So I cant really understand the whining
--



                Ron Smits
                ron@draconia.hacktic.nl
                Ron.Smits@Netherlands.NCR.COM

/*-( My opinions are my opinions, My boss's opinions are his opinions )-*/
/*-(                They might not be the same                        )-*/

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

From: jem@sunSITE.unc.edu (Jonathan Magid)
Subject: Re: Thanks to Alan Cox & NetCrew!
Date: 5 Jun 1994 03:04:20 GMT

In article <2sq31l$lf8@renux.frmug.fr.net>,
Rene COUGNENC <cougnenc@hsc.fr.net> wrote:
>
>No, 1.1.17 is broken on 386 processors (as of 1.1.13) and nfsd is 
>randomly killed... But 1.1.18 fixes that and some other things...

1.1.18 works much better for me than any release for a long time, 
but I'm having bad problems with all network daemons- all the ones
I've tried (telnetd, rlogind, sendmail, rshd) reject all connections
(correction: ftpd is fine).

I haven't time to isolate the problem further, so I haven't said anything,
but I thought I'd throw my 2 cents in.

jem.



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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: AHRGH: I forgot: patch application problems?
Date: 4 Jun 1994 23:52:30 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Thomas Boutell ecrit:

> Forgive me, folks. I asked a month ago how to get the 1.1x patches
> to apply properly when I was upgrading to 1.1.12. Now I'm trying
> to upgrade to 1.1.18, I've forgotten what esoteric thing I
> have to do to make patch work, and patch < patch13 (for instance)
> fails to create new files.

Most kernel patches apply proprely from the /usr/src directory,
using:
                patch -p < patchfile

If you want to verify if the patch applied proprely, I suggest you 
type this:

        patch -p <patchfile  2>&1 | tee patch.log

This way everything is logged in the text file "patch.log", and you can
read it and scan for the "fail" string.

Don't be afraid by the "hmm.. looks like a new something to me" sentences,
it is normal.

> How do I apply the patches correctly? And shouldn't this be
> in a README in the kernel patches directory? 

It is !
From the file /usr/src/linux/README, line 31:

 - if you install by patching, you need a *clean* 0.99.15 source tree,
   which presumably exists in /usr/src/linux.  If so, to get the kernel
   patched, just do a

                cd /usr/src
                patch -p0 < linux-1.0.patch

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: cps1@eccles.ee.ryerson.ca ( )
Subject: Re: AHRGH: I forgot: patch application problems?
Date: 5 Jun 1994 03:48:21 GMT

Thomas Boutell (boutell@netcom.com) wrote:
: Forgive me, folks. I asked a month ago how to get the 1.1x patches
: to apply properly when I was upgrading to 1.1.12. Now I'm trying
: to upgrade to 1.1.18, I've forgotten what esoteric thing I
: have to do to make patch work, and patch < patch13 (for instance)
: fails to create new files.

I usually do a "patch -s -p1 < patch18" from within the linux source directory
(ie patch within  /usr/src/linux ).  Make sure all the patches leading up to
patch18 are done in proper order otherwise you could end up with quite a mess.

--
  ===========================================================================
 |  York Lam <-=-> cps1@cobra.megan.ryerson.ca | It's only fun until someone |
  =============================================| loses an eye... then it's   |
 |               ( free-space )                | fun for one less person.    |
  ===========================================================================
                                                                          ---

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

From: erik@homer.phys.washington.edu (Erik Olson)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 5 Jun 1994 05:01:42 GMT

>Another thing: I have read somethings that disturb me.  Some of the messages
>in this thread imply that 1.0.* and 1.1.* is being developed/fixed/updated
>in tandom.  Is this true?
>-Sean

This is true.  Bugfixes have been applied to both branches, but new
things have been introduced only in the 1.1.* branch.  If I understand
correctly, the 1.0 is a terminal branch; ie, the 1.2.0 will be the
stable version that will be derived from 1.1.*.  The patches
for 1.0 are there merely for the people who want the most stable
kernel they can get.  

  - Erik
--
---
Erik D. Olson                                olson@phys.washington.edu
Linuholic                               erik@marge.phys.washington.edu

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

From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Sun, 5 Jun 1994 06:09:25 GMT

Followup to:  <2sr86s$9v9@charm.magnus.acs.ohio-state.edu>
By author:    ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
In newsgroup: comp.os.linux.development
>
> Suggestion: How about attaching a letter or a word in front of these
> different versions?  For the Linux-Sabre (bleeding edge) versions use "a"
> or "alpha" (e.g. 1.1.18a or 1.1.18alpha), and for the stable (but, not
> completely stable (the difference between 1.0.0 ["completely stable"]
> and 1.0.9 ["mostly stable"]) attach a "b" or "beta" on the version number.
> For example, how about 1.0.9b or 1.0.9beta?
> 
> Another thing: I have read somethings that disturb me.  Some of the messages
> in this thread imply that 1.0.* and 1.1.* is being developed/fixed/updated
> in tandom.  Is this true?

Not really.  However, some *bug fixes* has been applied to the 1.0.x
branch, bringing it up to 1.0.9 by now (1.0.9 is hence *more* stable
than 1.0.0, at least theoretically).  1.1.x is the development branch;
at some point a feature-freeze will be applied to this branch (similar
to the 0.99.x feature freeze), bringing about a 1.2.x mainstream and a
1.3.x development branch.

        /hpa



-- 
INTERNET: hpa@nwu.edu               FINGER/TALK: hpa@ahab.eecs.nwu.edu
IBM MAIL: I0050052 at IBMMAIL       HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512    STORMNET:    181:294/101
"We are receiving two hundred and eighty-five thousand hails." -- Lt. Crusher

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


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