From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 9 Sep 94 10:13:10 EDT Subject: Linux-Development Digest #143 Linux-Development Digest #143, Volume #2 Fri, 9 Sep 94 10:13:10 EDT Contents: Re: Linux for Mac (Hamish Macdonald) Re: Americans vs. Europeans (was Re: Unicode...) (Alan Cox) Re: Has ARP been fixed ? (Alan Cox) Re: Alpha Linux (Alan Cox) Re: ATI Mach64... Does it work...? (Marc A. Runkel) Re: Alpha Linux (Anton Ertl) Re: There's a hole in my copy! (Kai Petzke) Adaptec 2940 PCI (Gus P Ikonomopoulos) Re: Looking for Donald Becker (Rob Janssen) Re: Wheres blkdev.h?? (compiling 1.1.49) (Rob Janssen) Re: compiling 1.1.46+ ... I went to .50 :) (Rob Janssen) Re: Network driver section for the Hacker's Guide (Rob Janssen) Re: Developing Distributed Filesystems for Linux? (Alan Cox) Network driver section for the Hacker's Guide (Erann Gat) Re: Multiprocessing Pentium Systems (Richard Lamont) Re: News Spool File System - new filesystem type?? (Bill Davidsen) Re: News Spool File System - new filesystem type?? (Bill Davidsen) ---------------------------------------------------------------------------- From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Subject: Re: Linux for Mac Date: 8 Sep 1994 18:55:53 GMT >>>>> On 07 Sep 1994 20:14:41 EST, >>>>> In message <34loi1$n62@news.it.gvsu.edu>, >>>>> shefferm@river.it.gvsu.edu (Mike Sheffer) wrote: Mike> Is anyone out there working on 68K Mac binaries? What do you mean by this? A kernel? Binaries that could run on a Linux port to the Mac? If the latter, any binaries that currently run on Linux/68k for the Amiga or Atari should be able to run as-is on a port to the 68k Mac (once such a port exists). ------------------------------ From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: Americans vs. Europeans (was Re: Unicode...) Date: Fri, 9 Sep 1994 09:40:43 GMT In article <1994Sep6.155719.25125@midway.uchicago.edu> goer@midway.uchicago.edu writes: >>X windows does. Its fair to say its not exactly used a lot but X can do it. >Thanks for a thoughtful posting. This one part I'm not sure is right. >X doesn't know anything about text. It's the anciliary libraries that Xlib knows about the rendering of text, and the rendering is done by the X server rather than the client - common sense dictates its faster that way. The price is the fact that the X server needs the fonts rather than the application. >take care of that. So the question is what widget sets support non- >western languages and alternate wordwraps (as well as bidirectional word- >wrap, which for left-right/right-left languages has established typo- >graphical conventions). Do you really know of any that do this well? No. My experience is limited to Athena, Xview and a little Motif however. >The same remarks applied to US programmers re Europeans, BTW, may be >applied to Europeans vis-a-vis the rest of the world (i.e. the majority >of the world - which speaks languages like Urdu, Chinese, Arabic, etc.). >No fair pointing fingers at Americans, while comitting the same sins >as us :-). Actually I have a script that spells things like colour correctly I run over a lot of programs before I compile them under Linux 8). Now I've been playing a bit more with the internationalisation tools from LI and added myself a new one to back substitute locale catalogue usage into a program I hope to have the net-tools-1.1.50 release internationalised so people can do foreign languages anyway (I know most people already think ifconfig speaks a foreign language). Alan -- ..-----------,,----------------------------,,----------------------------,, // Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU // ``----------'`----------------------------'`----------------------------'' ------------------------------ From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: Has ARP been fixed ? Date: Fri, 9 Sep 1994 09:43:31 GMT In article <1994Sep6.184123.52@elmrd6.ineab.ikea.se> anos@elmrd6.ineab.ikea.se (Anders Ostling) writes: >It seems like the ARP module is broken. It lists all my entries with >completely invalid IP addresses, but correct MAC address. Is somebody >working on this ? Is it solved ? When did it break ? It's not broken. The /proc/net/arp file format got changed to match the other /proc/net files so you need newer tools - changed about 1.1.12 I think. Alan -- ..-----------,,----------------------------,,----------------------------,, // Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU // ``----------'`----------------------------'`----------------------------'' ------------------------------ From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: Alpha Linux Date: Fri, 9 Sep 1994 09:46:13 GMT In article <1994Sep6.180654.21915@mcshub.dcss.mcmaster.ca> ukrainec@soma.crl.mcmaster.ca (Andrew Ukrainec) writes: >Another observation: at least according to the K&R C specification, short >int, int, and long int are not defined to be any specific bit length, and >can all be equal to same bit length, as a matter of fact. The programmer >who writes expecting short int = 16 bits should know that the code will not >necessarily be portable. > >Therefore, there shouldn't be a problem defining > >short int = 32 bits >int = 64 bits >long int = 64 bits Indeed not. Do we get 128 bit long longs in gcc however ?. The other thing people for get is char != 8 bits always. The Honeywell L66 had char=9bits(*) (or 7 depending upon compiler setting), short=36bit, int=36bit, long=36bit). Made for some porting fun. (*) 4 or 5 chars per machine word. Alan -- ..-----------,,----------------------------,,----------------------------,, // Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU // ``----------'`----------------------------'`----------------------------'' ------------------------------ From: mrunkel@twain.ucs.umass.edu (Marc A. Runkel) Crossposted-To: comp.os.linux.help,comp.windows.x.i386unix Subject: Re: ATI Mach64... Does it work...? Date: 8 Sep 1994 16:49:12 GMT Pete Walker (pwalker@pinocchio.encore.com) wrote: : Hi Xfreers, : Notice that Mach64 is listed under 'others' group in Hardware-HOWTO and : just wanted to know if anyone has the Mach64 card working under : Xfree and if so what was the proceedure used to get it going. : I am purchasing one of these cards (VLB) and wants to know if it is a : good decision or safe ivest investment. Thanks for your replys. There is an unaccelerated X Server for the Mach 64 available on sunsite.unc.edu for linux systems. If you can compile your own X Server, there is a replacement driver.c file for it in the same tar package. -- Marc A. Runkel marc.runkel@registrar.umass.edu Network Analyst Of course, this is just my Registrar's Office * Systems Support Group tiny, insignificant, humble University of Massachusetts, Amherst opinion. If you don't like it.... ------------------------------ From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: Alpha Linux Date: 9 Sep 1994 11:29:30 GMT In article , iialan@iifeak.swan.ac.uk (Alan Cox) writes: |> Do we get 128 bit long longs in gcc however ? gcc defines long long to be twice as long as long. So if long is 64 bits, we should have 128-bit long longs. On the MIPS there are options (not working yet according to the gcc-2.4.x manual) `-mint64', `-mlong64' and `-mlonglong128'. Of course, the Alpha OSF/1 people did not use up all idiocy in defining ints, so they defined both long and long long as having 64 bits. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: There's a hole in my copy! Date: 8 Sep 94 21:53:12 GMT mark@garden.equinox.gen.nz (Mark Tomlinson) writes: >Yesterday, while trying to work out how to create a file with holes in it >(to save disk space), I found that merely copying the file did the job >without me having to do anything special. I thought this was a great >feature, but when I looked at the source code to cp, I found that this was >not was intended. (from fileutils-3.9). >The relevant piece of code looks like this: > /* If the file has fewer blocks than would normally > be needed for a file of its size, then > at least one of the blocks in the file is a hole. */ > if (S_ISREG (sb.st_mode) && > sb.st_size - (sb.st_blocks * DEV_BSIZE) >= DEV_BSIZE) > make_holes = 1; >Since sb.st_blocks is unsigned, the comparison is unsigned also. For any >file which does not have holes, and the last block is not completely full >(that's most files), then the LHS evaluates to a negative number, and >make_holes is set true. Even using signed numbers, I don't see why the >comparison is against DEV_BSIZE. Surely it should simply be: > if ( .. && sb.st_size > (sb.st_blocks * DEV_BSIZE)) Oh, well. I have found the same thing in GNU tar a few weeks ago. It will be fixed in the next major release. Fortunately, that bug does not matter. It will set make_holes to 1 on most files, so it will check every sector, whether it contains only zeros or not. It is a slowdown, but it also has a few advantages: - It will work on the MINIX filesystem, which does not fill in st_blocks correctly. While the MINIX filesystem is no good choice for the main Linux filesystem, it is a good idea to use it on floppies, because of its small overhead. - It will work correctly on those files, that have only a few holes, but also have indirect blocks. Most "pure" linux executables are like this, they have a hole at the end of the program and at the end of the data section. So I vote for removing the stupid and wrong test, and set make_holes always to 1 in the cp command. Maybe there should be an option to tell cp not to try to create holes. -- Kai Petzke | How fast can computers get? Technical University of Berlin | Berlin, Germany | Sol 9, of course, on Star Trek. wpp@marie.physik.tu-berlin.de | ------------------------------ From: gpi41676@uxa.cso.uiuc.edu (Gus P Ikonomopoulos) Subject: Adaptec 2940 PCI Date: 8 Sep 1994 05:33:04 GMT I have just purchased an Adaptec 2940 PCI controller. I need to run Linux soon. I am willing to help write a driver for this card. I don't under- stand much about PCI though. If someone is currently writing a driver or wants to, I'm eager to help. ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Looking for Donald Becker Reply-To: pe1chl@rabo.nl Date: Fri, 9 Sep 1994 08:05:08 GMT In gat@robotics.jpl.nasa.gov (Erann Gat) writes: >Does anyone know what happened to Donald Becker? He is the author of >many of the Linux network device drivers. He is apparently no longer >at super.org. He is now at NASA :-) Check the CREDITS file in the Linux source tree for people's addresses... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ Crossposted-To: comp.os.linux.help From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Wheres blkdev.h?? (compiling 1.1.49) Reply-To: pe1chl@rabo.nl Date: Fri, 9 Sep 1994 08:07:27 GMT In <34o25j$83f@vespucci.iquest.com> dougal@vespucci.iquest.com (Dougal Campbell) writes: >In article , Carlos Dominguez said something like: >> I'm trying to compile the latest/greatest kernel in order to >> get support for my 1mb/sec QIC80/floppy controller. >> I got the 1.1.45 kernel, applied all the patches sequentially from >> 46 to 49 to my 45 source tree, and whenever I do a make dep I always >> get this. >> ksyms.c:13: linux/blkdev.h: No such file or directory >> make[1] *** [dep] Error 1 >> I did a diff between a ksyms.c and a ksyms.c.orig and the diffs were >> that statement and a "BLOCK DEVICE" section towards the end. >> Can/Should I compile even with this dependency error? >I ran across the same thing when I compiled the 1.1.49 kernel. The >patches seem to not place some of the files correctly. If you look in >directory you applied the patches from (probably /usr/src or >/usr/src/linux) I'd bet that you'll see some stray .h and .c files. >Look at what source files the make fails on, look at the paths, and move >the stray files to their proper directories. It means you did the patching incorrectly. Check the README file in the /usr/src/linux directory to see how to do the patching. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ Crossposted-To: comp.os.linux.help From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: compiling 1.1.46+ ... I went to .50 :) Reply-To: pe1chl@rabo.nl Date: Fri, 9 Sep 1994 08:11:33 GMT In <1994Sep8.234321.197@acad.ursinus.edu> stevo@acad.ursinus.edu (Steve Kneizys) writes: >Just did this, except I went to 1.1.50 release. I started with the 1.1.45 >tar file, and did the patches 46 through 50 sequentially from the /usr/src >directory. Then I moved the .c and .h files (I think they were just >blkdev.h, ncp.h, ni52.h and ni52.c) created in /usr/src to the subdirectory >linux/include/linux, then moved entry.S to /usr/src/linux/kernel directory. >Did the standard makes and it booted on the first try! Did it by modem >too...brave soul I am :) When you use the patch command as it is written in the README file, you won't have this problem at all. Probably the file should be renamed: DONT_READ_THIS_IT_CONTAINS_NO_USEFUL_INFORMATION Then people would peek in it? Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Network driver section for the Hacker's Guide Reply-To: pe1chl@rabo.nl Date: Fri, 9 Sep 1994 08:14:14 GMT In <34nq27$j2o@news.doit.wisc.edu> unal@uwnuc1.physics.wisc.edu (Orhan Unal) writes: >Here is an excrept from the "CREDITS" file. >N: Donald Becker >E: becker@super.org >D: General low-level networking hacker >D: Most of the ethercard drivers >D: Original author of the NFS server >S: 17100 Science Drive >S: Bowie, Maryland 20715 >S: USA >N: Alan Cox >E: iiitac@pyr.swan.ac.uk >E: gw4pts@gw4pts.ampr.org >E: GW4PTS@GB7SWN (packet radio) >D: NET2Debugged author >D: Network layer debugging >D: AX.25 & IPX alpha releases >S: But that is an ancient version!! Now, it reads: N: Donald Becker E: becker@cesdis.gsfc.nasa.gov D: General low-level networking hacker D: Most of the ethercard drivers D: Original author of the NFS server S: 17100 Science Drive S: Bowie, Maryland 20715 S: USA N: Alan Cox E: A.Cox@swansea.ac.uk E: iiitac@pyr.swan.ac.uk E: gw4pts@gw4pts.ampr.org E: GW4PTS@GB7SWN (packet radio) D: NET2Debugged author D: Network layer debugging D: AX.25 & IPX alpha releases S: -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ Crossposted-To: alt.filesystems.afs From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: Re: Developing Distributed Filesystems for Linux? Date: Fri, 9 Sep 1994 10:52:33 GMT In article <34ou3c$n41@agate.berkeley.edu> lim@soda.CSUA.Berkeley.EDU (Lincoln Myers) writes: >If not, would it be possible to make a freely available implementation of >AFS or DFS for Linux, without infringing on their current owner's >(Transarc's) rights? Is there enough information out there? You can try chasing Transarc. Now they are owned by IBM they might be more friendly ;) Alan -- ..-----------,,----------------------------,,----------------------------,, // Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU // ``----------'`----------------------------'`----------------------------'' ------------------------------ From: gat@robotics.jpl.nasa.gov (Erann Gat) Subject: Network driver section for the Hacker's Guide Date: Thu, 08 Sep 1994 11:17:18 -0800 I am in the process of writing a new network driver, and I thought it might be worthwhile to turn the experience into a currently misssing section of the Linux Kernel Hacker's Guide on network drivers. However, if I am going to do that I would like to hook up with an experienced Linux developer to help me make sure that I am doing the Right Things. Is there anyone out there, preferably with some net driver experience, willing to help me out with this project? Many thanks, E. -- Erann Gat gat@robotics.jpl.nasa.gov ------------------------------ From: richard@stonix.demon.co.uk (Richard Lamont) Subject: Re: Multiprocessing Pentium Systems Date: Thu, 8 Sep 1994 17:03:23 +0000 >I've just seen some new dual processor pentium systems in Computer >Shopper. They look swell for the money, but there isn't a single OS >that can take advantage of them. Not quite true. SCO Unix can run on parallel Pentiums (Pentia?) using an add-on called MPX. This costs extra money, but I'm told it works well. Apparently compilations run about five times as fast with two Pentiums compared to one. I have no idea why this should be the case. Of course, with Linux, my trusty 486 is plenty fast enough on its own. :-) Richard Lamont. /ex ------------------------------ From: davidsen@elephant.dev.prodigy.com (Bill Davidsen) Crossposted-To: news.software.b Subject: Re: News Spool File System - new filesystem type?? Date: 9 Sep 1994 13:41:13 GMT In article <34opps$4gq@plts.org>, Tom Limoncelli wrote: >In <34n311$9br@usenety1.news.prodigy.com> davidsen@elephant.dev.prodigy.com (Bill Davidsen) writes: > >>I have thought of writing a complete news system using this method, which >>would restrict reading to NNTP, since the file structure would be all >>diferent. Not a loss, I think. I'm still looking for a fast algorithm to >>find N consecutive bits ON in a bitmap... > >Why? > >NNRP and INN have all the hooks to support all of this already. Why >re-invent the wheel when you only have to change the "read article" >and "write article" routines of INN or C News? I don't understand your question, so I'll answer all the meanings I can image ;-) a) why find N bits? to play with first fit best fit allocation, something I haven't done since about 1970. b) why write a complete news system? Because doing a general compressed filesystem type is not my interest, and doing the article part and waiting for someone to put in in a news system would be a waste of time and would make debugging really ugly. c) why restrict reading to NNTP? Because the filesystem type is going to change and I don't want to rewrite readers which go directly to /usr/spool/news. Hope I guessed what you were questioning. I didn't know INN had the ability to use compressed filesystems, I don't see the compressor code, or is that a feature in 1.5? Or do you mean it could be hacked into INN by rewriting some stuff? That's true of any news system if you have the source. -- Bill Davidsen, davidsen@tmr.com on weekends. "Speaking *from* but not *for* Prodigy" ------------------------------ From: davidsen@elephant.dev.prodigy.com (Bill Davidsen) Crossposted-To: news.software.b Subject: Re: News Spool File System - new filesystem type?? Date: 9 Sep 1994 13:46:56 GMT In article , Alan Cox wrote: >I've seen people run micro based news readers that pulled each article from >a tar file as needed (along with an index file so the tar reader could >just seek and grab the article). It is a good idea. For a micro, perhaps. For a server with lots of readers it would be somewhat CPU intensive to say the least. With one CPU/reader it's fine, but I can just see 1200 readers on a server... -- Bill Davidsen, davidsen@tmr.com on weekends. "Speaking *from* but not *for* Prodigy" ------------------------------ ** 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 ******************************