Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest143
2024-02-19 00:24:15 -05:00

575 lines
21 KiB
Plaintext

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: 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 <CvuwH2.1yB@info.swan.ac.uk>, 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-080994141221@silicon.jpl.nasa.gov> 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 <CvL0JI.G2F@dorsai.org>, 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: <No>
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: <No>
--
=========================================================================
| 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 <tal@plts.org> 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 <Cvuvsq.1qE@info.swan.ac.uk>,
Alan Cox <iialan@iifeak.swan.ac.uk> 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
******************************