Subject: Linux-Development Digest #324
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Mon, 17 Oct 94 13:13:18 EDT

Linux-Development Digest #324, Volume #2         Mon, 17 Oct 94 13:13:18 EDT

Contents:
  Re: LINUX Logical volumes (Marcus Daniels)
  Re: How do I dump core? (Rob Janssen)
  Re: A badly missed feature in gcc (Rob Janssen)
  Bad code generated by gcc for strlen() call? (Dan Swartzendruber)
  Re: A badly missed feature in gcc (Craig Burley)
  Re: Looking for X graphics/ Plotting libraries (A. Rohde)
  Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... (Rob Newberry)
  Re: Kernel 1.1.54: Error compiling ("Stephen Davies")
  Re: Problems compiling 1.1.54 (Huw Davies)
  Re: We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
  Re: 3c505 driver ? ("Neil S. Russell")
  Re: We a FAQ: Linux vs. *BSD!!! (Hans Petter Fasteng)
  getty_PS with UUCP out (Hans Petter Fasteng)
  Re: question about the kernel (Nick Williams)

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

From: [email-masked] (Marcus Daniels)
Subject: Re: LINUX Logical volumes
Date: 13 Oct 1994 03:30:51 GMT
Reply-To: [email-masked]

In-reply-to: [email-masked]'s message of 12 Oct 1994 15:34:56 GMT

Logical volumes should be easy to implement with userfs.

What about `ifs'?

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

From: [email-masked] (Rob Janssen)
Subject: Re: How do I dump core?
Reply-To: [email-masked]
Date: Mon, 17 Oct 1994 08:54:30 GMT

In <[email-masked]> [email-masked] (Andreas Helke) writes:

>Jeff Kesselman ([email-masked]) wrote:
>: Thanks for the response, but either i wasn't clear enough with my 
>: problem, or I'm not understanding your answer.  The program ALREADY 
>: segment faults.  I can't do anything about that.  What I want is for it 
>: to dump core WHEN it segments faults, so I can gdb the core and find out 
>: WHERE it segment faulted.  Every other UNIX I've ever worked with does 
>: this automaticly, but Linux isn't doing it for me...

>Somewhere between  0.99 and 1.1 a definition in the kernel sources changed
>and now the default is not to produce a corefile. You have to reset this
>definition and recompile your kernel.

No, you just set the ulimit from your shell.

E.g.: ulimit -c 1024
(when using bash)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Rob Janssen)
Subject: Re: A badly missed feature in gcc
Reply-To: [email-masked]
Date: Mon, 17 Oct 1994 08:57:50 GMT

In <[email-masked]> [email-masked] (Jeff Kesselman) writes:

>In article <[email-masked]>, Rob Janssen <[email-masked]> wrote:
>>In <[email-masked]> [email-masked] (Jeff Kesselman) writes:
>>
>>>>Well, (URP!) VMS Pascal supports both (* *) and { } .....for what
>>>>*that* piece of silly trivia is worth...
>>
>>>Not much more then the fact that Borland C supports //,I'm afraid.  Its 
>>>still a compiler specific extension to the accepte standard.
>>
>>No.  The "Pascal user manual and report" by Jensen & Wirth defines these
>>two notations of comments in Pascal.
>>When that is not the accepted standard, then what is?
>>
>>The (* *) notation is said to be used on systems where { } are not available.
>>
>>Rob
>>-- 

>Okay. I stand corrected.  Must be the fact that the last time i used 
>pascal was better then 10 years ago.  Thanks, Bob.

Same for me, but I still have that book (second issue, 1978) on the
shelf here :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: [email-masked] (Dan Swartzendruber)
Subject: Bad code generated by gcc for strlen() call?
Date: 17 Oct 1994 09:58:15 -0400

With the input passed to blah(), the loop should never iterate even
once, since 0 is not less than -10.  And in fact, if I change the
call of strlen() to xstrlen(), which causes it to call the wrapper
function, it works correctly.  Examining the disassembled code seems
to indicate that gcc is generating incorrect code for the strlen()
code generated in the for loop.  I'm running gcc 2.5.8 on Linux.
Failing code section (and generated asm code follows):

================================== CUT HERE ===================================

void    blah(char *, int);

void
main(void)
{
        blah("", 10);
}

void
blah(char * string, int n)
{
        int             i;

        for (i = 0; i < strlen(string)-n; ++i) {
                printf("loop...\n");
        }
}

int
xstrlen(char * string)
{
        return(strlen(string));
}

================================== CUT HERE ===================================

        .file   "x.c"
gcc2_compiled.:
___gnu_compiled_c:
.text
LC0:
        .ascii "\0"
        .align 4
.globl _main
_main:
        pushl %ebp
        movl %esp,%ebp
        call ___main
        pushl $10
        pushl $LC0
        call _blah
        movl %ebp,%esp
        popl %ebp
        ret
LC1:
        .ascii "loop...\12\0"
        .align 4
.globl _blah
_blah:
        pushl %ebp
        movl %esp,%ebp
        subl $4,%esp
        pushl %edi
        pushl %esi
        pushl %ebx
        movl 12(%ebp),%esi
        xorb %dl,%dl
        movl 8(%ebp),%edi
        movb %dl,%al
        cld
        movl $-1,%ecx
        repne
        scasb
        notl %ecx
        movl %ecx,%eax
        subl $1,%eax
        xorl %ebx,%ebx
        cmpl %esi,%eax
        je L4
        .align 2,0x90
L6:
        pushl $LC1
        call _printf
        addl $4,%esp
        incl %ebx
        movl 8(%ebp),%edi
        xorb %al,%al
        cld
        movl $-1,%ecx
        repne
        scasb
        notl %ecx
        movl %ecx,%eax
        subl $1,%eax
        subl %esi,%eax
        cmpl %eax,%ebx
        jb L6
L4:
        leal -16(%ebp),%esp
        popl %ebx
        popl %esi
        popl %edi
        movl %ebp,%esp
        popl %ebp
        ret
        .align 4
.globl _xstrlen
_xstrlen:
        pushl %ebp
        movl %esp,%ebp
        pushl %edi
        xorb %al,%al
        movl 8(%ebp),%edi
        cld
        movl $-1,%ecx
        repne
        scasb
        movl %ecx,%eax
        notl %eax
        subl $1,%eax
        movl -4(%ebp),%edi
        movl %ebp,%esp
        popl %ebp
        ret

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

From: [email-masked] (Craig Burley)
Subject: Re: A badly missed feature in gcc
Date: 17 Oct 94 11:45:45 GMT

In article <wpp.782134241@marie> [email-masked] (Kai Petzke) writes:

   The answer to this is found in the GCC info files.  It has to do with
   the fact, that a number of people think, that GCC should become the
   world's standard compiler:

        A feature to report any failure to conform to ANSI C might be
        useful in some instances, but would require considerable
        additional work and would be quite different from `-pedantic'.  We
        recommend, rather, that users take advantage of the extensions of
        GNU C and disregard the limitations of other compilers.  Aside
        from certain supercomputers and obsolete small machines, there is
        less and less reason ever to use any other C compiler other than
        for bootstrapping GNU CC.

   Please note the words "limitations", "certain" and "obsolete".

   I personally like GCC very much, but I do not like some of the attitude
   behind it.  The statement above tells me, that I might run into trouble,
   if I use GCC on one machine but not the other.  This is exactly, what
   Microcruft and many others do, and this is exactly the behaviour, which
   is condemned in the GNU Manifesto.

No, it is almost completely the _opposite_ behavior of what is
condemned in the GNU Manifesto.

Or, has my comparative lack of paying attention to the commercial-software
world resulted in my not noticing that what you call "Microcruft"
has done the following?

-  Distributed their software products for free

-  Distributed the source code to their software products for free

-  Invited people to help them improve their source code

I suggest that you reexamine the situation.  If you consider it
intelligently, you'll notice that while the statement you quote
indeed indicates a certain "attitude" among the "official" GCC
developer, the FSF, that attitude does _not_ extend to leveraging
significant assets to lock customers into a product line that
they cannot easily wriggle out of.  That would be a very hard
thing to do with a product that is freely copyable like GCC.

The only depressing "attitude" on display here is the one you have --
that because the FSF hasn't already devoted even more of its funds
to make GCC "all things to all people", or chose to do that rather
than, say, to port it to more machines and make it generate better
code more reliably, it has somehow let you down.

Fortunately, the answer to your "attitude" is the same, simple answer
to most complaints about the FSF and its products:

    If you don't like it, change it, or persuade someone else to change it.

How's that for attitude?
--

James Craig Burley, Software Craftsperson    [email-masked]

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

From: [email-masked] (A. Rohde)
Crossposted-To: gnu.gcc.help
Subject: Re: Looking for X graphics/ Plotting libraries
Date: 17 Oct 1994 14:17:25 GMT

In article <[email-masked]>, [email-masked] (Wade Scholine) writes:
|> CookieMonster <[email-masked]> writes:
|> 
|> 
|> >I am working on a small project, and need some library routines to do 
|> >some simple X windows graphics: Pop open a window, take some disk data, 
|> >and graph the data in the window with auto-scaling, axis, etc. SInce I 
|> >want to spend more time on the data producing side of the program, I need 
|> >a package that can do the plotting for me.
|> 
|> There is a program called x11-graph which does the trick for me.
|> It's kinda old (at least the version I have is) but with minor
|> tweaks it works pretty well.  You'd have to archie to find it,
|> since I don't remember where I got mine (or I suppose I could
|> mail it to you...)
|> -- 
|> Wade L. Scholine              | Once upon a time, four AMPHIBIOUS HOG
|> c_farer associates, inc.      | CALLERS attacked a family of DEFENSELESS,
|> Delray Beach, FL.             | SENSITIVE COIN COLLECTORS and brought DOWN
|>                               | their PROPERTY VALUES!!

Try GnuPlot, xvgr or GLE. They are available from sunsite.unc.edu and it's
mirrors.

Axel

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

From: [email-masked] (Rob Newberry)
Subject: Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive...
Date: Fri, 14 Oct 1994 23:00:01

>: Looking at  the postings relating to this problem, it appears that the
>: connecting piece of hardware is the NE2000 Ethernet Card. In fact we seem
>: to have crudely fixed the problem by , by slowing down the reads/writes
>: performed by the Network Card.

>What do you mean by this? Did you define REALLY_SLOW_IO? Something else?

>: If anyone else could suggest a better fix, please let me know.

>FWIW, our system is closing in on 12 days of uptime since replacing the NE2000
>with a 3c509. 

I replaced mine with an SMC Ultra -- much nicer, and absolutely NO problems 
since.

Rob

*******************************************************************
Rob Newberry               Education and Technology Solutions, Inc.
Email: [email-masked]        4303 Parkland Court
Phone: 301 438 3915        Rockville, Maryland 20853
FAX: 301 438 3748

      The secret to happiness is knowing how many
          weekdays you can afford a hangover.

*******************************************************************

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

From: "Stephen Davies" <[email-masked]>
Subject: Re: Kernel 1.1.54: Error compiling
Date: Mon, 17 Oct 94 22:00:35 PDT

G'day Bart.

I think that you have somehow screwed your source tree. Start again and
try the following:

1. In /usr/src create a file called "dopatch" or somesuch that contains:

zcat MYPATCHDIR/patch$1 | patch -p0 2>&1 | tee patchlog

where MYPATCHDIR is where you keep your patch.gz files.

chmod this file to 7xx as takes your fancy.

2. For each new patch, "cd /usr/src", "dopatch n" and "grep fail patchlog".
(where "n" is the relevant patch number. eg 54)

If the grep returns nothing you are half-way home.

3. "cd linux", "make mrproper", "make dep", "make zlilo"/"make zimage"

For patch54, you will probably have to delete the second half (line 637
onwards +/-) of binfmt_elf.c to get a clean compile.

Cheers,
Stephen.

>I have been trying to compile kernel 1.1.54.
>I downloaded 1.1.52 complete, and compiled. No problem.
>
>I patched 1.1.53 and 1.1.54 from the / (root) with: 
>patch -p < patch53  (and 54)
>I did not see any errors during the patch, but it is imposible to read anyway.
>
>Make config: enable all IP stuff, all else as default.
>'Make dep' works ok, 'make clean' ok, 
>
>'make' fails in the area: 
>tools/build.c , problems with N_MAGIC, ZMAGIC QMAGIC ,  implicit declar; 
>undeclared, incomplete type....
>Then stuff about: unused variable 'sb'   and   'major_root' may be used 
>uninitialized....
>Error 1
>End of story.
>
>Is it me doing something wrong? I have been patching from 1.1.19 and never had
>any problems until today.  
>
>Any help appreciated.
>
>Thanks,
>Bart.
>
>
>-----------------------------------------------------------------------------
=======
>Bart Kindt (ZL4FOX) System Operator, Efficient Software NZ LTD, Dunedin, New
Zealand
>-----------------------------------------------------------------------------
=======

========================================================================
Stephen Davies Consulting                              [email-masked]
Adelaide, South Australia.                           Voice: 61-8-2728863
Computing & Network solutions.                       Fax  : 61-8-27410

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

Crossposted-To: aus.computers.linux,latrobe.linux
Subject: Re: Problems compiling 1.1.54
From: [email-masked] (Huw Davies)
Date: Mon, 17 Oct 1994 12:51:17 GMT

Huw Davies ([email-masked]) wrote:
: I've just applied the 1.1.54 patches to a (working) copy of 1.1.53, ran
: make config choosing the usual group of options (although I added ISO9660
: support which I must have accidentally turned off building 1.1.53) and
: then ran make zImage. Sadly I get compile time errors (see below). I've
: tried rebuilding the compiler with and without elf support but the errors
: remain.

It turns out that applying the 1.1.54 patch to a 1.1.53 system will lead
to this problem. The simple solution is to edit binfmt_elf.c which, as the
result of applying the patch, contains two copies of the file. I just
simply went down to the start of the second copy and deleted to the end
of file and then rebuilt the kernel.

Thanks to all those who took the time to reply. If I'd bothered to think
rather than just panic (something that's easy to do at 2 in the morning having
worked all day on other computer problems) I'd have probably worked this
out for myself....

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

Crossposted-To: comp.os.386bsd.development,comp.unix.bsd
From: [email-masked] (Jesus Monroy Jr)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Sat, 15 Oct 1994 20:37:12 GMT

John Gotts ([email-masked]) wrote:
: The 386BSD FAQ covers some of the differences.  RTFM.
:
        Yes, that's true, but the direct question is:

        Which is better Linux vs. *BSD?

        RTFQ (Question)

        And don't spout out on this.... I very serious on this issue.

-- 
Jesus Monroy Jr                                          [email-masked]
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

From: [email-masked] ("Neil S. Russell")
Subject: Re: 3c505 driver ?
Reply-To: [email-masked]
Date: Mon, 17 Oct 1994 13:30:12 +0000

> In article <[email-masked]>,
> Tall Sword <[email-masked]> wrote:
> >Zheng Huang ([email-masked]) wrote:
> >: Hi,
> >
> >: I tried to config my linux(slakware 2.0) to work with my 3c505 network card,
> >: but I can't find the 3c505.c file in linux src directory under drivers.
> >: For some reason, the 3c505 is been commented out from the config file. Could
> >: someone tell me how I can make 3c505 work with linux.
> 
> I tried to configure the kernel to include the 3c503 driver but it don't 
> recognize my card. I know the linux has support for all the 3com card except
> for 505. I tried my 3c501 card, and it works.
> 
> Any help for 3c505 driver?

I Compiled kernel 1.1.51 to include 3c505 code included and it works fine with
these cards. Try compiling a newer kernel.

-- 
Neil S. Russell
Nation Computer Systems Manager
NACRO NCE Ltd

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

Crossposted-To: comp.os.386bsd.development,comp.sys.unix
From: [email-masked] (Hans Petter Fasteng)
Subject: Re: We a FAQ: Linux vs. *BSD!!!
Date: Mon, 17 Oct 1994 11:56:15 GMT

Jordan K. Hubbard ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] (Jesus Monroy Jr) writes:

:          This is a weekly question.
:          More often than not, we get into a flame war
:          on this.  Let's stop this silliness!!!

: The only way we're going to stop this silliness is to simply start
: ignoring the querants.  If someone asks "Which is better?  Which is
: better?", jumping up and down all the while, and everybody just flat
: out _ignores_ the question and goes about their business as if nothing
: happened, folks will eventually get the point and stop asking.

: Consider carefully: It's not the questions that start the bloody flame
: wars, it's everyone's pathetic attempts to answer!  "Well, xxx is
: better because of yyy.."  "No it's not!"  "Yes it is, you moron!  Just
: look at blah blah blah!"  "Well, you're a complete idiot who obviously
: wouldn't know an operating system if it bit you - yyy is _obviously_
: better because bleh bleh bleh!".  And so downhill it goes from there.

: No FAQ will ever satisfy the two sides, and would rapidly become
: obsolete even if it did.  Dave Burgess's FAQ _tries_ to answer this
: question about as well as any FAQ could, and people still aren't
: remotely satisfied.  One German magazine reviewer who compared FreeBSD
: to Linux ended up making an unfavorable judgement of FreeBSD because
: _it didn't have enough shells_ bundled in by default!  He completely
: ignored the other issues, he just wanted his bloody tcsh to be happy.
: This almost perfectly exemplifys the average querant - they don't
: really want to know which is better in general (as if "better in
: general" meant anything anyway), they want to know which is better for
: THEM, and how the hell are we supposed to know that?

:          The distraction is overwhelming and we need a solution.

: The solution is obvious, and in right front of our faces.  Don't even
: bother with such questions.  Ignore them.  If you're dead-set on
: answering questions, then there are PLENTY of more worthy questions
: posed every single day that could use meaningful answers.  Why waste
: time with people who only want to know which brand gives you whiter
: teeth, fresher breath, cures acne or gets out those nasty grass
: stains?  Such people are better off watching daytime television talk
: shows or reading "USA Today" anyway ("Today on Sally Jesse Rafael,
: we'll be asking the question "Which is better?  Linux or FreeBSD?",
: and we'll also be interviewing 3 truck drivers who like to do long
: cross-country trips with live hamsters in their shorts.")

: Sheesh!

:                                       Jordan

  It is always easy to know better then others.  It is not easy to go into
your self, therefore we go into others and tell them what to do better.
THe people posting those questions is new on the net, and knows nothing
about internet or linux,freebsd.  I do not thing it is right to ignore
questions or to tell people how silly thay are.  Just telling them that it
is a FAQ is enough.  Nearlly every person askes questions that my sound
stupide in other ears than thair own.
(sorry spelling is not my best side)

-hans

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

From: [email-masked] (Hans Petter Fasteng)
Subject: getty_PS with UUCP out
Date: Mon, 17 Oct 1994 12:19:11 GMT

I have getty_ps 2.0.7e (uugetty) on my dialin line.  I also uses that line
for UUCP outgoing calls.  But now it is not possible getty will not release
the port to UUCP how do I instruct uugetty to let UUCP call out?

-hans

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

From: [email-masked] (Nick Williams)
Crossposted-To: comp.unix.internals,comp.os.linux.help
Subject: Re: question about the kernel
Date: 14 Oct 1994 23:02:21 -0400

In article <[email-masked]>,
Matthias Urlichs <[email-masked]> wrote:
>In comp.os.linux.development, article <dyue.782058914@mega>,
>  [email-masked] (Dongxiao Yue) writes:
 
>> Can someone tell me how and where the critical sections are protected?

>If the critical sections are not accessed from interrupt code, there's no
>need to lock access. Reason: Switching between processes happens when
>somebody calls schedule(). Interrupts don't call schedule() and nobody
>switches processes behind your back. QED.

Critical sections are pieces of code that access data that could
potentially be accessed by a different thread of execution or an
interrupt handler. Thus accesses to a  buffer that is to be filled by an
interrupt handler must be protected in some way or another (by raising
the priority on a single CPU machine, or raising the priority _and_
spinlocking on a shared memory multi-processor machine or some other
scheme [?]).

That said, I must make clear that I haven't had the priviledge of
studying linux kernel sources; I am ignorant of how linux handles
critical sections in the kernel. I do know how they are traditionally
handled in other operating systems though. To the original poster I say
"read the docs [if there are any]."

>-- 
>Matthias Urlichs        \ XLink-POP Nürnberg  | EMail: [email-masked]
>Schleiermacherstraße 12  \  Unix+Linux+Mac    | Phone: ...please use email.
>90491 Nürnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42
>          PGP: 1B 89 E2 1C 43 EA 80 44  15 D2 29 CF C6 C7 E0 DE 
>      Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

Nick

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

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