Subject: Linux-Development Digest #794
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:     Sat, 4 Jun 94 20:13:08 EDT

Linux-Development Digest #794, Volume #1          Sat, 4 Jun 94 20:13:08 EDT

Contents:
  Relocatable Code Quandry (Michael Schmelzer)
  Re: Frustrated with new k (Kenneth Edwards)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Ken Pizzini)
  Re: Thanks to Alan Cox & NetCrew! (Rene COUGNENC)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (jonboy)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (H. Peter Anvin)
  Re: 1.1.17 and no networking won't compile (Rob Janssen)
  Re: linux bug or HP bug? (with solution) (Rob Janssen)
  Re: Frustrated with new kernels (Elaine Walton)
  Re: Frustrated with new kernels (Elaine Walton)
  Re: Colorado Trakker 250 (Greg Broiles)
  Re: iscntrl(128) thru iscntrl(255) (Ken Pizzini)
  Legality of casting floats to shorts (David Fox)
  Re: Thanks to Alan Cox & NetCrew! (Juha Virtanen)
  AHRGH: I forgot: patch application problems? (Thomas Boutell)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Bjorn Ekwall)

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

From: mjs@jackson.neurology.wisc.edu (Michael Schmelzer)
Subject: Relocatable Code Quandry
Date: 03 Jun 1994 20:31:34 GMT
Reply-To: mjs@head.neurology.wisc.edu

[please reply to the address in my .sig!]

While trying to build InterViews, I came upon an
interesting paradox: To build shared libraries, you
need to generate position independent code, and
although GCC can emit position independent code,
the Gnu assembler can't handle it. (The gcc info file
even admits as much!)

What's going on? Aren't shared libraries a keystone of Linux?
I see .sa files all over the place. 
And isn't PIC a prerequisite to build a shared library?
If yes and yes, then how was the PIC assembled?

More to the point of my predicament: What do I lose if I
build InterViews w/o PIC?
Will I still be able to build a shared library without PIC?
Will I lose big if I can only build static libraries for InterViews?
Has anyone done anything similar?

Please send clues to the address below:
--
Mike Schmelzer mjs@head.neurology.wisc.edu (608) 265-5343
"The sun is by far the hottiesss..t planet in our solar system, and it  
 would burn, it would burn YOU if you were to eat it." - Get A Life

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

From: edwardsk@cuug.ab.ca (Kenneth Edwards)
Subject: Re: Frustrated with new k
Date: Fri, 3 Jun 1994 21:08:15 GMT

Rick Emerson (rick.emerson@dscmail.com) wrote:

: Anyway, the original post points out an ongoing problem: Where is the
: latest *reliable* kernel?  Aside from the 1.0 announcement, I can't
: recall another notice saying, in effect, "OK, gang, this kernel works
: pretty well and won't surprise you."  

Well, I have been running 0.99.13 for about a year now, and I would have
to say it is very reliable.  So, "this kernel works very well and won't
suprise you" :-).

I run NFS to SUN and HP, Xdm to run X on the SUN monitor, 2 IDE and 1 SCSI
disk, NE2000 ethernet, Colorado Jumbo 250 tape backup, SLIP to other Linux
boxes over the modem.  The system is in use daily, is rock stable.
I can't remember it ever going down without being told, and all of the
above work fine.

The new 8k NFS has me interested a little, but while my current NFS 
performance is poor, it is not causing any problems.  So what am I
missing here, why do people need to get linux.xxx only to find out 
it does not work?

Maybe someone could put together "upgrade-WHYTO" documents to tell people
when they need to upgrade.  This might quel some of the complaints about
the constantly changing nature of Linux.


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

From: ken@coho.halcyon.com (Ken Pizzini)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 1994 19:06:04 GMT

In article <2spee9$sk8@harbinger.cc.monash.edu.au>,
Kevin Lentin <kevinl@bruce.cs.monash.edu.au> wrote:
>The argument here may be whether the odd or the even kernel should have the
>greater number so that people who do not know what is going on would
>automatically take the latest stable kernel (hence the call for 1.2.0). I
>find this a bit weird. It would be real strange to be developping a kernel
>with a version lower than the stable one. To be developping 1.1.x while
>1.2.x is out is wrong. And what happens when 1.1.x is declared stable? Make
>it 1.4.0 and then the next kernel after 1.4.0 is  1.4.1 for the stable ones
>and 1.3.0 for a new feature. It would cause far more confusion than there
>is now.

Perhaps a little odd, but consider: the naive user will pick up the 1.4.x
kernel while the (presumably) clued-in kernel hackers/bleeding edge folk
work on the 1.3.x series.  I really don't think the hackers will be
confused by the inversion, and the casual users won't even know the
difference.  Sounds like a sane solution that allows the casual upgraders
to get a "stable" version without having to read any FAQ or bother
folk on the c.o.l.* groups.

Also, the 1.0.x branch gets updated quasi-independently of the 1.1.x branch,
and so would a 1.3.x and 1.4.x pair.  Just because the 1.3.x branch might
get updated more frequently doesn't make it inappropriate for it to be
the development branch.  And presumably, even in the current scheme,
whenever a new "stable release" is made from the development branch
you'd simultaneously get a 1.even.0 and 1.odd.0 release that were
identical to each other, but would diverge with their later patch levels.

Personally, I favor renaming 1.0.9 as 1.2.0 now, and then proceed
normally with the "inverted" numbering.

                --Ken Pizzini

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: Thanks to Alan Cox & NetCrew!
Date: 4 Jun 1994 14:28:05 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)

Ce brave Dances With Geeks ecrit:

> My kmem-ps is back up, and as far as I'm concerned 1.1.17 is beautiful!
> Thanks, everybody!! :)

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

So yes, thanks everybody :)

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

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

Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
From: jmmadiso@iupui.edu (jonboy)
Date: 3 Jun 94 14:32:57 -0500

In article <Cqtu2C.BzB@news.gu.se>,
people wrote stuff...

why don't the directories that have 1.0 in it just rename the dirs
stable-1.0.x
and the patches say stable-[whatever]
and others say ALPHA-1.1.x and patches
say ALPHA (or BETA, whatever they are) [whatever]?

-- 
jonM<>< jmadison@klingon.iupucs.iupui.edu; jonboy@neuromancer.ucr.edu
"I'm trapped in the zoo called America/locked in a cage called tha 'hood"
                -O.G.G. --" Before Redemption"

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

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: Sat, 4 Jun 1994 20:37:21 GMT

Followup to:  <2sqjas$fi1@nwfocus.wa.com>
By author:    ken@coho.halcyon.com (Ken Pizzini)
In newsgroup: comp.os.linux.development
> 
> Perhaps a little odd, but consider: the naive user will pick up the 1.4.x
> kernel while the (presumably) clued-in kernel hackers/bleeding edge folk
> work on the 1.3.x series.  I really don't think the hackers will be
> confused by the inversion, and the casual users won't even know the
> difference.  Sounds like a sane solution that allows the casual upgraders
> to get a "stable" version without having to read any FAQ or bother
> folk on the c.o.l.* groups.
> 
> Also, the 1.0.x branch gets updated quasi-independently of the 1.1.x branch,
> and so would a 1.3.x and 1.4.x pair.  Just because the 1.3.x branch might
> get updated more frequently doesn't make it inappropriate for it to be
> the development branch.  And presumably, even in the current scheme,
> whenever a new "stable release" is made from the development branch
> you'd simultaneously get a 1.even.0 and 1.odd.0 release that were
> identical to each other, but would diverge with their later patch levels.
> 
> Personally, I favor renaming 1.0.9 as 1.2.0 now, and then proceed
> normally with the "inverted" numbering.
> 

I suggested this to Linus before; I'd suggest it again:

For the development kernels, use something other than normal numbers,
for example letters (1.1.a, 1.1.b), Greek letters (1.1.Alpha,
1.1.Beta...) or Roman numerals (1.1(I), 1.1(II)) to mark what is
effectively an alpha test kernel.

        /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
First hug free; all subsequent ones free.

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.17 and no networking won't compile
Reply-To: pe1chl@rabo.nl
Date: Fri, 3 Jun 1994 19:02:51 GMT

In <1994Jun3.125831.42348@Lehigh.EDU> shl0@ihd117d.CC.Lehigh.EDU (Samson H. Lee) writes:

>I applied patch17 yesterday and tried recompiling the kernel.  I had
>been including network support for TCP/IP and SLIP but decided to
>remove network support until I really needed it.  (My university is in
>the process of setting a SLIP server, but it's not ready yet.)  So I
>tried leaving it out when I ran 'make config'.  I then ran 'make

[...]

>Anybody out there know what's the problem?  Let me know if this is
>unclear and I'll try to explain things in more detail.  Thanks for any
>and all help.

A previously reported problem is that the kernel won't compile when
networking is turned off.   The responsible person is probably working
on it.  For now, just enable networking.

If all people would explain their problems as well as you did, life would
be a lot easier :-)

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: linux bug or HP bug? (with solution)
Reply-To: pe1chl@rabo.nl
Date: Fri, 3 Jun 1994 19:08:07 GMT

In <2snbej$q76@sun0.urz.uni-heidelberg.de> fc4@aixfile1.urz.uni-heidelberg.de (Peter Parzer) writes:

>I had the problem that the lp driver would not recognize if my
>HP LaserJet 4p was power off. I solved this problem, at least for
>the polled version of the driver. The key of the problem was that
>the printer returned as state 0x87 when power off (state means
>the result of LP_S(minor)). The linux lp driver takes this as OK
>and assumes that the char was printed. I dont know if this is a bug
>in the lp driver or if this is a problem with HP since I have no
>idea about the official specifications of line printers.

>Another curious thing is that my HP deskjet 550c somtimes returns
>0x87 and sometimes returns 0x4f (line-off) when power-off.

This is a wellknown problem...  the status returned by the printer
port when the printer is OFF is flakey at best.  Some years ago I did
an application for MS-DOS where the client wanted reliable detection
of this situation, and it was a pain...  what worked for one printer
did not work for another :-(
Unfortunately, I can't get at the final solution now.   But I remember
it involved masking out certain bits, and then testing for a certain
combination of zeroes and ones in the masked result.  Direct compares
with values were not good.

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

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Re: Frustrated with new kernels
Date: 3 Jun 1994 21:58:45 GMT

Forgive me, but I am confused.  I understood that once a patch is made it
is not changed.  For example, from what I see above, it looks like the
developers fix the bugs found in 1.1.13 which was introduced in 1.0.9 by
repatching 1.0.9.  From what I understood, if a 1.0.9 bug was found in
1.1.18 it is fixed in 1.1.19.  This would imply that the features defined
in 1.1.19 would be fully debugged in a later patch.  The result would be
that no revision is any more stable than a previous.  The only time that
things would be clean (no out-standing defects) would be when someone says
"We want a clean version" like when 1.0.0 was formalized.

Is this correct?  Am I on drugs?  I don't have a problem with volatility.
I enjoy a challenge (except when it inadvertantly blows away years of
work).
-Sean

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Subject: Re: Frustrated with new kernels
Date: 3 Jun 1994 22:08:51 GMT

I am really surprised at the responses have gotten over this.  What
really amazes me is that I NEVER REALLY INTENDED to berail the efforts
of those who had done this service for us; I NEVER REALLY INTENDED to
imply I wanted the 1.1.* to be perfectly passable.  I just wanted to
try running the bleeding edge of the Linux-sabre 1.1.*.  I wanted to
try it out, then if it blew up my machine, I'd go back to 1.0.0.  No
regrets, no vindication.  How simply can I put it?  I wanted to
experiment; I wanted to play.

However, I was despairing over not being able to experiment.  With this
I got the support to persevere and win.

-Sean

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

From: greg@ideath.goldenbear.com (Greg Broiles)
Subject: Re: Colorado Trakker 250
Date: Sat, 4 Jun 1994 18:00:41 GMT

=====BEGIN PGP SIGNED MESSAGE=====

emrys@cellar.org (The Fool On The Hill) writes:


>       Does a driver exist to allow me to access my Trakker?  If so, could
>I please get a pointer to it?  If not, why?  Is it _that_ difficult to
>access the tape on the parallel port?  Hell, if MS can do it, we oughta be
>able to!!

On a tip from a friend, I took my Trakker 250 apart - and found what sure
looks like a normal 120/250 MB internal tape backup unit, attached to
a tiny power supply and a "parallel option board". The "p-o-b" attaches
with a connector indistinguishable from a normal floppy cable connector.
Due to complex circumstances, it isn't easy for me to test this right now
to see if it works as well as it looks like it ought to - but if you've got
a Trakker and you're itching to do a tape backup, I'd try it out. I intend
to explore further soon.


=====BEGIN PGP SIGNATURE=====
Version: 2.5

iQCVAgUBLfDBHX3YhjZY3fMNAQGBTwQAkSGPlO07FNECNWBtrl21kcdhG9HKev4s
9/SMbQkrp4K5o/qrMDVbP+p/woC2zUHLGBDOhMi3PD5AxjBfB5XR3MCj5zEDEELX
Aso9MGlOSHIramqbfU3ynEjJS50mfH+6EdBM6RcpH36QXflZ8CPiYtqAWknaoBB6
k9/vAPx6Qzk=
=hgCV
=====END PGP SIGNATURE=====
-- 
Greg Broiles                                    greg@goldenbear.com
"Over 2MB of news are posted each day. This is a staggering figure
when you consider that most news feeds are run over 1200 baud modems."
- Nemeth, et al, "Unix System Administration Handbook" (1989) 

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

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: iscntrl(128) thru iscntrl(255)
Date: 3 Jun 1994 21:58:39 GMT

In article <1994Jun3.121852.28185@excaliber.uucp>,
Joel M. Hoffman <joel@wam.umd.edu> wrote:
>I regularly program with 8-bit strings and char. constants in C under
>Linux.  The high bits are used for Hebrew.  Most s/w under Linux
>(including GCC) seems to work fine with 8bit char. strings, so it
>seems that iscntrl should be false for those high chars.

Well, in a Hebrew or Latin-1 locale one would certainly want
iscntrl() to return false on most (if not all) of the upper
128 characters.  But in the C locale (which is the default)
the implementer gets a lot of leeway.

                --Ken Pizzini

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Legality of casting floats to shorts
Date: 03 Jun 1994 19:04:53 GMT

The gdb command

 print (short)-1.49605799e+34

or 

 print (short)3e9

which casts a large negative float to a short, gives the message
"Erronious Arithmetic Operation" or something very similar.  Of
course, this is a rather erronious operation, and it could be argued
that a program that executes it is incorrect.  However, this is an
operation which is giving me floating point exceptions in programs
which run fine on SPARCs and SGIs.  I suppose this a property of the
i486 and there is no way to change the behavior, right?  Oddly,
"print (short)1e9" executes without error, I guess because 1e9
fits in an int.
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: Juha.Virtanen@hut.fi (Juha Virtanen)
Subject: Re: Thanks to Alan Cox & NetCrew!
Date: 04 Jun 1994 22:37:40 GMT
Reply-To: jiivee@hut.fi

>>>>> On 4 Jun 1994 14:28:05 GMT, rene@renux.frmug.fr.net (Rene COUGNENC) said:
:> 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...

:> So yes, thanks everybody :)

Yes, Linux-1.1.18 is a great release for term users, too. With
Linux-1.1.12 and all older kernels when I tuploaded stuff from
internet host to my linux box, term took all CPU time available,
but with 1.1.18 term takes only about one percent of CPU time.
Having load at 0.00 when term is reading stuff in at a rate of
~1900bps is great.

After tuploading about 4MB all kind of stuff plus having two
xclocks running (updates every second) from internet side and
reading news with gnus by running emacs on internet side over
txconn, term has taken only 38 seconds of CPU time! Under Linux
1.1.12 it would have taken about 80 minutes of CPU time after
same actions (or even more).

Thanks to everybody for a great job!


Juha
--
Meskimen's Law:
        There's never time to do it right, but there's always time to
        do it over.

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

From: boutell@netcom.com (Thomas Boutell)
Subject: AHRGH: I forgot: patch application problems?
Date: Sat, 4 Jun 1994 23:13:51 GMT

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.

Thought I remember what to do about this, but I don't.

How do I apply the patches correctly? And shouldn't this be
in a README in the kernel patches directory? It's not obvious
from the patch manpage, at least to me.

-T
-- 
boutell@netcom.com, purveyor of fine HTML pages to the biology trade.
FAQ-keeper for comp.infosystems.www. Drop by and learn about the Web.
<a href="http://siva.cshl.org/boutell.html"><em>Thomas Boutell</em></A>

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 94 00:03:12 GMT

Alex Ramos (ramos@engr.latech.edu) wrote:
 > Less drastic, and about as effective, would be to just put
 > a good README file in a real good place...

 > --
 > Alex Ramos (ramos@engr.latech.edu) * http://info.latech.edu/~ramos/
 > Louisiana Tech University, BSEE/Sr * These opinions are probably mine

Great idea!!!

A recurrent post in, for instance, comp.os.linux.announce, with such
information should solve the problem...  eh, hmm, well...
someone beat us to it! There is the meta-FAQ, and the Linux info sheet and....

OK, so I'm pulling your leg, sorry about that!  Here, you can have it
back, I've hardly used it at all, I just took a _small_ bite, yummy... :-)

But, I was almost serious when I suggested that the "officially stable"
release should have the highest number!  There is no way one can _force_
people to look for information in the places where they really ought to.
Flaming won't help, and only results in unfruitful threads and bad feelings.

It is quite understandable that someone who is new to Linux would want
the latest (and by the usual definition "best") release.
Now, the "oldtimers" know that the "odd" kernels are the "bleeding edge",
and for something smoother, you should look for an even one, really :-)

So let's not make it any harder for the newcomers than necessary;
let them _by default_ find the "most stable" release when they look
around on the ftp sites, or from wherever they get their kernels.


Cheers,

Bjorn Ekwall == bj0rn@blox.se

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


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