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

540 lines
22 KiB
Plaintext

Subject: Linux-Development Digest #556
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, 16 Mar 94 03:13:09 EST
Linux-Development Digest #556, Volume #1 Wed, 16 Mar 94 03:13:09 EST
Contents:
Re: Specialix Driver Round 2 (From specialix) (David Wright)
Re: Linux 1.0 problems (No free VT) (Grant Edwards)
Re: UDP report card (Roger Binns)
Re: [Q] Unixware filesystem? (H. Peter Anvin N9ITP)
Re: 127.x.x.x (was Re: UDP report card) (Warner Losh)
Re: Matrox drivers (Dirk Hohndel)
Re: 127.x.x.x (was Re: UDP report card) (Mark Evans)
Re: 127.x.x.x (was Re: UDP report card) (Barry Margolin)
Future development of Linux and affects on other architectures (Hamish Macdonald)
Does XFree support ET4000 (Hercules Dynamite) video cards (Kevin Rosenberg)
Re: Amiga File System, once again (Alan Braggins)
Re: select (Warner Losh)
Linux 1.0 old problem, new problem... (Paul Smith)
Re: 127.x.x.x (was Re: UDP report card) (Alfred Longyear)
Linux 1.0 problems (No free VT) (Gene Choi)
Re: Lint for Linux? (Nicholas Ambrose)
----------------------------------------------------------------------------
From: dmw@prism1.prism1.com (David Wright)
Subject: Re: Specialix Driver Round 2 (From specialix)
Date: 15 Mar 94 14:10:40 GMT
>>>>> "DJB" == Donald J Becker <becker@super.org> writes:
DJB> In article <cdh.763034702@specialix.co.uk>,
DJB> Alan Drew <cdh@specialix.co.uk> wrote:
>> A device driver (Partcularily an Intelligent device driver) usual fits
>> something like this (in block diagram format) into your system.
>>
>> +-----+ +--------------+ +---------------+ +-------------------+
>> | O/S |----| Device Driver|-----| Download Code |----| modem/terminal etc|
>> +-----+ +--------------+ +---------------+ +-------------------+
DJB> I disagree with this diagram. The vast majority of devices have a
DJB> register-level interface that appears as hardware, and the device drivers
DJB> are tightly integrated with the kernel
DJB> +--------------------+ +------------------------------------------+
DJB> | O/S + Device Driver|-----| modem/terminal etc (opt. Download Code))|
DJB> +--------------------+ +------------------------------------------+
All of the "good" boards I have seen actually follow the first layout.
The only way I can see the 2nd scheme working is for not-very-good boards that
look (at a hardware level) like "standard" com ports. A decent *intelligent*
I/O card should not waste it's time looking like a standard COM[123] port.
You won't get anywhere with a DigiBoard or Specialix intelligent card trying to
talk to it like a "dumb" I/O multiport adapter under DOS. DOS has no idea the
card is even there, or what it is. You need their special driver which
downloads their own custom OS to the card, along with some version of card
specific drivers (which execute under the special OS), and then patches the
apropriate HOST operating system (DOS, Unix, etc) to be able to talk to it.
Very clearly the portion that actually "hooks into" the OS would be
covered by the GPL, and not one of the developers has said they have a
problem with that. But the code that actually runs on the CARD is *not* OS
specific, is the same for DOS, Unix, whatever, and could be provided in
binary-only format with no problems.
The 2nd. diagram may be how it appears to someone who is just doing
IOCTL's to talk to the device, but it is leaving out the portion that the
discussion was about (the downloaded code that runs on the card itself).
Dave
--
____________________________________________________________________________
| /\ / | Prism Computer Applications | David Wright |
| -/--\-- | 14650 Detroit Ave, Suite LL40 | dmw@Prism1.COM |
| /____\ | Lakewood, OH 44107 USA | 216-228-1400 |
------------------------------
Crossposted-To: comp.os.linux.help
From: grante@aquarius.rosemount.com (Grant Edwards)
Subject: Re: Linux 1.0 problems (No free VT)
Date: Tue, 15 Mar 1994 18:54:17 GMT
Gene Choi (genie@sting.Berkeley.EDU) wrote:
: I changed 0 things in my setup from my move from pl15 to 1.0. Xfree
: complains about having no free VT.
Well, do you have free VTs?
--
Grant Edwards |Yow! Don't worry, nobody
Rosemount Inc. |really LISTENS to lectures in
|MOSCOW, either! .. FRENCH,
grante@rosemount.com |HISTORY, ADVANCED CALCULUS,
|COMPUTER PROGRAMMING, BLACK
|STUDIES, SOCIOBIOLOGY!.. Are
|there any QUESTIONS??
------------------------------
From: rogerb@x.co.uk (Roger Binns)
Subject: Re: UDP report card
Date: Tue, 15 Mar 1994 19:21:04 GMT
Warner Losh (imp@boulder.parcplace.com) wrote:
: enough to make assigning a large block of addresses a problem. Now
: they are redesigning IP to handle more than 4 billion hosts[*]...
Is this anywhere near enough. Most people here use two machines, plus there
are all sorts of xterms, fridges, coffee machines etc. I can easily see
the ratio of ip addresses per person being >1, and those numbers will
run out in a faily sparse ass IP nets are.
Roger
--
__ __ __ __
| |\ / /| | Roger Binns | `Don't go near Earth, its got human
| | \/ / | | Software Engineer | beings on it. They are contagious.'
| | / /\ | | IXI Ltd | Lister
|__|/__/__\|__| Cambridge, UK | rogerb@x.co.uk
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP)
Subject: Re: [Q] Unixware filesystem?
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Tue, 15 Mar 1994 19:45:25 GMT
In article <2m25ee$iv4@cville-srv.wam.umd.edu> of comp.os.linux.development,
barspi@wam.umd.edu (Barzilai Spinak) writes:
> After 1 1/2 years of waiting, I will shortly have a BIG computer and
> will install Unixware, Linux and Windows (ugh! ...I need to). My question
> is if there's a Unixware filesystem the Linux can use. I don't know anything
> about Unixware yet and I don't know if it uses a proprietary filesystem
> or not.
Unixware probably uses either UFS or the SysV filesystem. Linux
supports the SysV filesystem; it does not support UFS.
Excuse the question, but why do you want both Unixware and Linux? I
am just curious.
/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
--- The real message begins here ---
------------------------------
From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: Tue, 15 Mar 1994 18:13:38 GMT
In article <HERRING.94Mar14224420@hardy.iesd.auc.dk>
herring@iesd.auc.dk (Erick Herring) writes:
> CHedrick> One could argue that rc.local is part of the system as a
> CHedrick> whole, and it's the responsibility of the people
> CHedrick> creating setup scripts to make sure that the loopback
> CHedrick> interface is always turned on properly. I guess I'd be
> CHedrick> willing to accept that, but it would make me feel
> CHedrick> slightly better to know that 127 will never leave the
> CHedrick> machine.
>
>I really think that we are in violent agreement about this -- the
>question, then, is how do we keep them off of the wire?
I must agree with Eric on this one. rc.local is not really part of
the system as provided. It is something that the user is expected to
hack, munge, whatever. I don't want to have to tell 1000000 people
that boot linux to make sure they don't muck with the loopback stuff.
It is one more thing for a novice to break/forget. Heck, when I had
my Linux machine on the network, I didn't even think to add the
loopback stuff, and I even added it wrong a couple of times. This is
from someone with 8 years of TCP/IP configuration/programming
experience who was clueful and did read the FAQ and HOWTO and every
other doc that I could get at the time.
The Kernel should put 127 in the routing tables by default, but it
should allow its removal by a knowledgible enough user (which could
mean recompiling the kernel, for example). Give the troubles that
putting 127 on the wire causes, I think that this special case is
suffient reason to violate whatever purity requirements dictated that
you not automatically add the route.
Otherwise, the Linux IP code will get a bum rap from all the sys
admins that have to chase the problem down.
In addition, 127.* should be ignored when received as well, if that
isn't already happening. I had thought this was clear by implication,
but private email seems to indicate otherwise.
Warner
--
Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
more serious personality disorders"
------------------------------
From: hohndel@physics.su.oz.au (Dirk Hohndel)
Subject: Re: Matrox drivers
Date: 15 Mar 1994 19:40:18 GMT
John Wagner (jwagner@mental.mitre.org) wrote:
: so has anybody written a driver for the Matrox MGA-II cards for Xfree-86
: yet?? I just got my new system with the 4meg version and would like to
: run linux on it, but I've heard that the drivers that come with the card
: do NOT support Xfree. I could still use my 386 to run linux, but the
: pentium sure would be nice :)
There isn't a driver and I seriously doubt there ever will be ine for
XFree86[tm].
Dirk
--
_ _ _ _ _ | The XFree86 Project, Inc.
| | | |_) |/ |_| | | |_| |\ | | | |_ | | XFree86@physics.su.oz.au
|_/ | | \ |\ | | |_| | | | \| |_/ |_ |_ | hohndel@physics.su.oz.au
------------------------------
Crossposted-To: comp.protocols.tcp-ip
From: evansmp@mb48026.aston.ac.uk (Mark Evans)
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: Tue, 15 Mar 1994 19:02:02 GMT
Warner Losh (imp@boulder.parcplace.com) wrote:
: 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.
As also (IMHO) is any system which accepts such an address and either
trys to route it or send it to a user process. (Or for that matter chucks
out an ICMP error in response)
------------------------------
From: barmar@think.com (Barry Margolin)
Crossposted-To: comp.protocols.tcp-ip
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: 15 Mar 1994 21:21:14 GMT
In article <2m37fn$jdd@cronkite.ocis.temple.edu> jwiegand@opus.temple.edu (The Answer is 42.) writes:
>Gee, my sun here misbehaved even though it's right there in
>/etc/networks:
>
>localnet 127 loopback
/etc/networks has nothing to do with routing. It's just a
symbolic-to-numeric map, like /etc/hosts is for host names.
>I wonder why the loopback ping went all out to God Knows Where?
Look in your routing table. You'll see a host entry for 127.0.0.1, but not
a network entry for 127.0.0.0. So it will send to the default router.
Who ever claimed that SunOS conformed to everything in RFC 1122?
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
------------------------------
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Future development of Linux and affects on other architectures
Date: 15 Mar 1994 21:21:06 GMT
I'd just like to mention here that anyone who is developing new
features in Linux, or is enhancing existing features to add new
functionality should keep in mind that Linux is being ported to other
architectures.
Any time you feel the urge to put inline assembler into code which has
no direct link to either the i386 architecture or the IBM PC clone
architecture, think twice before doing so.
If you absolute must put in inline assembler (speed reasons are the
only possible reason I can see), please abstract it out into an
"inline function" or a preprocessor macro, and keep the definition of
the inline function or macro separate from the main functionality.
If you follow rules like this, then it makes porting of these new
features to Linux on other architectures easier.
An example of the benefits of this is the fact that the "net/unix"
Unix domain socket code ported over to Linux/68k with absolutely no
changes required to the source. I was very happy when I was able to
do this.
------------------------------
From: kevin@lhc.nlm.nih.gov (Kevin Rosenberg)
Subject: Does XFree support ET4000 (Hercules Dynamite) video cards
Date: Tue, 15 Mar 94 21:28:25 GMT
Thanks!!
======================================================================
Kevin Rosenberg A thought for the day?
kevin@lhc.nlm.nih.gov
------------------------------
From: armb@setanta.demon.co.uk (Alan Braggins)
Subject: Re: Amiga File System, once again
Date: Mon, 14 Mar 1994 10:07:37 GMT
In article <2lvql8$b2j@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes:
> You could presumably put an AmigaDOS filesystem on a physically
> PC-formatted (720K) floppy, and then read the floppy on the Amiga.
Are you saying both the Linux and AmigaDOS versions of the Amiga file
system will already work on PC-formatted floppies, or that, given that
both systems support alternative filesystems, they could be written?
--
Alan Braggins armb@setanta.demon.co.uk abraggins@cix.compulink.co.uk
"Any technology distinguishable from magic is insufficiently advanced"
------------------------------
From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: select
Date: Tue, 15 Mar 1994 02:26:34 GMT
In article <MhV_Lq600gjON0lH0U@andrew.cmu.edu> Robert Andrew Ryan <rr2b+@andrew.cmu.edu> writes:
>What standard specifies select should write to the timeval? SunOS 4.1
>is the only system I've seen where it's even mentioned as a possible
>future enhancement. I certainly agree it's a useful enhancement, but it
>is incompatible with a great number of previous implementations. This
>is a serious source of bugs for the unwary porting interactive network
>programs.
The FreeBSD man pages also talk about this, so I suspect that the
NetBSD to do as well.
However, the following platforms do not write to timeval:
DEC Ultrix
SGI IRIX
Sun SunOS 4.x and 5.x
FreeBSD current (1.0 and later)
NetBSD 0.9 ish
386BSD
DG something
BSD 4.4
HP HPUX (8.x and 9.x)
IBM AIX (3.2*)
All x86 SVR4 clones I've tried
VAX/VMS (WIN/TCP, TGV, UCX)
And here is a list of all system that do write the timeval:
Linux
Warner
--
Warner Losh imp@boulder.parcplace.COM ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
more serious personality disorders"
------------------------------
From: psmith@iies.ecn.purdue.edu (Paul Smith)
Subject: Linux 1.0 old problem, new problem...
Date: Tue, 15 Mar 1994 23:21:20 GMT
I posted previously about a problem in Linux pl14 and pl15 with
gopher/www servers hanging when serving DOS or Windows clients. One
e-mail reply I received claimed that this was a known bug, but should
be fixed in the 1.0 kernel. Well, as far as I can tell, it isn't.
I'm using Slackware 1.1.2, but I downloaded the 1.0 kernel from funet.fi
and installed it over the pl15h that is currently in Slackware. I am
also using the 2.01 version of gn as my gopher server, which compiles
after I fix a couple of things (what is a SIGSYS in Linux?). When I hit
on the server using a DOS or Windows client (NetManage or PCG from UMN)
the data gets transferred (according to gn debug log, and the dialog
box on the client), but the transfer hangs at the end. The client
seems to be waiting for the server to close or something, and the
server thinks everything is fine and has already closed. These same
clients can hit on any other gopher server on the internet without
a single problem, so I know it isn't a problem with the client.
Please, I am positive this is a bug in the kernel somewhere (tcp layer?).
I've tried four versions of gopherd, two or three versions of gn,
and many different DOS and Windows clients with different packet
drivers and Winsock stacks... they all have the same problem, and
the only thing in common is Linux. I've also tried two different
ethernet cards, 3c501 and 3c509, and both had the same trouble.
Also, I'm using getty_ps 2.07c (included in Slackware 1.1.2)... it
seems to not be working quite right with the new kernel. It thinks
that it succesfully initialized the modem, when it actually didn't.
(I can tell by looking at the lights). If I enter/exit kermit to
force it to re-init then it works ok. This was never a problem
before I installed kernel 1.0... my modem strings and other setups
worked just fine.
Could someone please look into these? Thanks!
-Paul
------------------------------
Crossposted-To: comp.protocols.tcp-ip
From: longyear@netcom.com (Alfred Longyear)
Subject: Re: 127.x.x.x (was Re: UDP report card)
Date: Tue, 15 Mar 1994 15:54:49 GMT
It seems to me that the address 127.x.x.x is not special. What is special
is the loopback device.
When the "lo" device is brought up, it will register itself as IP address
127.0.0.1. You must still create the route to the loopback device as you would
for any other device in your configuration.
If you don't have a route for 127.x.x.x to the "lo" device, but have a default
route to an ethernet controller, for example, then requests to 127.0.0.1 will
go out the wire just as requests to any other IP address. Until a route is
created to the loopback device, the address 127.x.x.x is an unknown address
just as if _I_ asked for address 192.83.17.1. It would need ARP to resolve it
to a real ethernet address and subsequently the request would go out the
default route.
So, it is not the "implementation of TCP/IP" which is broken, but the
operator's setup of the TCP/IP configuration which is broken. There is nothing
"magical" about the address 127.0.0.1 other than the convention that it is the
loopback device and is normally _configured_to_route_ back to your own machine.
I guess what I am saying is that the routing of frames is not a function
solely of the device's IP address, nor is it a function soley of the device
type. There is no magical "override" which says that "Oh, you have address
127.0.0.1. I won't bother to look it up. I know that this is the loopback
device and will simply put it there". It is a function of the routing tables
within the system. If the routing tables do not include a route for the 127
address, then it will use the default route or fail if there is no default
route. If it must use the default route to some eithernet controller then it
will need an ethernet address. This means that it will ask for the ARP
translation of 127.0.0.1.
------------------------------
From: genie@sting.Berkeley.EDU (Gene Choi)
Crossposted-To: comp.os.linux.help
Subject: Linux 1.0 problems (No free VT)
Date: 15 Mar 1994 03:30:10 GMT
So after I heard about the announcement of Linux 1.0, I grabbed
the source and recompiled. To my dismay, I am no longer able to
run Xfree any more. Using pl15 and pl15c(or something near c),
I had 0 problems with X. I changed 0 things in my setup from
my move from pl15 to 1.0. Anyway I tried forcing X to start
via startx and xdm (as root of course). 0 luck so far.
Under startx, Xfree complains about having no free VT.
Has something changed with setting VT's?
I am using the Xfree Mach32 drivers.
-Gene
------------------------------
From: na2@doc.ic.ac.uk (Nicholas Ambrose)
Subject: Re: Lint for Linux?
Date: 15 Mar 1994 17:40:32 -0000
In article <JAFFER.94Mar11105535@camelot.ai.mit.edu>, jaffer@zurich.ai.mit.edu (Aubrey Jaffer) writes:
|> In article <STEVEV.94Mar6135102@miser.uoregon.edu> stevev@miser.uoregon.edu (Steve VanDevender) writes:
|>
|> In article <1994Mar1.115924.20298@uts.uni-c.dk>
|> elmnjb@unidhp.uni-c.dk (Niels J. Bagger) writes:
|>
|> As the title says: Does lint(1) exist for Linux?
|>
|> gcc -Wall is pretty close to lint for telling you about dumb C
|> coding practices.
|>
|> Not close enough! If you code with K&R style function prototypes (as
|> opposed to ANSI) then gcc -Wall tells you nothing about argument
|> mismatch and number of arguments mismatch between modules.
|>
|> I have to code for a variety of machines not all of which support ANSI
|> prototypes. Lint is essential for finding argument mismatch. I wish
|> I could find a lint for linux so I wouldn't have to ship my code
|> elsewhere just to use lint.
I Huess you could Always Stuff The Code Through porotoize forst, then use
gcc -Wall, then unprotoize ....
Nick
--
Air is water with holes in it
------------------------------
** 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
******************************