Files
2024-02-19 00:23:35 -05:00

694 lines
24 KiB
Plaintext

Subject: Linux-Development Digest #554
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: Tue, 15 Mar 94 10:13:13 EST
Linux-Development Digest #554, Volume #1 Tue, 15 Mar 94 10:13:13 EST
Contents:
Re: [Possible bug?] rm * on write-protected dos floppy (Koen Holtman)
Re: 127.x.x.x (was Re: UDP report card) (neil j.cherry)
Re: notebook doesn't warn when batteries are empty (Steffen Neumann)
Re: Error with ld when trying to use CheckerV0.3 (ld.so.1.9l.4) on linux (Nicholas Ambrose)
KODAK Photo-CD Question (Aapo Meili)
Re: 127.x.x.x (was Re: UDP report card) (The Answer is 42.)
Whereis liby.a for yacc? (Zhuo Er Lin)
Getting "screen-3.2b" to compile (Endaf Jones)
Re: GOD SPEAKS ON LINUX! (Joshua Drake)
Re: 127.x.x.x (was Re: UDP report card) (khockenb@vaxc.stevens-tech.edu)
Re: Assembly code debugger (Miguel de Icaza)
Re: [Possible bug?] rm * on write-protected dos floppy ("Alexander During")
signals questions (VAN NUFFEL ERIC)
Re: Loaded fonts discarded after X vt switch... (Markus Kuhn)
select (Frank McCabe)
g++/iostream library badly broken (Jinwoo Shin)
Re: UDP report card (Erick Herring)
----------------------------------------------------------------------------
From: koen@wswiop05.win.tue.nl (Koen Holtman)
Subject: Re: [Possible bug?] rm * on write-protected dos floppy
Date: 14 Mar 1994 14:49:15 +0100
gans@acf2.nyu.edu (gans) writes:
>The following procedure illustrates a bug on my system:
>I mount a 3.5 inch *write protected* floppy using
> mount -t msdos /dev/fd0 /mnt
>and then do
> cd /mnt; rm * (as root)
>ls reports that all files on the disk have been removed. There
>are no error messages. If the floppy is dismounted and then
>remounted, the files are, of course, still there.
[.....]
The Linux floppy drivers do not report write errors to the writing
program. This is more a case of broken-as-designed than an actual bug.
A real fix probably won't happen in the near future.
You do however get a kernel message if a write error occurs. If you really
care about the data you write to a floppy, monitor the kernel messages for
the string "floppy I/O error".
If you are running X, you can do this with an Xconsole. If you are using
a virtual console, you will have to make sure that the `level' of kernel
message printing is correct. There is a command to set this level, but I
can't remember its name right now. The level may have been set to suppress
floppy kernel messages at boot time in the rc or rc.local file.
> ---- Paul J. Gans [gans@acf2.nyu.edu]
Koen.
------------------------------
Crossposted-To: comp.protocols.tcp-ip
From: ncherry@cbnewsg.cb.att.com (neil j.cherry)
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: Mon, 14 Mar 1994 19:10:31 GMT
In article <CMo1yH.A82@boulder.parcplace.com> imp@boulder.parcplace.com (Warner Losh) writes:
>In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank
>Lofaro) writes:
>>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>>comment? If my interpretation is correct, 127.x.x.x should always be
>>looped back.
>>
>>Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
>>hold?
>
>I know of at least two commercial versions of IP that have had bug
>fixes applied to them that stop them from spitting out 127.* to the
>wire. I'm not aware of anything that supplants this requirement in
>RFC 1122.
>
>Any system that does spits 127.* to the wire is broken.
>
>Warner
In every commercial unix implementation I've worked with I can make 127.x.x.x
ride the ether, and I can switch it back. But I've always seen the 127 net
defaulted to l0 (loopback) or something like that.
NJC
------------------------------
From: sneumann@TechFak.Uni-Bielefeld.DE (Steffen Neumann)
Subject: Re: notebook doesn't warn when batteries are empty
Date: Mon, 14 Mar 1994 13:42:11 GMT
No solution, but an Idea what happens:
Linux puts your notebook into the protected mode and takes control.
If your notebook uses a bios routine that checks for low battery,
than it is not called anymore during use of linux.
(BTW, that happened to me, when the build in virus-checker did not
react to lilo boot-block magic, but started to get crazy when installing
MSDog...)
Steffen
--
Steffen Neumann Computer science is the dangerous try
sneumann@techfak.uni-bielefeld.de to overcome human intelligence
------------------------------
From: na2@doc.ic.ac.uk (Nicholas Ambrose)
Subject: Re: Error with ld when trying to use CheckerV0.3 (ld.so.1.9l.4) on linux
Date: 14 Mar 1994 15:04:25 -0000
In article <1994Mar10.053846.13233@mlb.semi.harris.com>, crw@maniac.mlb.semi.harris.com (Carl Williams) writes:
|> I am trying to get the Checker program (V0.3) to work and
|> am having trouble with ld when I try to run Checker.
|>
|> Specifically , I am running linux-0.99.15, and I just installed
|> gcc2.5.8, libc.4.5.21, and CheckerV0.3 (I installed all of the
|> above as I wanted to use Checker !! and the README said I needed
|> a gcc at least 2.5 something (I was at gcc2.4.5 before) ).
|>
|> In installing the above I installed ld.so.1.9l.4.
|>
|> After all this when I try to compile a program with checkergcc I get:
|> # checkergcc test.c -o test
|> ld: unrecognized option `-checker'
possibly Checker is using -checker instead of -l checker
|> Usage: ld [-d] [-dc] [-dp] [-e symbol] [-l lib] [-n] [-noinhibit-exec]
|> [-nostdlib] [-o file] [-r] [-s] [-t] [-u symbol] [-x] [-y symbol]
|> [-z] [-A file] [-Bstatic] [-D size] [-L libdir] [-M] [-N]
|> [-static] [-nojump] [-dll-verbose] [-S] [-T[{text,data}] addr]
|> [-V prefix] [-X] [file...]
|>
|> I tried to use the ld.diff file (that came with the CheckerV0.3)
|> to make a new ld.so
|> , but it seemed wildly different
|> than the ld.c file the diff file was compared against (the ld.diff
|> file starts it's changes at line 1154, and the ld.so.c file
|> for ld.so.1.9l.4 has only 458 lines.
|>
|> Can you help/ any suggestions ?
|>
|> Thanks,
|>
|> --Carl
|> crw@harris.mlb.semi.harris.com
Well, a simple solution is to use dbmalloc. it's easy to use. Just include
their own malloc.h file, and link with -ldbmalloc. if this does what
you want, hen that would seem easier ... This is the most simple way
of using dbmalloc admittedly, but iot seeme to pick up most of the stupid
errors and works well for me ...
Nick
--
If someone had told me I would be Pope one day, I would have studied
harder.
-- Pope John Paul I
------------------------------
From: meili@srztm304.alcatel.ch (Aapo Meili)
Subject: KODAK Photo-CD Question
Reply-To: meili@.alcatel.ch
Date: Mon, 14 Mar 1994 15:04:39 GMT
------------------------------
From: jwiegand@opus.temple.edu (The Answer is 42.)
Crossposted-To: comp.protocols.tcp-ip
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: 15 Mar 1994 02:45:11 GMT
In article <1994Mar14.011113.2735@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
>In article <Mar.13.17.50.52.1994.1393@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>>ftlofaro@unlv.edu (Frank Lofaro) writes:
[ ... ]
>>>Linux USED TO handle 127.x.x.x right for all values of x.
>>>Now all 127.x.x.x address other than 127.0.0.1 seem to try to send out
>>>the default route.
>>>This is bad, can we bring back the old behavior (thus not violating the RFC's
>>I'm not convinced that it's right for 127.0.0.2 to be regarded as
>>loopback. But if you want it, you can get it. It's all a matter of
[ ... ]
>However, I think that all 127.x.x.x addresses should be loopback.
>1: It does not break anybody's set up, unless they are violating RFC's
>by using the 127 net for their own purposes (they deserve to lose, they
>aren't interoperable)
>2: Have 127.x.x.x always be loopback is MANDATED by rfc1122.
>RFC1122:
[...]
> (g) { 127, <any> }
> Internal host loopback address. Addresses of this form
> MUST NOT appear outside a host.
>--- end of RFC excerpts.
>Anyone in comp.os.linux.development or comp.protocols.tcp-ip want to
>comment? If my interpretation is correct, 127.x.x.x should always be
>looped back.
>Is rfc1122 obsolete? Or does the 127.x.x.x statemnet shown above still
>hold?
Gee, my sun here misbehaved even though it's right there in
/etc/networks:
localnet 127 loopback
I wonder why the loopback ping went all out to God Knows Where?
jim
a virtual alice in netland
------------------------------
From: umlin000@cc.umanitoba.ca (Zhuo Er Lin)
Subject: Whereis liby.a for yacc?
Date: 14 Mar 1994 02:19:31 GMT
The subject says it. I need to link the parser generated by byacc
but no liby.a.
--
========================================================================
| Eric Lin Voice: (204) 783-2884 |
| Computer Engineering FAX Modem: (204) 783-2884 |
| University of Manitoba Internet: Umlin000@cc.Umanitoba.CA |
------------------------------
From: ejones@zener.cuug.ab.ca (Endaf Jones)
Subject: Getting "screen-3.2b" to compile
Date: Wed, 9 Mar 1994 22:31:09 GMT
Has anyone gotten screen-3.2.b to compile under Linux?
I was aware of a thread back a month ago or so, but didn't follow
up on it as I didn't need screen then, but I do now.
When I try to compile it, I get numerous errors and the Config script
dosn't create the required *.h files .
--
Endaf Jones Calgary, Alberta, Canada VE6END (2m & 33cm)
ejones@zener.cuug.ab.ca Zener Online Systems
jonese@cuug.ab.ca Calgary Unix Users Group
Endaf.Jones@qm.nt.com Northern Telecom (MCS-C)
------------------------------
From: drake@teleport.com (Joshua Drake)
Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: GOD SPEAKS ON LINUX!
Date: 13 Mar 1994 18:45:32 -0800
What the hell is god to linux....
Lewis (ljt3@PL122b.lehigh.edu) wrote:
: In article <2lklvr$h2v@nermal.cs.uoguelph.ca> gbuhlman@uoguelph.ca (Glen Buhlmann) writes:
: >someone else writes:
: >: I'll have you know I'm sitting right here in front of god, and god is
: >: running Linux.
: >I am God......and I use an Amiga......
: Running Amiga Linux, I assume. :-)
: --
: Lewis Tanzos - ljt3@[cs1.cc/pl122.eecs].lehigh.edu - ljt3@Lehigh.edu
: "By the common conception, humankind doesn't consider something 'worth
: it' unless they get their investment back -- preferrably with profit.
: ...By this criterion, most of the Universe is 'not worth it'"
--
drake@teleport.COM Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-1016 (1200/2400, N81)
------------------------------
From: khockenb@vaxc.stevens-tech.edu
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: Mon, 14 Mar 1994 03:39:32 GMT
In article <Mar.13.21.14.06.1994.1486@geneva.rutgers.edu>, hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
> By the way, the same problem occurs with incoming packets. If a
> machine is misconfigured so that it sends to 127.0.0.1 on an Ethernet,
> I believe we should not respond to an ARP response, and if a packet
> addressed to 127.0.0.1 somehow comes from the outside, it should be
> silently dropped.
I think it would be nice if the packet was dropped and a message was
written to syslog with the offending host's ethernet address, so I could
track down the misbehaving machine.
Does that sound reasonable?
-Kurt Hockenbury
------------------------------
From: miguel@xochitl.nuclecu.unam.mx (Miguel de Icaza)
Crossposted-To: gnu.gcc.help
Subject: Re: Assembly code debugger
Date: 14 Mar 1994 20:38:38 GMT
> Does anyone know whether there is some sort of assembly language debugger
> for Linux (ie i386/486). I need some way to single step through a couple of
> assmebler routines which I wrote.
> It would be nice if the debugger handled C/C++ code as well, but that isn't
> crucial.
You can use gdb.
To see the current assembly instruction, I use:
display/i $pc
To see the registers: info regs
To disassemble the current function:
disassemble
To disassemble a block of code:
disassemble $pc $pc+0xA0
In your .gdbinit in the default directory I have some macros for all
this (def r as info regs, and the like).
To single step in assembler, you use: nexti and stepi (the
corresponding next and step instructions but for assembly).
Hope this helps,
Miguel.
--
Miguel.
------------------------------
From: 63912i@cfi.waseda.ac.jp ("Alexander During")
Subject: Re: [Possible bug?] rm * on write-protected dos floppy
Date: 15 Mar 1994 03:19:32 GMT
In article <2m1q0r$627@wswiop05.win.tue.nl> koen@wswiop05.win.tue.nl (Koen Holtman) writes:
>gans@acf2.nyu.edu (gans) writes:
>
>>I mount a 3.5 inch *write protected* floppy using
>> mount -t msdos /dev/fd0 /mnt
>>and then do
>> cd /mnt; rm * (as root)
>>ls reports that all files on the disk have been removed. There
>>are no error messages. If the floppy is dismounted and then
>>remounted, the files are, of course, still there.
>[.....]
>
>The Linux floppy drivers do not report write errors to the writing
>program. This is more a case of broken-as-designed than an actual bug.
>A real fix probably won't happen in the near future.
>
>> ---- Paul J. Gans [gans@acf2.nyu.edu]
>Koen.
I wonder whether there could be done something about this. Suppose you
could test the write protection status of the floppy without writing to
it. Suppose furthermore that mount() calls the init routine of the
floppy driver. As we are at it, suppose that mount() tells the floppy
driver that it wants to access the floppy in a read/write fashion and
not just readonly.
Couldn't the floppy driver return an error, similar to the one you get
if there is no floppy at all in the drive? This would lead to a behaviour
where you couldn't use a write protected floppy at all, unless you mount
it read-only. This is somewhat more strict than now, where you can mount
it read/write and get the errors later, but nevertheless, it seems
cleaner to me...
However, there is a philosophy problem involved, as far as I see it,
which is that the use of the drive for read or write is not really
clear at mount time, is it? The thing is, if it is possible, I would
gladly do it, if somebody could point out to me a) whether it makes
sense and b) where. My idea is to forbid opening the floppy device as
read/write if the floppy is write protected. An idea (as far as I see
now) would be to make floppy_ready() in floppy.c garble somthing or
other, so mount barfs or return somthing sensible somewhere, but all
the functions with promising names in floppy.c are void...
I think it's possible to add a new ioctl command to test write protection,
so mount could be patched to use this. But one would have to implement
all that in every single blk-driver written so far, which is clearly
too much work. How are CD-ROMs handled? Is it the filesystem that account
for R/O mounting?
As I said, if somebody could point out where, I'd gladly patch the floppy
routines.
Alex
--
As MS-DOS is very abstruse, \\it's also quite tricky to use. \\So many give in
and try typing 'win'. \\But that means completely to lose.
Alexander D\"uring, Physics Department, Waseda University, Tokyo, Japan.
Statistical Physics, Linux, Shakespeare. --- This space for rent ---
------------------------------
From: evnuffel@vub.ac.be (VAN NUFFEL ERIC)
Subject: signals questions
Date: 15 Mar 1994 08:03:05 GMT
Hi,
I'm quite new to linux and I hope this message is in the right newsgroup !
I got to work on the release 0.99 patchlevel 13.
I have to analyse the signals system and I encounter some problem with it.
In signal.c , in the do_signal function, there are some lines I can't
understand.
Here is one:
__asm__("bsf %2,%1\n\t"
"btrl 1,%0"
:"=m" (current->signal),"=r" (signr)
:"1" (signr));
Of course, I know this is ASM and bsf is "bit scan forward" (if I remember)
but I dont understand the %i, \n, \t, "=m",....
If someone can explain me this line, or better tell me the principle of ASM
in linux code (so I wont have to ask for each ASM line I encounter) it will
greatly help me.
Another thing: If anyone has docs and explanations on the signal code,
please send this to me.
TRUNOLD.
evnuffel@is2.vub.ac.be
------------------------------
From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
Subject: Re: Loaded fonts discarded after X vt switch...
Date: Tue, 15 Mar 1994 09:39:42 +0100
Reply-To: mskuhn@cip.informatik.uni-erlangen.de
aeb@cwi.nl (Andries Brouwer) writes:
>If you have freely distributable stuff, and it is not too much,
>you might send it to me - I would probably put it into kbd-0.86.
I have put ISO 8859 fonts (for all 10 sets) on ftp.uni-erlangen.de
in pub/doc/ISO/charsets/isofont*. They have been made by Kosta
Kostis. They are available in all the usual VGA resolutions.
Perhaps you'd like to add them to your kbd package. (The ftp
server is down at the moment, but should be up soon again)
Markus
--
Markus Kuhn, Computer Science student +0o0; University of Erlangen, Germany
Internet: mskuhn@cip.informatik.uni-erlangen.de | X.500 entry available
------------------------------
From: fgm@doc.ic.ac.uk (Frank McCabe)
Subject: select
Date: 15 Mar 94 10:07:30 GMT
A while ago I posted a request/comment about the select system call -- that
it doesnt properly timeout.
I missed the followup thread, but someone else has said to me that the
consensus was that I wasnt filling in the timeval record properly. (Some
people made the same comment to me privately).
Forgive me if I am wrong, but I believe that I DO fill out the timeout value,
and here is the offending code:
static int ns_select(long time_out)
{
fd_set rset,wset,eset;
struct timeval timeout;
int status;
int mask = sigblock(sigio_mask); /* block SIGIO signals */
again:
FD_ZERO(&rset);
FD_ZERO(&wset);
FD_ZERO(&eset);
FD_SET(ns_socket, &rset);
timeout.tv_sec = time_out;
timeout.tv_usec = 0L;
status = select(ns_socket+1,&rset,&wset,&eset,&timeout);
if (status == -1) {
if (errno == EINTR)
goto again;
else {
perror("select() error ");
CloseAddressBook();
exit(1);
}
}
sigsetmask(mask);
return(status);
}
This program is called just once (I have another select for other purposes)
at the startup of my system:
if (ns_select(TIMEOUT) && read_msg(&msg, &ns, ns_socket)) {
where TIMEOUT is #defined:
#define TIMEOUT 5L /* max time (secs) to wait for nameserver */
The behaviour that is exhibited is that the select returns immediately, with a
value of 1 (i.e., one FD ready).
A subsequent recvfrom system call on the `ready' FD returns the error
ECONNREFUSED (which is a TCP -level error message on a UDP system call).
Now, if someone can identify the bug in this code I would be grateful and
humbled.
I would just add the final comment that this program compiles and executes
correctly under sunos 4.1.3
Frank McCabe
===================
My opinions are mine - no-one else is allowed to have them
------------------------------
From: c61b-1ew@web-1a.berkeley.edu (Jinwoo Shin)
Subject: g++/iostream library badly broken
Date: 15 Mar 1994 09:17:08 GMT
I have installed on my home machine Slackware 1.12 and I'm having bit of a
difficulty with gcc/g++ that came with the distribution. I know that some
of you will flame me for posting g++ question on linux newsgroup, but I
noticed that g++ on Sun at work didn't have the same problem so I figured
it was port specific problem. I'm running gcc.2.5.8 and the latest libraries
(came with slackware, i'm not home ... so can't quote you on the version)
and some of the iostream functions are behaving badly.
For instance:
cin.getline(buffer,80) is supposed to add '\0' after the entered string
in buffer, but this port fails to do so.
cin.clear() doesn't always clear the buffer completely.
etc.etc.etc...
Anyone know what the problem is?
Thanks in advance
P.S. Please reply in email
------------------------------
From: herring@iesd.auc.dk (Erick Herring)
Subject: Re: UDP report card
Date: 14 Mar 1994 21:24:18 GMT
>>>>> "CHedrick" == Charles Hedrick <hedrick@geneva.rutgers.edu> writes:
ftlofaro@unlv.edu (Frank Lofaro) writes:
>> Linux USED TO handle 127.x.x.x right for all values of x. Now
>> all 127.x.x.x address other than 127.0.0.1 seem to try to send
>> out the default route. This is bad, can we bring back the old
>> behavior (thus not violating the RFC's anymore like we are
>> now)?
CHedrick> I'm not convinced that it's right for 127.0.0.2 to be
CHedrick> regarded as loopback. But if you want it, you can get
CHedrick> it. It's all a matter of how you set up routing when
CHedrick> you turn on loopback. I just enabled lo (which I
CHedrick> normally don't have running) using
CHedrick> ifconfig lo 127.0.0.1
CHedrick> route -n add 127.0.0.0 dev lo
What exactly does "not convinced" mean? If you are putting packets
destined for 127.rrr.rrr.rrr on the wire, you're losing.
Without regard to how the machine is set up, 127 is loopback. I have
appended some of the appropriate RFC sections below.
RFC 1340 "Assigned Numbers"
(Reynolds & Postel)
There are certain special cases for IP addresses [11]. These special
cases can be concisely summarized using the earlier notation for an
IP address:
IP-address ::= { <Network-number>, <Host-number> }
or
IP-address ::= { <Network-number>, <Subnet-number>,
<Host-number> }
[...]
(g) {127, <any>}
Internal host loopback address. Should never appear outside
a host.
RFC 1166 "Internet Numbers"
(Kirkpatrick, Stahl & Recker)
[...]
Special Addresses:
In certain contexts, it is useful to have fixed addresses with
functional significance rather than as identifiers of specific
hosts.
[...]
The class A network number 127 is assigned the "loopback"
function, that is, a datagram sent by a higher level protocol
n to a network 127 address should loop back inside the host. No
datagram "sent" to a network 127 address should ever appear on
any network anywhere.
[...]
Class A Networks
* Internet Address Network Name References
- ---------------- ------- ---- ----------
*127.rrr.rrr.rrr Loopback Loopback [JBP]
RFC 1537 "Common DNS Data File Configuration Errors"
(P. Beertema)
[...]
Also each nameserver should run primary for 0.0.127.in-addr.arpa;
that zone file should contain a SOA and NS record and an entry:
1 PTR localhost.
There has been extensive discussion about whether or not to append
the local domain to it. The conclusion was that "localhost." would be
the best solution; reasons given were:
[...]
------------------------------
** 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
******************************