Subject: Linux-Development Digest #820
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, 12 Jun 94 07:13:03 EDT

Linux-Development Digest #820, Volume #1         Sun, 12 Jun 94 07:13:03 EDT

Contents:
  beginners question to Xlib programming (PETERSEN KIRK A)
  SLIP panic still with 1.1.19! (was Re: Bugs in 1.18) (Frank Lofaro)
  MOD player for linux? (Steve Havelka)
  Re: Book on PC architecture (Archie Cobbs)
  Re: assembly language & Linux (ATTN!) (H. Peter Anvin)
  Re: Linux game development (Was Re: Why [DOS, W (David Kastrup)
  Re: Filesystem semantics protecting meta data ... and users data (Matthew Dillon)
  Re: sb/rb package? (Rick Narron)
  Re: Filesystem semantics protecting meta data ... and users data (Totally Lost)
  Re: My problem? GCC problem? Linux problem? (Dan Pop)
  Re: MOD player for linux? (Mikael Nordqvist)

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

From: un17@clark.edu (PETERSEN KIRK A)
Subject: beginners question to Xlib programming
Date: 11 Jun 1994 20:23:18 -0700


        I have just started reading about programming Xwindows and I have
had some problems.  when I try to compile a program with some Xlib function
calls, it compiles but runs into a problem during the linking stage (I think)

        I compile with the following command line:

gcc -ansi -O2 -m486 -o prog -lX11 main.c

and I get the following errors

/tmp/cca005581.o:  Undefined symbol _XOpenDisplay referenced from text segment
/tmp/cca005581.o:  Undefined symbol _XDisplayName referenced from text segment
/tmp/cca005581.o:  Undefined symbol _XCreateSimpleWindow referenced...
and so on

        Any ideas?

Kirk Petersen
un17@clark.edu

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: SLIP panic still with 1.1.19! (was Re: Bugs in 1.18)
Date: Fri, 10 Jun 94 04:52:58 GMT

In article <10251@gos.ukc.ac.uk> sjwk@ukc.ac.uk (S.J.W.Kersley) writes:
>After fiddling about with 1.1.18. I have noticed the following
>problems:
>
>Performing a flood-ping (ping -f) on a machine connected via
>a SLIP link caused the linux box to die horribly with 3 or 4
>'Killing interrupt handler' panics
>[...]

ping -l 100 slipservername

ALWAYS panics any Linux kernel 1.1.x with x>12. And all the older kernels 
I tested if the new tty patches are put in (they were mainstreamed in 1.1.13)

INCLUDING 1.1.19.

At least for me. I have a 9600bps modem on cua1 with a 16550A.

This is really bad. I am considering backing down to 1.1.12 (without any tty 
patches) so I don't have to worry about it.

(Sorry if this sounds like a bitch, I don't mean it to be. I am just a bit 
frustrated and disappointed each new kernel I get. I am currently just
testing networking for now, but I'll be on the net full time soon and 
I want something that doesn't panic, especially after I start accessing 
it remotely and also, I'd not want to lose my fs after I load it full of 
software, etc from the net).

Anyway, the panic is in:

0x173903 <sl_xmit+107>: movb   0x52(%ebx),%al

Which is in linux/drivers/net/slip.c, sl_xmit():

        if (skb->free)                      <- This dereference
                kfree_skb(skb, FREE_WRITE);

When it blows up, skb == 1 ! (NOT GOOD!)

I hope this helps.


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

From: shavelk@agora.rdrop.com (Steve Havelka)
Subject: MOD player for linux?
Date: Sun, 12 Jun 1994 03:15:56 GMT

Subject says it all.  Thanks...

--
        -Steve Havelka (Flam)
          shavelk@agora.rain.com

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

From: archie@qin.CS.Berkeley.EDU (Archie Cobbs)
Subject: Re: Book on PC architecture
Date: 10 Jun 94 06:12:15 GMT

cemeier@magnus.acs.ohio-state.edu (Charles E Meier) writes:

>I've often wondered why some knowledgeable engineer hasn't gathered all of 
>this material into a single book that explains how all the various chips
>work together to become a whole PC compatible machine.  Or have I missed 
>_The Ultimate PC Hardware Reference Book_ in my perusal of the shelves of
>the local bookstores?

For the purpose of designing a PC card, ISA, EISA, etc. the book
to get is by Edward Solari, _ISA and EISA Theory and Operation_.

Warning: it's expensive.

-Archie


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

From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: assembly language & Linux (ATTN!)
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Sun, 12 Jun 1994 05:06:41 GMT

Followup to:  <2t7g2b$dq8@gradient.gradient.com>
By author:    phil@gradient.com
In newsgroup: comp.os.linux.development
> 
>       I would like to place a request that future Linux authors
> use as little assembly as possible in their programs. This is primarily
> due to the fact that the Atari and Amiga ports of Linux are progressing
> very rapidly. It is conceivable that someday in the future, the source
> bases will be merged. 
> 
>       Us 680x0 people thank you,
> 

Now if you, as the original poster, is developing a device driver, it
shouldn't make a difference anyway.  You're not going to be able to
use a 386 card in an Atari or Amiga no matter what.

Does the 680x0 port include Mac support?

        /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
WWW hyplan available at <http://www.eecs.nwu.edu/hpa/plan.html>

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

From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: Linux game development (Was Re: Why [DOS, W
Date: 12 Jun 1994 07:17:09 GMT

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

>In article <2sv8v5$oan@rztsun.tu-harburg.de>, behnke@tu-harburg.d400.de (Lutz Behnke HiWi) says:
>+---------------
>| could you please state your dislikes with the g++ and tell me what single
>| other compiler beats all that?
>+------------->8

>g++ 2.5.x is broken, ask the OI folks...  Supposedly the current development
>snapshot works properly; let us hope they release it before they break it
>again...  For that matter, bugs in g++ 2.4.x aborted an attempt to make a C++
>Linux kernel some time ago.

As far as I remember OI discussions on various threads, the problem with
g++ was that when a derived class redeclared some overloaded function,
all overloaded functions of same name but different arguments from
base classes were ignored in that class.

Now while this might be a nuisance for OI compiling, it is proper ANSI
behaviour.

However, this is just from hearsay, and I will not guarantee that this
was the only problem, or at all a problem. It is just what I recollected
in the back of my head. Others might be more competent to tell.

As to the C++ Linux kernel: it is a pity development had to go back to
C, as a lot of things could be more nicely done in C++, but the fact
*is* that g++ compiler quality is lots worse than gcc. gcc gives hosts
of warnings for dubious constructs, g++ hardly at all. gcc compiles
lots faster. The parser of g++ is a mess, which results in the
two step forwards, one step back, syndrom in bug fixes.

Some bug fixes tend to be symptomatically fixed by hacks, driving the level
of problems appearing hack for hack to more complicated constructs,
instead of getting at the roots of the problem. Again, this is my
subjective impression. But it is often the case that single constructs
work in g++ (also single syntactic constructs), whereas certain
combinations result in run-time or compile errors.

Part of this is fault of a mod-boggingly complex language definition,
part of it I have the feeling comes from an unsuitable design. Again,
just personal impressions.

Although I resent going back to gcc instead of g++ for Kernel development,
it was a necessary step in order to ensure quality of the kernel code.
-- 
 David Kastrup        dak@pool.informatik.rwth-aachen.de          
 Tel: +49-241-72419 Fax: +49-241-79502
 Goethestr. 20, D-52064 Aachen

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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 11 Jun 1994 13:08:22 -0700

In article <33f7bla@qnx.com> waflowers@qnx.com (Bill Flowers) writes:
:In article <idletimeCqzHAL.I59@netcom.com>,
:Totally Lost <idletime@netcom.com> wrote:
:>In article <1994Jun6.073403.4235@wavehh.hanse.de>,
:>Martin Cracauer <cracauer@wavehh.hanse.de> wrote:
:>>SunOS-4.1.3 has a policy to have asynchronous writes for data, but
:>>...
:>
:>Both of these policies are stupidly wrong from a security stand point,
:>...
:
:The first policy does open a security hole, but U**x systems are not
:...

    This whole thread is silly.  You people are talking about security
    concerns related to a tiny window that may occur during a crash.

    I submit that the argument is centered around the wrong thing.  The 
    problem with most UNIX's today is really their monolithic nature.  
    Too much junk is being shoved into a common supervisor address space 
    the result of which is that a single bug in a single subsystem can 
    corrupt or crash the entire core.  

    Before you throw all your resources at this filesystem 'bug', you
    should realize that the problem is much greater then the one little
    side effect that rarely occurs in UFS based filesystem designs.  I,
    personally, would rather throw my resources into solving the basic
    problem -- the kernel design.

    For the record, I believe that something like Mach is a good first
    attempt, but personally I think the designers concentrated on all the
    wrong things.  I'm amazed at how much unecessary locking is done in
    Mach... people don't seem to grasp the fact that the critical path in
    FIFOs and QUEUEs can *easily* be implemented without locking.  For
    example, a reentrant queuing routine for an interrupt subsystem can
    generally be implemented like this:

        addq.l  #4,QueuePointer         ; allocate position somewhere in Q
        move.l  QueuePointer,A0         ; top down address pointer
loop    tst.l   -(A0)                   ; find unused position
        bne     loop                    ; (critical path: no looping occurs)
        move.l  D0,(A0)                 ; write data to queue

    The key to divorcing low level device drivers from a monolothic kernel
    is task switching overhead, but I have yet to see anybody seriously
    address the issue.  I see no reason why you wouldn't be able to get the
    same or better efficiency out of a filesystem by having a process (i.e.
    protected address space) for each mounted partition and a process 
    for the low level device driver.  The result of such a scheme is the
    ability to eliminate most of the semaphores and other locking mechanisms
    that would otherwise be required in a monolithic design.  Most importantly,
    the critical 'bug' path goes from the 600K monolithic kernel to the 60K
    microkernel core, the 20K filesystem process, and the 5K device driver
    process... even if your system 'crashes' to an user-unusable state, the
    chances of filesystem corruption are drastically reduced.

    Considering that the complexity of kernels goes up every year, this is
    the only real solution.  The fact that a microkernel-based environment
    can better take advantage of a multi-processor situation is just icing
    on the cake.

                                                -Matt


-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


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

From: rexx@netcom.com (Rick Narron)
Subject: Re: sb/rb package?
Date: Sat, 11 Jun 1994 01:52:12 GMT

Ken Kai-Fu CHANG (kenchang@mundil.cs.mu.OZ.AU) wrote:
: Is there any sb/rb (Ymodem) package availble for Linux?

Ken,

  While putting together my Zmodem package, I found that besides the sz and
rz modules, there were rb and sb symbolic links.

  I haven't tried ymodem but it seems that the zmodem package includes ymodem.

  On my system the zmodem package is called rzsz-3.34.tar.gz.

  Sunsite (sunsite.unc.edu) has a packaged called rzsz-9204.tar.gz that might
work too.  It is in the /pub/Linux/apps/comm  directory.

Regards, 
Rick Narron (rexx@netcom.com)
-- 
      _------_
     /        \_____
    /    o          \                               
    |      /^^^^^^^^^
     \     \
      \     ^^^^^^^^^/                              
      /       ______/
     /        \                                     
 ---oOOo------oOOo--------------------------------
 |   |   |___|___|   |___|  _|  _|   |__ |__ |   |  I may be a dinosaur   
 |   |   / ___  /|  / ___/  \ \/ /   |\ \/ / |   |  but I can still byte!
 |   |  / /_ / / | / /_  |   \  /|   | \  /  |   |
 |   | /   ___/  |/ ___/ |   /  \|   | /  \  |   |    Rick Narron
 |   |/ /\ \ |   / /___  |  / /\ \   |/ /\ \ |   |
 |   /_/ |\_\|  /_____/  | /_/  \_\  /_/ |\_\|   |    rexx@netcom.com
     |   |   |   |   |   |   |   |   |   |   |   |

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

Crossposted-To: comp.benchmarks,comp.sys.sun.admin
From: idletime@netcom.com (Totally Lost)
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: Sat, 11 Jun 1994 01:53:04 GMT

Ahhh the vular keyboard emailer finally decided to spare the audience
insults directed at me will completely avoiding any techinical
discussion.

Batter number two up, and his first swing is:

In article <2t6870$bg8@news.cfi.waseda.ac.jp>,
Alexander During <63912i@cfi.waseda.ac.jp> wrote:
>>>I've raised this point a dozen times, even at the usenix meeting where the
>>>Berkeley guys first presented their concept of sync written meta data ...
>>>and they didn't have a clue since they were one-tracked on making the
>>>system clean from fsck point of view ... not from the users or data base
>>>managers point of view. If the users/production data is corrupt, the
>>>filesystem is corrupt!! PERIOD!!
>
>I think it is about time to stop that silly thread. Apart from the rather
>disgusting style of 'idletime's postings, the discussion is rather far-
>fetched. The point is: There are circumstances under which a filesystem
>can be harmed by system crashes. The likelyhood of such an event depends
>on a) the typical crash frequency, which is determined by the skill of
>the sysadmin and the OS, as well by the hardware, and b) the stability
>of the filesystem under such crashes, which depends on the kind of crash
>and the FS itself.

Reliablity, operational integrity, and security are never silly.
(carefully avoiding the production word the writer has a hard time about)

The point really is that nearly every unix system shipped today
will needlessly exposue the user community to corruption and security
problems ... these probelms can be greatly removed, if not mitigated
by, a correct filesystem design. This is not a silly discussion,
but rather on that is 12 years overdue from my view point.

Since the guy wants to talk statisics we can do that to ...

If the probability that metadata gets written before the data blocks
is one (sync writes) and the probability of corruption during a crash is
.03 to .1 (my guess) then accross a comunity of 4 million machines with
one crash a year, then approximately 120K to 400K potential security
or corruption events happen each year.

If your reduced the probability to approximately zero then none should
occur of this failure type. That is kinda a noticable change guy.
 
Of course other events occur like head crashes which destroy data on disk
that can not be controlled. But thats a hardware problem :) ... or is it?
(I have a nice tirade on how UFS causes premature disk failure too...)

>First and foremost, no FS is save against a head scrubbing over the HD,
>so there is no perfect way out. It may be useful to argue which risks
>are more worthy to protect against, but this thread is seemingly not
>directed at that kind of analysis.

And we are all going to die some day, so just give up now ???
Since you raised the point ... lets hear the analysis please,
most of us off the back of the cuff already reached what we think
is the right conclusion.

What point are you tring to make? this statement as it's stands is
simply smoke to blur the issue since you failed to provide enough data
to even validate your point, if there was one.

>
>The main problem involved is a tradeoff between time and security. A
>filesystem that writes synchronously (like DOS) forces the hardware
>to read a sector, change one byte and write that sector back each time
>a byte is written, which is slow. It is not perfectly safe, however,
>which is something everybody who has worked under DOS will readily
>agree with. So asynchronous writes have the undisputable advantage of
>being faster, while aggravate the severity of crashes, that still may
>well harm even completely synchronous writes.

I have several times stated that this is not necessarily a trade-off
at all ... and that the correct algorithm will suppress needless
metat date writes the current algorithms require to achieve fsck level
reliablity. I will also add up to 30% additional overhead due to
other side-effects of this policy which when translated to time
due to mechanical delays for seek and rotation reduce certain classes
of applications thruput by as much as 95% (read 1/20th).

And asyncronous ordered writes are the best of both worlds. Faster than
both fully syncronous or just syncronous metadata.

>From one of the enlightening postings of Mr. idletime, we could gain the
>fact that he has experienced 3 losses of data in 19 years. This is not
>something that I would call a risk. Please consider the likelyhood of
>getting run over by a car in 19 years which you spend by crossing a
>street 8 hours a day. I bet you'd get run over more often (nowadays
>probably only once, however), and still you do it. There are just 
>chances that one has to take.

And you may have looked at the words, but certainly didn't think about
what was said. I know of 3 security breaches caused by this, and a
number of corruptions. I suspect atleast the same number (or larger)
of breaches occured where the receipient didn't care to disclose the
new found wealth. Since I am only one person, if you multiply that times
the number of other sysadmins who are not looking for such or reporting
such, we have a huge number per year again. And for what reason?
carelessness as far as I am concerned.

If you lay in the middle of  the freeway or train tracks for 5 minutes
a day you have have some probability of getting run over ... if that
is on a freeway at rush hour the probablity is near one. If that
is midnight on a siding that hasn't been used in ten years it is near zero.
I'll take my chances with the siding. Choosing a high probablity
event is stupid.


>In my opinion there is nothing much to discuss. idletime has raised that
>point a dozen times infront of experts and they probably threw him out
>and so he tries to infest this newsgroup. Just let him have his fun, but
>don't waste the time of the people who read this for information by 
>posting too many replies; it's getting annoying.

I believe the world is round, which is a pretty safe bet today.
Not that long in the past such mutterings could cost your life.
Even today some continue to declare the world flat, we call them
fools.

We each pick who we trust as experts, with experience this
usually becomes a task of reasoned care.

I think this is officially strike one, do you care to accept the
bait and attempt to reclaim your honor defending your position?

>
>Just my 2 Yen.

and at the current exchange rate what fraction of 2 cents is that ...
hmm let's see ...


batter up ....
John

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

From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Re: My problem? GCC problem? Linux problem?
Date: Sat, 11 Jun 1994 01:18:24 GMT

In <jameslCr7Btw.Kw4@netcom.com> jamesl@netcom.com (James Logajan) writes:

>Wayne Throop (throopw%sheol@concert.net) wrote:
>: ::     void main() { example("Hello!"); }
>
>: It probably doesn't cause your sigsegv on linux,
>: but it may be worth noting that defining main to return void
>: is illegal in C, and always has been.  Borrowing from the
>: comp.lang.c FAQ:
>
>: 5.12:        Can I declare main as void, to shut off these annoying "main
>:      returns no value" messages?  (I'm calling exit(), so main
>:      doesn't return.)
>
>: A:   No.  main must be declared as returning an int, and as taking
>:      either zero or two arguments (of the appropriate type).  If
>:      you're calling exit() but still getting warnings, you'll have to
>:      insert a redundant return statement (or use some kind of
>:      "notreached" directive, if available).
>
>The void main() issue is irrelevant to the original discussion, but since
>it has been brought up, a couple of points:
>
>Old K&R 'C' defined 'void' the same as 'int'. Lots of old code placed
>voids in front of a lot of things that properly returned 'int', like
>printf. This was done, obviously in bad form, to shut up lint.

Old K&R C (at least the one described in K&R1) didn't define 'void' at
all.
>
>I'll have to take serious issue with the so-called "comp.lang.c FAQ"
>on what main takes as arguments: it can take 0, 1, 2, or 3 arguments. The

The ANSI C standard explicitly states that main can have 0 or 2
arguments. A certain implementation can extend the number of arguments,
but a portable program is not allowed to rely on that.

>common names and types of these arguments is left as an exercise for
>the reader. I've never read it, and after getting something as basic
>and simple as main() arguments wrong, I can't suggest it to anyone.

The FAQ is right, you're wrong. If you want your programs to work only
on your platform and only with your compiler, there is no need to read
that FAQ, indeed.

>(I have no quarrel with its statements regarding the return type of
>main. But it should be noted that virtually all standard 'C' compilers
>are not as strident as the authors of this FAQ.)

The FAQ is based on the ANSI standard, which is the greatest common
denominator of all compliant implementations. On what are your opinions
based?
>
>Just out of curiousity, anybody know of any systems where void main() {}
>causes problems?

Who knows what surprises future systems/implementations are reserving
for the naive programmers? :-)

void main() is illegal and the fact that most implementations tolerate it
doesn't mean that using it is a clever idea.

Dan
-- 
Dan Pop 
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

From: d91mn@efd.lth.se (Mikael Nordqvist)
Subject: Re: MOD player for linux?
Date: 12 Jun 1994 10:41:33 GMT

In article <Cr9L2M.6Dt@agora.rdrop.com> shavelk@agora.rdrop.com (Steve Havelka) writes:
>Subject says it all.  Thanks...

nic.funet.fi:/pub/OS/Linux/util/sound
sunsite.unc.edu:/pub/Linux/apps/sound/players

gmod, mod, s3mod, tracker (The first two only support GUS).

Says it all.

/Mikael
-- 
Mikael Nordqvist, student    | d91mn@efd.lth.se | What is GNU Hurd? A whole
Lund Institute of Technology | mech@df.lth.se   | bunch of GNUs running around.

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


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