Files
oldlinux-files/docs/mail-archive/linux-devel/Volume1/digest5XX/digest530
2024-02-19 00:23:35 -05:00

284 lines
10 KiB
Plaintext

Subject: Linux-Development Digest #530
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: Wed, 9 Mar 94 01:13:05 EST
Linux-Development Digest #530, Volume #1 Wed, 9 Mar 94 01:13:05 EST
Contents:
UDP report card (Chris Anderson)
DPT Driver whill be availble (cyril szenberg)
Re: Small pre-1.0 problem (Rob Janssen)
Re: AMD 486DX problem (with Linux?) (Mathew Ong)
Re: Amiga FileSystem, Anyone? (Lee Heins)
Re: PLEASE use the GPL -- NOT (Nick Andrew)
[Q] What's bsd_ioctl ? (Steven Yampolsky)
----------------------------------------------------------------------------
From: christop@access1.digex.net (Chris Anderson)
Subject: UDP report card
Date: 8 Mar 1994 20:23:46 -0500
Three things seem kinda odd:
1. A sendto INADDR_ANY as a destination gives me a ENETUNREACH. This errno is
new for me, in other environments the local process bound to either the
loopback or one of the machine's inet addresses gets the message.
2. A sentto destination of my local address when there isn't a process bound
to it, returns a ECONNREFUSED. I've never encountered this behavior before.
3. A recvfrom trashes the 8 bytes at the end of a sockaddr_in. This seems
kinda sloppy. The code on line 484 of net/udp.c is where this happens.
Other than that, I'm a happy FIONBIO/SOCK_DGRAM/select() user.
I'm using pl15b with a 3Com etherlink II card on a two machine network with
the other running sys V r4 mounting nfs drives and using rlogin / telnet
regularly without any problems. And, I might add, very happy with the
portability of Linux applications.
Happy Hacking,
Chris
------------------------------
From: cyrilsz@renux.frmug.fr.net (cyril szenberg)
Subject: DPT Driver whill be availble
Date: 7 Mar 1994 18:58:23 GMT
i am finish optimise my dpt driver it is alrady runnig under my machine
a 486 DX 50 whith a DPT 2122 , but of corse in write the driver for all
board (i hop ;-) ) ,but in dma mode only for th e moment but if there is
some peaple with board not support dma i whill see .
My english is not perfect i am sorry .
So i will release it a the end of this week for the first alpha version
Bye
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Small pre-1.0 problem
Date: Tue, 8 Mar 1994 22:27:36 GMT
Reply-To: pe1chl@rabo.nl
In <CMCvGH.6Ex@scr.siemens.com> aoppelt@scr.siemens.com (Achim Oppelt) writes:
>kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
>>I have just compiled pre-1.0 and have a strange problem. I've never seen it
>>before.
>>My /proc/version contains:
>>Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994
>>[87 rebuilds, that's sick!]
>>My /etc/issue contains (generated from /proc/version in rc.local):
>>Linux version pre-1.0 (root@krayzee) #87 Tue Mar 8 21:01:21 EST 1994
>>BUT muy virtual consoles say this above the login prompt:
>>Linux version pre-1.0 (rootrayzee) #87 Tue Mar 8 21:01:21 EST 1994
>>Note the contents of the brackets. Where did those 2 characters disappear
>>to?
>>[486/dx50, 32 meg ram, 2xide, 1xSCSI, T130B controller, cluster patches]
>>--
>>[==================================================================]
>>[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
>>[ kevinl@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
>>[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
>>[==================================================================]
>I assume you are using getty_ps, which interprets certain @-character
>sequences and replaces them with things like hostname, number of users
>logged in etc. @k is probably not defined, so it is simply stripped.
>(I cannot check this out since I currently do not have acces to my
> Linux box, which is at home in Germany :-( )
>So this has nothing to do with pre-1.0.
Indeed. Just use the output of "uname -a" instead of the /proc/version
file...
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: ongmek@cs.curtin.edu.au (Mathew Ong)
Subject: Re: AMD 486DX problem (with Linux?)
Date: 9 Mar 94 02:11:32 GMT
mckesey@imaphics.prior.com (Gregory McKesey) writes:
> Wen-Chun> I do believe that the code itself is much more
> Wen-Chun> problematic.
>You may be right, but the test was not really to test for equality.
>The test was thrown in as an after thought. I certainly did not mean
>to have the program run on anything other that 486's. The purpose of
>program was simply to multiply two numbers and show that my amd486 did
>not compute the correct value for the float calculation.
>IE. the output:
>1.312500 * 7.999900 =10.499990
>1.312500 * 7.999900 =10.499869
>is really what concerns me. 1.312500 * 7.999900 does not equal 10.499990
>no matter what kind of rounding rules you may use. The rest of the
>program and output is irrelevant. If boot my system with the no387 option
>or recompile the program with the msoft-float option, the program
>gives a more accurate result.
I have heard that the AMD 486dx40 chip has *IDENTICAL* micro-code
as that of Intel's chip...so how come there is this float problem.
(Can any one verify this?)
Most of the hardware discussions I've seen believes there can't be
any difference what-so-ever between the two chips in terms of
their output. (Unless AMD has poorer quality assurance on their products).
Another 2 cents worth...(I think with all the cents collected in these groups
we'd all be rich :) )
Mat
(found just outside the door)
------------------------------
From: leeh@i-link.com (Lee Heins)
Subject: Re: Amiga FileSystem, Anyone?
Date: 8 Mar 1994 17:49:29 -0600
In article <1994Mar6.130716.5368@pe1chl.ampr.org>,
Rob Janssen <pe1chl@rabo.nl> wrote:
>In <DHOLLAND.94Mar5232531@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>
>>The strange stuff the trackdisk.device does should be possible with PC
>>hardware, unless that hardware is even less capable than I thought. If
>>the Amiga does something else, like write more tracks than the average
>>PC drive can access, I don't know about it.
>
>The PC has a specialized floppy disk controller that understands and
>handles the industry-standard MFM format of formatting diskettes.
>The Amiga does not use that standard format (and neither does the Mac)
For Mac 800k format this is true, for Mac 1.4M format, this is not
true, it uses the same low level MFM format as MS-DOS does on their 1.4M
3.5" floppies. There is a program for Linux called xhfs (and there are a
couple for MS-DOS) which will let a PC-clone 1.4M 3.5" drive read Mac format
1.4M floppies. For Mac 800k floppies, they use a variable spindle speed
(like CD-ROM drives) which most PC clone floppy drives aren't capable of.
Mac 800k disks are also GCR encoded instead of MFM, but that is something
that it is probably possible to do in software with PC-clone style floppy
mechanisms. The Amiga is also GCR, although they use variable bit rate
density zones (similar to that used on many IDE hard drives) instead of
variable spindle speed.
>Classification of 'more or less capable' is entirely yours. I would say
>the PC disk controller is more capable, in that it handles tasks that
>need to be done in software on the Amiga and Mac.
Also untrue for the Mac for 1.4M floppies at least, the MFM hardware is
built into the SWIM (floppy controller) chip. I think what he meant was
"more flexible" more than "more capable".
All in all, it looks like is impossible to handle either 880k Amiga disks
or 800k Mac disks on PC-clone style floppy mechanisms.
>--
>-------------------------------------------------------------------------
>| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
>| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
>-------------------------------------------------------------------------
--
Lee Heins, leeh@i-link.com
------------------------------
From: nick@kralizec.zeta.org.au (Nick Andrew)
Subject: Re: PLEASE use the GPL -- NOT
Date: 2 Mar 1994 07:48:32 +1100
In <2kgq7k$29j@snoopy.cis.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes:
>[...] the authors might suddenly claim their original work was really very
>valuable, and they should get compensated for it now.
Under the GPL, authors cannot enforce compensation for the GPL'ed work
because the user is granted a specific right to copy and distribute the
program, so the author cannot charge money for such distributed copies.
Nick.
--
Kralizec Dialup Unix (Public Access) Data: +61-2-837-1183, 837-1868
Zeta Microcomputer Software v.42bis v.32bis 14.4k 24 hours
P.O. Box 177, Riverstone NSW 2765 Plan: To beat Gnuchess 4.0 fairly!
------------------------------
From: minsk@ccs.neu.edu (Steven Yampolsky)
Subject: [Q] What's bsd_ioctl ?
Date: Wed, 9 Mar 1994 05:03:24 GMT
Hi!
For the past couple of days I've been trying to port SPIM MIPS
Emulator 5.2 to Linux. Yesterday I got stuck on a linking error:
spim.o: Undefined symbol _bsd_ioctl referenced from text segment
The only reference to bsd_ioctl is in /usr/include/bsd/sgtty.h which
goes something like this:
#undef ioctl
#define ioctl bsd_ioctl
Can somone help me here?
Thanks in advance,
Steven Yampolsky
e-mail:minsk@ccs.neu.edu
------------------------------
** 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
******************************