Returned mail

Mail Router (MAILER-DAEMON@npvsrv1.napervilleil.NCR.COM)
23 Jul 95 23:28:51 CDT


Your mail could not be delivered because of the following reason:

----- Transcript of session follows -----
Executing: /usr/lib/mail/surrcmd/smtpqer -n -B -C -u npvsrv1.NapervilleIL.NCR.COM!ncrhub4!ncrgw1!vger.rutgers.edu!linux-kernel frsos.napervilleil.attgis.com jejb@frsos.napervilleil.attgis.com
smtpqer: Binary contents cannot be sent via SMTP
server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1

----- Unsent message follows -----
>From ncrgw1!vger.rutgers.edu!linux-kernel Mon Jul 24 00:22 EDT 1995 remote from ncrhub4
Received: by ncrhub4.ATTGIS.COM; 24 Jul 95 00:22:39 EDT
Received: by ncrgw1.ATTGIS.COM; 24 Jul 95 00:22:14 EDT
Received: (from majordomo@localhost) by vger.rutgers.edu (8.6.12/8.6.12) id GAA17551 for linux-kernel-digest-outgoing; Sun, 23 Jul 1995 06:39:29 -0400
Date: Sun, 23 Jul 1995 06:39:29 -0400
Message-Id: <199507231039.GAA17551@vger.rutgers.edu>
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #127
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk

linux-kernel-digest Sunday, 23 July 1995 Volume 01 : Number 127

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

From: Sentinel <sentinel@li.net>
Date: Fri, 21 Jul 1995 18:41:52 -0400 (EDT)
Subject: Re: 1.3.11 IP forwarding? Help.

On Thu, 20 Jul 1995, Joshua M. Thompson wrote:

> On Tue, 18 Jul 1995, Joseph Fouche wrote:
> > Well, 1.3.11 is running here, but no IP forwarding. Whatever broke
> > between 1.3.9 and 1.3.10 is still broken, at least for me. I'm using the
> > 2.2b3 PPP code and driver.
> > Anyone else tested this yet? Sure, I'm a bit early, but hey...
> I'm using the same kernel and PPP driver and it's definately still
> broken. For that matter AppleTalk seems to be broken too; it doesn't
> crash the machine anymore but all NBP-related requests time out.

Okay well with 1.3.11 and the new ppp2.2b3 I cant even get ppp to turn on
it gives me an error dealing with a ppp driver..

when I do use the new ppp.c and the header files from the install script
from the ppp-2.2b3 distribution I get an error when I try to make zlilo
there fore I can not update my ppp driver.. If anyone here knows what
either I am doing wrong or what is wrong please tell me othere wise for
now I will stick with ppp-2.1.2d and await what happens next.

Sentinel@li.net

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

From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Fri, 21 Jul 1995 23:21:34 +0200 (MET DST)
Subject: Re: linux-kernel-digest V1 #122

According to owner-linux-kernel-digest@vger.rutgers.edu:
> From: "Michael J. Drons" <pa_mjd@meceng.coe.neu.edu>
> Date: Tue, 18 Jul 1995 13:25:08 -0400 (EDT)
> Subject: Dosemu 0.60.3
>
> When Compiling Dosemu 0.60.3 it dies after 20 minutes because of too many open
> files. Has anyone had this problem??? Can I fix it bby increasing the number of > open files in limits.h or resource.h???
>
> Currently limits.h defines it as follows:
> #define OPEN_MAX 256 /* # open files a process may have */
> and I find it hard to believe that "make most" on the dosemu side had 256 files
> open.

Such errors can be caused by an infinite loop of include files including
eachother. When the preprocessor keeps processing the #includes, at some
time the max number of opens will be reached.

Rob

- --
+------------------------------------+--------------------------------------+
| Rob Janssen rob@knoware.nl | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+

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

From: Eric Bosch <ecbosch@tyrell.net>
Date: Fri, 21 Jul 1995 21:08:26 -0500 (CDT)
Subject: Crashing Problems & missing file

I am using kernel 1.3.11, compiled under elf. When I run X, and have a
console on the screen doing a 'find' command from root (cdroms, msdos fs,
os2 fs mounted) and I run Seyon to call out the system freezed cold. I
have on occaision interrupted the 'find' command, and restarted with a
different 'find' and within a few minutes, I get a hard freeze. I was
told that tagged queing should be disabled in aic7xxx.c, which seems to
be the default, (AHA-2940) disconnection is disabled on CDROM and Archive
python drives. I can't figure what the problem is! Do I need to turn down
the negotiation speeds for these devices? They are set at 10 MB/s. I
also have two Seagate SCSI drives in unit- 2340 (2 Gig) and a 1240 (1 Gig).

I also migrated to ELF yesterday, and I seem to have wiped something
out. When I invoke Seyon in a X session, I get two error messages as
follows:

_setutent: can't open utmp file: no such file

I think I probably wiped out a link or something. Could anyone tell me
what is missing? /usr/utmp, /usr/wtmp links are in place, pointing to
/var/adm/utmp and /var/adm/wtmp respectively. Some help would be
appreciated, as I'd hate to have to do a complete reinstall!!

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

From: hpa@trantor.storm.net (H. Peter Anvin)
Date: 22 Jul 1995 03:52:07 GMT
Subject: Re: 16-bit read/operation on ISA-bus

In article <3ul7vg$1tgj@info4.rus.uni-stuttgart.de>,
Student Mark Smit (SP+T H.W) <smit@xvnews.unconfigured.domain> wrote:
>
> (There is a definition of inb, outb, ... in the file asm/io.h, but
> later on compilation
> the internal commands __inb, __outb, ... are unknown.
>

Compile with -O2.

/hpa

- --
PGP public key available - finger hpa@yggdrasil.com
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

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

From: Richard Waltham <dormouse@farsrobt.demon.co.uk>
Date: Sat, 22 Jul 1995 01:42:40 +0100 (BST)
Subject: 1.3.11 compile warnings

Compiling 1.3.11 give a couple or three warnings.

Not sure about the significance of the first one, if indeed it has any, or
if any of them have but here they are anyway.

'sgcnt' is defined but never referenced, should it be?

'ow_size' is defined but only referenced in a section starting with #if 0,
so never used.

gcc -D__KERNEL__ -I/usr/src/linux-1.3.0/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe -m486 -c sg.c
sg.c: In function `sg_ioctl':
sg.c:80: warning: passing arg 2 of `verify_area' makes pointer from integer
without a cast
sg.c: In function `sg_write':
sg.c:301: warning: unused variable `sgcnt'

gcc -D__KERNEL__ -I/usr/src/linux-1.3.0/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe -m486 -c tcp.c
tcp.c: In function `tcp_write_wakeup':
tcp.c:4954: warning: unused variable `ow_size'

Running the commands

make mrproper
make dep
make clean
make dep

gives two different outputs for make dep. Is this usual or should I normally
expect them be the same. For my build of kernel, however, it doesn't seem to
have any consequences as it ends up the same whatever the output of make
dep.

Running make dep after mrproper gives the following additional output if its
of any significance.

make[1]: Entering directory `/usr/src/linux-1.3.0/kernel'
gcc -D__KERNEL__ -I/usr/src/linux-1.3.0/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe -m486 -E -DCONFIG_MODVERSIONS -D__GENKSYMS__
ksyms.c | /sbin/genksyms -w /usr/src/linux-1.3.0/include/linux/modules
genksyms "ksyms.c": warning: symbol [do_mmap]: unknown 'struct sem_undo'
genksyms "ksyms.c": warning: symbol [do_mmap]: unknown 'struct sem_queue'
genksyms "ksyms.c": warning: symbol [do_mmap]: unknown 'struct minix_super_block'
genksyms "ksyms.c": warning: symbol [do_mmap]: unknown 'struct ext2_super_block'
genksyms "ksyms.c": warning: symbol [inet_add_protocol]: unknown 'struct sock'
genksyms "ksyms.c": warning: symbol [inet_add_protocol]: unknown 'struct ip_mc_list'
genksyms "ksyms.c": warning: symbol [inet_add_protocol]: unknown 'struct udphdr'
genksyms "ksyms.c": warning: symbol [scsi_register]: unknown 'struct scsi_disk'
updating /usr/src/linux-1.3.0/include/linux/modversions.h

make[2]: Entering directory `/usr/src/linux-1.3.0/drivers/char'
gcc -I/usr/src/linux-1.3.0/include -o conmakehash conmakehash.c
./conmakehash cp437.uni 641 283 6 > uni_hash_tbl.h

make[2]: Entering directory `/usr/src/linux-1.3.0/drivers/scsi'
gcc -D__KERNEL__ -I/usr/src/linux-1.3.0/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -pipe -m486 -o aic7xxx_asm aic7xxx_asm.c
./aic7xxx_asm -o aic7xxx_seq.h aic7xxx.seq
428 out of 448 instructions used.

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

From: rolandd@swn.com (Roland Dunkerley)
Date: Fri, 21 Jul 95 18:42:24 PDT
Subject: Re: kernel config

>>>>> ":" == dholland <dholland@husc.harvard.edu> writes:

>> It seems that many people want to change the way the kernel is
>> compiled, but nobody can find a good solution. A new config
>> program _must_ be supported by Linus because anything else will
>> not be kept in sync with the kernel.

:> Agreed.

>> Some ideas:
>>
>> All the adjustable defines are kept in a database. Each define
>> is classified with cross-references, dependencies, and options.
>> This is so that different config programs can have different
>> menu systems, yet be (mostly) independent of the kernel
>> version.

:> And what format shall this take? It needs to be parsable from
:> sh using only expr, sed, and awk.

Only if not a single kernel hacker understands lex/yacc well enough to
write a parser to do the necessary Makefile/header configuration.
Seriously, why would it need to be parsable from sh at all? Can
include a flex/bison grammar (pre flexed/bisoned even, though I doubt
this would at all be necessary, I would guess that flex and bison are
much more ubiquitous on machines with development tools installed than
perl would be.) with the rest of the kernel sources, that would get
built with make config. The sound driver already has a configure
program written in C.

>> Help is stored in a separate file. Each define gets a
>> paragraph. The DOS 5 help file format is simple to use

:> Um, shouldn't we use something flexible that meets our needs
:> rather than somebody else's?

I'll second that.

>> This needs to be done in 1.3.x really soon.

:> Maybe. I'm not convinced the configuration is that badly
:> broken. Proper documentation of the sources is more important,
:> in my opinion. ;-)

Proper documentation would be nice. Man pages for kernel internal
functions would be really nice. Probably wouldn't take too long to
have most of the major ones if someone were to volunteer to collect
the kernel-man pages and ask people to write just one. I'm too busy
lately myself to collect them, but I'd be willing to write a page or
two. The current configuration doesn't bother me too much. I hate it
when I have to start all over or go manually edit the files when I
flub a single one up though. So I think some improvement could be
achieved in that area, just don't think it is the most important thing
happening with linux right now. I think the performance issues
(particularly with NFS) for example are far more important. If
someone were to present a well thought database format, I'd volunteer
to write a parser for it however. For that matter, the database file
could be a binary file, but that would be nonportable. It's really
not like the kernel isn't full of C code already, won't hurt if it's
configurator is also in C. Of course, Linus does have to like it
enough to use it or it will be useless.

NSA: plutonium Mossad NSA Panama Croatian Qaddafi domestic disruption
munitions Noriega jihad Honduras NORAD genetic DES [Hello to all my
fans in domestic surveillance]

This message copyright (c) Roland Pleasant Dunkerley III rolandd@swn.com
<A HREF="http://www.cdt.org/petition.html">Petition to Help keep FCC away
from inet!</A> Distribution of this article via Microsoft Network requires
payment of a $1.00(US) per character per copy license fee.

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

From: adam@adam.yggdrasil.com (Adam J. Richter)
Date: 22 Jul 1995 06:17:09 GMT
Subject: 1.3.x kernel breaks GNU make 3.74 (fix included)

I sent the following to bug-gnu-utils@prep.ai.mit.edu, but I
thought it might be relevant to readers of this channel. The
symptoms of the problem are make failing to find files that exist
after the kernel has been upgrade to 1.3.9 or above (it may also
occur in earlier 1.3.x kernels; I haven't tried them).

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

Linux 1.3.9 and possibly ealier linux 1.3.x kernels have
what I think is a performance improvement in readdir() that breaks
GNU make 3.74. Under Linux 1.3.9 and above, it appears that when
readdir() writes a filename into the d_name field of the structure
that it returns, it null terminates the string, but does not fill
in the rest of the available bytes with nulls. It appears that
GNU make 3.74 expects this nonstandard expensive behavior on all
systems that define __GNU_LIBRARY__. Here is a fix. I'm not
sure that it's the best fix, since I have a mind to simply
get rid of the original definition of D_NAMLEN.

Adam J. Richter Yggdrasil Computing, Incorporated
(408) 261-6630 "Free Software For The Rest of Us."

*** /tmp/make-3.74/dir.c Mon Nov 7 19:14:50 1994
- --- dir.c Sat Jul 22 02:00:27 1995
***************
*** 22,24 ****
#include <dirent.h>
! #ifndef __GNU_LIBRARY__
#define D_NAMLEN(d) strlen((d)->d_name)
- --- 22,24 ----
#include <dirent.h>
! #if defined(linux) || !defined(__GNU_LIBRARY__)
#define D_NAMLEN(d) strlen((d)->d_name)

- --
Adam J. Richter Yggdrasil Computing, Incorporated
(408) 261-6630 "Free Software For The Rest of Us."

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

From: joey@finlandia.Infodrom.North.DE (Martin Schulze)
Date: Sat, 22 Jul 95 00:57 MET DST
Subject: Kernel configuration and documentation

Dear folks!

Albert Cahalans mail broke a frontier built up in me....

First I will leave some comments on configuring the kernel.

1. It's very good that you can easily configure it using the Configure
script. Unfortunately many things have to get recompiled after
that, but computers are getting faster...

2. To my feeling there are far too little comments about what all the
settings are about. Sometimes even I run into trouble, 'cause I
didn't know what's meant. And what will a newbie think?

So I would very much appreciate a file describing every setting you
can make in the configure script. In this file I would like to have
a description that even a newbie understands and at some places a
more technical view, with pointers to the source where some things
can also get tuned.

Maybe the Configure script can also be extended to support a help
function which displays a little (10 lines or so) description about
the current define.

3. There are many kernel settings which are not carried with the
configure script. I would appriciate introducing another script (or
perhaps a complex program so you don't have to recompile the
kernel) to adjust the kernel. I mean, set max number of processes
(at all and per user), set number of ttys, set kernel output (to a
serial line?) and such things. Just finetuning the kernel.

Maybe another thing can be added here, adjusting the autoprobing
for some strange ethercards, cdroms or whatever, say adding or
deleting some addresses.

4. All these configuration and adjusting stuff should be kept in some
files that are used in newer kernels, too.

Albert Cahalan said:

| All the adjustable defines are kept in a database. Each define is
| classified with cross-references, dependencies, and options. This

Hmm, that may be quite good to track down the time needed for
compiling the kernel. But the problem that I see is that Linus has to
keep this database (at least the dependencies section) up to date,
which will be a stupid job. But nevertheless I think this would be a
good idea.

| is so that different config programs can have different menu systems,
| yet be (mostly) independent of the kernel version.

What do you mean?

| Help is stored in a separate file. Each define gets a paragraph.
| The DOS 5 help file format is simple to use

Your're joking, aren't you? I can't see any reason using anything from
poor DOS. :-(

What I suggest is:

a) A document describing all the different switches, their
advantages and disadvantages, their dependencies and
side-effects.

b) More (or at least any!) descriptive text while running the
configure script. This should contain enough important
information, but shouldn't be too technical.

You may have a look at the description files used in Patric
Volkerdings Slackware.

To come to an end. There are two proposals that we should think of.

regards,

Joey

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

From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Sat, 22 Jul 1995 01:40:26 +0200 (MET DST)
Subject: Re: linux-kernel-digest V1 #123

According to owner-linux-kernel-digest@vger.rutgers.edu:
> From: "Theodore Ts'o" <tytso@mit.edu>
> Date: Wed, 19 Jul 1995 16:22:42 +0200
> Subject: Re: linux-kernel-digest V1 #118
>
> From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
> Date: Tue, 18 Jul 1995 09:18:15 +0200 (MET DST)
>
> Resilience to disk errors certainly isn't Linux's best point...
> I while ago I had some bad sectors on my SCSI disk (which does not have
> automatic re-allocation of those bad sectors), and it was quite difficult
> to recover from that.
>
> It would be nice to allow filesystems to automatically move bad sectors
> to the bad block list, and possibly rewrite a block buffer to a newly
> reallocated block when it is discovered that a newly allocated block is
> bad. This would probably require a callback from the device driver to
> the filesystem layer to notify the filesystem that a particular block is
> bad.

That is all very nice. However, before doing it so sophisticated I
would like to suggest to first make it handle errors more reasonably...
(i.e. don't panic the system or hang processes when a block can't be read)

> It would be nice if you could get the messages printed on a fixed device
> directly by the kernel, so that you could send them to the first console
> (instead of the current one), to a terminal on a serial port, to a
> printer, etc. That would make them less dependent on complex stuff like
> syslogd and X.
>
> This doesn't require kernel changes; you just need to make source
> changes to klogd. This would work in most cases, where process
> scheduling is still working. It certainly works in the disk i/o error
> case mentioned above; you just have to instruct klogd to write kernel
> log messages to a device, instead of or in addition to forwarding the
> kernel message to syslogd.

I'm not sure what klogd is, my system currently runs only syslogd.
Is there an advantage to getting and running klogd? (I don't have it)
Note that when the disk is dead, processes that are not very active and
suddenly need to do something stand a high chance of failure.
(because they have been swapped out)

I know it is against the "do it in user mode" religion, but I really
think that critical error message printing should be done in the kernel,
not in a user process that probably dies with the system.

> In the case where I'm doing kernel work, and where I'm afraid a device
> driver bug that I'm working on might cause the system to hang at the
> interrupt level, i generally avoid working using X11 at all; I'll then
> kill off klogd, or run klogd -c 8, so that all kernel messages go to the
> current console, where I'm guaranteed to get the message even if the
> system is hung.

That only helps when you are doing debugging work.
(even then I would not like to be without X)
Problems with the disks or the SCSI bus can occur at any time, usually
when you don't expect or like it. I feel uneasy with the fact that
I don't see the error messages, and the filesystems are corrupted
beyond the minimum possible extent.
(e.g. an error on /dev/sda1 will corrupt a filesystem on /dev/sda2, only
because you can't sync the system properly before rebooting it)

Sure all kinds of nice solutions are possible, but why can't we report
device errors back to the user program, as all other operating systems
seem to be able to do? (and leave the system in a state where it can
be safely shutdown)

Rob
- --
+------------------------------------+--------------------------------------+
| Rob Janssen rob@knoware.nl | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+

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

From: sl14@crux4.cit.cornell.edu (Stephen Lee)
Date: Sat, 22 Jul 1995 04:03:24 -0400
Subject: strace 3.0 and 1.3 kernel

I was compiling strace 3.0 on my 1.3.11 system, and found the following
problems:

1)

syscall.c:480: `ERESTARTSYS' undeclared (first use this function)
syscall.c:483: `ERESTARTNOINTR' undeclared (first use this function)
syscall.c:486: `ERESTARTNOHAND' undeclared (first use this function)

Are these used anywhere else apart from the kernel? I guess I can live
with -D__KERNEL__ for this one...

2)

sys_semget(), sys_semctl(), etc. are prototyped in <linux/sem.h> which is
included in <sys/sem.h>. This clashes with the function of the same name
in strace. I don't know if sys_* belongs to the implementor's name space,
but even if it does, wouldn't it be a better idea to enclose them with
#ifdef __KERNEL__? The same goes for sys_msg* and sys_shm*.

Stephen

- --
Stephen Lee
Internet: sl14@cornell.edu

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

From: "David S. Miller" <davem@caip.rutgers.edu>
Date: Sat, 22 Jul 1995 05:28:11 -0400
Subject: Grrr: Z8530 driver in 1.3.11

Date: Fri, 21 Jul 1995 13:12:34 -0700
From: Bruce Perens <bruce@pixar.com>

Joerg Reuter jr196930@lykos.tng.oche.de said:
> 2. The driver i s under the GNU GPL already (*) and so Hans is free
> to modify my work [...]
> 3. BUT: With no term of the GPL Hans is allowed to change the
> copyright notice of the driver. He may claim that his version is
> "derived work"than his own code. [...]
> This was definetely the last project I deliver source code. That is
> too much!

After the way I flamed at Joerg to get him to put the GPL on his driver, it's
embarassing that he should be abused this way.

As your friendly list administrator can I please ask that this be
taken to private mail between the parties directly involved. The
problem is known, and it can only be worked out amongst those
involved. Thanks ;)

Later,
David S. Miller
davem@caip.rutgers.edu

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

From: Jim Lynch <jimlynch@netcom.com>
Date: Sat, 22 Jul 1995 03:40:44 -0700 (PDT)
Subject: Re: kernel config

On Thu, 20 Jul 1995 dholland@husc.harvard.edu wrote:

> > Some ideas:
> >
> > All the adjustable defines are kept in a database. Each define is
> > classified with cross-references, dependencies, and options. This
> > is so that different config programs can have different menu systems,
> > yet be (mostly) independent of the kernel version.
>
> And what format shall this take? It needs to be parsable from sh using
> only expr, sed, and awk.
>
> > Help is stored in a separate file. Each define gets a paragraph.
> > The DOS 5 help file format is simple to use
>
> Um, shouldn't we use something flexible that meets our needs rather
> than somebody else's?
>
> > This needs to be done in 1.3.x really soon.
>
> Maybe. I'm not convinced the configuration is that badly broken.

I agree. It seems to work OK.

> Proper documentation of the sources is more important, in my opinion. ;-)

I definitely agree! This is MUCH more important! I'd like to see uncompressed
source trees double in size with inline documentation alone!

- -Jim Lynch aka enOne (jimlynch@netcom.com)

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Date: 22 Jul 1995 12:45:32 +0200
Subject: Re: Benchmarks - 1.3.11 + patch

In linux.dev.kernel, article <Pine.LNX.3.91.950720084525.13192A-100000@pimpinel.fluido.org>,
Carlo Emilio Prelz <fluido@telepac.pt> writes:
>
> I found out why I had problems running the filesystem tests. It seems
> that the timer set by the alarm() call is automatically reloaded when
> it expires... I don't know whether this is how things should be, but I

No, that isn't how it should be. Looks like a bug...

> * Linux pimpinel.fluido.org 1.2.10 #59 Tue Jun 13 09:46:17 MET DST 1995 i486
> * Linux pimpinel.fluido.org 1.3.12 #23 Wed Jul 19 21:55:21 MET DST 1995 i486
>
> Pipe-based Context Switching Test || 3446.9 -> 9969.6 +189.23%

Now that looks tempting...

- --
Ambulance drivers come quicker.
- --
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
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>.

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

From: tfries@umr.edu (Todd Fries)
Date: Tue, 27 Jun 1995 04:11:37 +0000 (GMT)
Subject: re: "Make modules" dependency

> I'm compiling 1.3.11, and "make modules" always recompile all modules
> without checking for dependency. Can the makefiles be fixed? It is quite
> annoying, esp. since "make modules" hasn't worked all the way to the end
> for me since 1.3.x... It is bad trying to track why a module won't
> compile, it's worse having to recompile everything before it each time...

This has been a thorn in my side as well. The 'quick and dirty' solution I
always end up using is to change the order of the objects / SUBDIRS= in
the individual makefiles so that the module I want to compile is compiled
first.

Jim Nance has been working on changing this. He is slowly getting a few of
his ideas into the kernel tree at a time (too slowly, imho, but that's for
Linus to decide, not Jim or myself.) Jim is working towards a central
'rules' file for all 'common' rules between makefiles, which then provides
a lot of flexibility in terms of changing the 'rules' globablly.

Jim: Keep up the good work!
Linus: Please continue to add Jim's makefile suggestions to the kernel...I
find them much more efficient not only in compiling time and
flexibility, but also in space.

My $.02...

- --
Todd Fries...tfries@umr.edu

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

From: iain@enterprise.iinet.com.au (Iain Riley)
Date: 21 Jul 1995 20:17:04 +0800
Subject: Re: Double "Oops" from corrupt tty struct.

Last night I had my machine fall over with the same problem.

It is a DX2/66 running a standard 1.3.10 kernel.

It also produced this message

Jul 21 19:27:02 enterprise kernel: Warning: bad magic number for tty struct
(4, 5) in tty_ioctl

Here is the oops

Oops: 0000
EIP: 0010:07200720
EFLAGS: 00010202
eax: 07200720 ebx: 00000000 ecx: 007b97d4 edx: 00055000
esi: bfffebb8 edi: 00055000 ebp: 00000000 esp: 00461f30
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process tail (pid: 190, process nr: 26, stackpage=00461000)
Stack: 00160bd4 00055000 00055000 00498b60 00407c60 00000114 00000000 007ec000
00461f4c 0015d297 00055000 00407c60 bfffeaa4 00000114 00407c60 00498b60
00000114 bfffeaa4 0011cebc 00498b60 00407c60 bfffeaa4 00000114 007ec000
Call Trace: 00160bd4 0015d297 0011cebc 0010a2f9

EIP = 07200720 (unknown)
Call trace = Trace: (unknown)
Call trace = 00160bd4 (write_chan + 0x0124)
Call trace = 0015d297 (tty_write + 0x00d7)
Call trace = 0011cebc (sys_write + 0x008c)
Call trace = 0010a2f9 (system_call + 0x0059)

The machine then fell over when the swapper died.

Iain Riley
- --
iain@iinet.com.au

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

From: linux <linux@pi8hrl.ampr.org>
Date: Sat, 22 Jul 1995 14:12:45 +0200 (MET DST)
Subject: Re: Z8530 driver in 1.3.11

>
>
> Joerg Reuter jr196930@lykos.tng.oche.de said:
> > 2. The driver i s under the GNU GPL already (*) and so Hans is free
> > to modify my work [...]
>
> After the way I flamed at Joerg to get him to put the GPL on his driver, it's
> embarassing that he should be abused this way.
>
I wonder how it is possible that Joerg can GPL a source if there is work
from me in it and i am also called as holder of the copyricht.
I noticed that Joerg has made his part of the source onder GPL licence.
So it is not more then normal in a fun project like linux, with i like
very much, to release also my copyrighted things of the source.
So i released my version for GNU with the small thinks joerg has
written in scc.c with has been released for GNU before.

I did only make the whole code free for GNU so everybody can work on it.

Greetings Hans

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

From: Andrew Veliath <drewvel@ayrton.eideti.com>
Date: Sat, 22 Jul 1995 16:25:13 -0400
Subject: Re: kernel config

On Fri, 21 Jul 1995, Roland Dunkerley wrote:

> Seriously, why would it need to be parsable from sh at all? Can
> include a flex/bison grammar (pre flexed/bisoned even, though I doubt
> this would at all be necessary, I would guess that flex and bison are
> much more ubiquitous on machines with development tools installed than
> perl would be.) with the rest of the kernel sources, that would get

Over the last two days I've got something sort of like what you are
talking about sort of working. Basically it is a flex/bison parser which
parses a configuration definition file which is itself piped through
cpp. The library/programs themselves are all written in c. I figured
that if you will compile the kernel, you will most likely have a c
compiler ;).

This "compilation" stage outputs a parent/sibling tree (binary format
though) to stdout which can then be saved or whatever. Two functions are
available to read or write the entire tree, and I've already created two
quick but not very functional hacks, one which reads this binary file and
outputs a configuration header, and the other which reads the binary file
and actually outputs an sh script to use the "dialog" program to query
the user about which options to have, and the writes a configuration
header. A tty one could easily be created as well (also necessary)...

Does anyone know of a higher level ncurses based UI library in C?

Basically the configuring program works on and saves the values in this
binary file, and a genconfig program is used to take that binary file
and create a header file (another method is to use something like the
sh-builder approach though). I was wondering, though, if it might be
better to produce a text file instead of a binary file, in a format
similar that of the original file (excluding comments and formatting),
but it might be larger.

A typical general configuration file to feed the parser might
look something like this, where the "implies" keyword means it requires
another section node.

/* an example */
section net_devs "network devices"
implies net_sup, sysv_ipc
{
helptext "Configuration of various network devices." &
"More help text.";

bool ne2000
{
helptext "Standard ne2000 Compatibles";
falsetext "#undef CONFIG_NE2000";
truetext "#define CONFIG_NE2000";

}

section net_more "Subsection"
{
helptext "more stuff here";
}
}

Since it is piped through cpp, macros can be used not to mention c-style
commenting and include files, also emacs c-mode ;-).

I am only playing with it and do not know if it is worth pursuing. I am
not sure about how to handle a few things, how many section
"descriptors" should there be? The keyword "implies" could mean that it
"expects" another section to already be included and if it is not to
query the user for it's inclusion. There could be "levels" of help...
If anyone has any ideas or suggestions they would be appreciated, there
are many things to consider or to and I really don't know too much about
"what's best." If anything were to be serious, it would have to be more
defined and slimmed down to the minimum parts.

One thing that could be done is to add an optional "file" keyword to the
body of section, allowing for more specific configuration headers and
less compiling. (I guess only the files affected need be generated)

Andrew Veliath <drewvel@ayrton.eideti.com>
http://ayrton.eideti.com/~drewvel

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

From: Eric Bosch <ecbosch@tyrell.net>
Date: Sat, 22 Jul 1995 12:19:44 -0500 (CDT)
Subject: Crashing Problems

I am running kernel 1.3.11, and am having system lockup problems. It
seems to be very repeatable. If I am in X and have a console open, doing
a find command the system locks solid. I was also attempting to do a
backup using backup script (backup-1.03) to tape, and have had a lockup
occur at the same place repeatedly (Seems to be after backup has completed)
Is this possibly pointing towards a bad block on the harddrive? If so,
how could I clean it up without major data loss? I have even tried
shutting off the cache in CMOS setup, with no change. I would appreciate
any help ANYONE could provide. Thanks a lot!

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

End of linux-kernel-digest V1 #127
**********************************