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
******************************
