Subject: Linux-Development Digest #556 From: Digestifier 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 writes: DJB> In article , DJB> Alan Drew 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@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 Robert Andrew Ryan 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@zurich.ai.mit.edu (Aubrey Jaffer) writes: |> In article 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 ******************************