Subject: Linux-Development Digest #223
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 25 Sep 94 03:13:22 EDT

Linux-Development Digest #223, Volume #2         Sun, 25 Sep 94 03:13:22 EDT

Contents:
  Re: How to use a host as a router - READ THIS (Jay Ashworth)
  Re: 1+ Gig SCSI Drives (Bill Davidsen)
  Re: RFD: new moderated newsgroups (Jeff Kesselman)
  Linux 1.1.18, Tcl 7.3: Floating Exception in Expr Test, etc. (Daniel Simmons)
  Re: Linux on Pentium P90 PCI---which motherboard? (David S. Vickers)
  Re: Ou trouver Linux ([email-masked])
  Re: Sequential IO only thing lacking in Linux ... (Mark Lord)
  Re: Linux on Pentium P90 PCI---which motherboard? (Eric J. Bohm)
  Re: 900 MHz CB band??? ([email-masked])
  Re: Future of linux -- the sequel (Shannon Hendrix)
  Re: NCR 53C406A SCSI (Drew Eckhardt)
  RealTek RTG3106 XFree? (Steffen Sledz)
  Re: Windows DLL-type linking possible...? (Hugh Emberson)
  Re: pseudo ftp mirrors (Pete Kruckenberg)
  Re: Linux for DEC 5000s ??? (Andreas Busse)
  Re: 680x0: Ext2 incompatibility with i386 (Ralf Baechle)
  Re: 680x0: lib incompatibility (4.5.21/26) (Ralf Baechle)
  Re: 680x0: separate newsgroup? (Ralf Baechle)

----------------------------------------------------------------------------

From: [email-masked] (Jay Ashworth)
Crossposted-To: comp.os.linux.misc,comp.os.linux.admin
Subject: Re: How to use a host as a router - READ THIS
Date: 22 Sep 1994 21:28:49 -0400

[email-masked] (Ian McCloghrie) writes:
>This is common practice (and, in fact, required by many TCP/IP protocl
>stacks).  Whether or not it is "correct" is unclear.  It's quite
>possible to implement routing using the same IP address on two
>interfaces, if one of them is a point-to-point link (namely,
>a slip line).  The idea of every physical network having its own
>IP network is ideologically pure.  Ideological purity, while clean
>and elegant, is often discarded in favour of optimizations.  Given
>the current state of the IP address space, it could easily be argued
>that wasting an entire network on a 2-host point-to-point slip line
>is incorrect behaviour :)

True.  But you'll note I didn't say anything about where those 2 addresses
need to reside.  Common sense would seem to suggest putting your
"router's" PPP port on your host's net, and it's ether on your own, and in
fact, this works.  At worst, external incoming connections will get aimed
at your ether IP number, but you don'e lost a _whole_ there...

Cheers,
-- jra
-- 
Jay R. Ashworth                                                       Ashworth
Designer              High Technology Systems Consulting          & Associates
ka1fjx/4                                                
[email-masked]      Linux: The Choice of a GNU Generation     +1 813 790 7592

------------------------------

From: [email-masked] (Bill Davidsen)
Subject: Re: 1+ Gig SCSI Drives
Date: 21 Sep 1994 17:48:44 -0400

In article <[email-masked]>, Marc Singer <[email-masked]> wrote:

:Second, I suspect that there are some other kernel dependencies
:relating to >1G drives.  Unfortunately, this is merely speculation.
:It comes from troubles I have had with 1.2G and 1.7G drives as ext2
:devices.

I've had problems putting the boot partition above 1G because the BIOS
can't load the kernel, but this is true with any drive, not just SCSI. I
saw it with some old 600MB ESDI drives which were being scrapped and
wound up being sold for about $99 each. As long as the root partiton was
first and extirely below cyl 1024 I don't recall any problems.

:I once read a rumor about a new filesystem standard.  I believe that
:ALL unices are limited to 2G partition sizes due to the 32 bit file
:pointer accepted by the standard OS entry points.  Perhaps there is a
:movement afoot to go to 64 bit pointers as did Microsoft with Windows
:NT.

Don't confuse the filesize limit with the filesystem size limit. There
are real problems handling an individual file > 2GB (at least on a 32
bit machine), but having a filesystem up to 4*10^9 sectors is a much
easier problem. Most systems haven't given up on the idea that the
limits should be the same, but that's muddy thinking.

Note that the easiest jump is to 4GB (32 bits) since disk location is
(or can be) an unsigned number inside the kernel, while the UNIX system
calls use a signed number and you only get 31 bits for the actual
offset.

After that you can work in sectors, or allocation units. The first looks
a lot easier than the second in terms of not having to do a lot of
arithmetic in software.

This is important, 2GB won't hold a week's news, but 4GB will, probably
until the end of '95 ;-(
-- 
Speaking *from* but never *for* Prodigy
        "Pain builds moral fiber"  -my dad
        "Pain hurts"  -me

------------------------------

From: [email-masked] (Jeff Kesselman)
Subject: Re: RFD: new moderated newsgroups
Date: Sat, 24 Sep 1994 18:36:53 GMT

In article <[email-masked]>,
Edmund Humenberger <[email-masked]> wrote:
>To build a place where you can get information I suggest
>a new group: comp.os.linux.development.moderated
>
>or something like this.
>
>There should be only a limited group of members be allowed
>to pst to this group. These members can vote for any
>other person to be allowed to post also.
>If there is a majority of 30%, the new person can
>become member to.
>How can somebody become member?
>to write good articles in Comp.os.linux.development!!!
>
>then the others will sea and vote for himher.
>
>If there are more votes than 30% of the members to quit
>the right of somebody to post, the right will be canceled.
>
>this can be done automaticly: are there some volunteers out
>to do  it?
>
>Even if I am not alowed to post. I like to read information.
>
>thanks ed

I have a BIG  problem with a USENET private club (which this basicly is.)  
Most moderated groups allow EVERYOEN to post, and a moderator or 
moderators sift through it to find what useful and what is fluff.

This way it doesn't devolve into cliches.

My feeling is if you want a priavte postr place, run it on your own 
machine and make it net-accessble to those you 'deem worthy'.

Jeff Kesselman

P.S.  AS I understand it, this is really the wrong palce for this
discussion.  If it is to continue it should be mvoed to one of the 
appropriate net organziational topics...

------------------------------

From: [email-masked] (Daniel Simmons)
Crossposted-To: comp.lang.tcl
Subject: Linux 1.1.18, Tcl 7.3: Floating Exception in Expr Test, etc.
Date: 24 Sep 1994 02:16:57 -0600

Howdy folks!

I'm looking for some help with an *ugly* bug or two.  I've recently been
working to port a fairly large application that was developed under HP-UX
and uses Tcl7.3 so that it would work with Dist-3.0 and metaconfig to
compile all over the place (metaconfig is the system Perl and Trn use
to configure themselves).  As I said my application was developed under
HP-UX, but my porting work has been on a Linux system at home.

I'm running Slackware-2.0 with the 1.1.18 kernel (but I've tried the 1.0.9
and 1.1.50 kernels with the same results).  My application has two Tcl
interpreters, which it creates fine, but the first Tcl code which I
attempt to evaluate contains a variable dereference.  This line causes
the program to Seg-fault __INSIDE_TCL__  the seg fault is in Tcl_ParseVar
and at the point where the Tcl parser is just beginning to parse the part
of the string which follows the variable reference.  To make matters worse,
I get the seg fault when I run from the commandline or when I run from
the debugger, but it does *not* occur if I run from the debugger and single
step through the program.  Oh, it also occurs exactly the same whether
I compile with or without optimization.

All of this happened using Tcl binaries and share libraries supplied with
Slackware 2.0.  Being a little suspicious, I downloaded the latest Tcl7.3
modified for Linux shared libs from sunsite but to no avail (either using
the supplied shared libs or compiling myself from the Linux-modified 
sources).

Now here's where it really gets weird:  I downloaded a stock copy of Tcl7.3
from sprite and compiled it.  The compile went fine, but it fails the
expr test with a floating point exception.  This same test is passed with
flying colors by the linux-modified version of tcl, but comes up every
time with the stock tcl.  The mystery is further depened by the fact that
stock tcl and the linux modified tcl do not differ in any source file--only
in the Makefiles.

Oh, and of course, the stock Tcl still exhibits the seg fault problem
I mentioned above.

ARRRGGGGG.  What could I be doing wrong?

Danny

-- 
Daniel Simmons          electronic mail : [email-masked]
Idaho State University       voice mail : (208) 236-3199
Computer Center              snail mail : Box 8037, Pocatello

------------------------------

From: [email-masked] (David S. Vickers)
Crossposted-To: comp.os.linux.misc
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
Date: 25 Sep 1994 01:44:15 GMT

[email-masked] (Vaughan R. Pratt) writes:
>If Linux runs on your Pentium P90 PCI, or you know of a working such,
>I'd appreciate knowing what motherboard did the trick.
>-- 
>Vaughan Pratt                  http://boole.stanford.edu/boole.html

I recently built a system for someone with an Intel Plato P54C
motherboard which used the Neptune chipset.  I used an NCR SCSI
controler with a patched kernel (version 1.1.19).  The first
motherboard I got had a flakey cache, and upgrading the BIOS didn't
help.  I replaced the motherboard, and everything has worked
flawlessly since.  

-David Vickers

------------------------------

From: [email-masked]
Subject: Re: Ou trouver Linux
Date: 25 Sep 1994 02:22:03 GMT

Re: Ou trouver Linux

Je crois savoir que tu parle bien francais! Bon alors.

Tu peut trouver linux a differents endroit par FTP.
  tsx-11.mit.edu:/pub/Linux
  sunsite.unc.edu:/pub/linux

Ce sont deux des endroits ou tu peut trouver des kit de distribution de Linux.
 Il y en a beaucoup d'autre comme ftp.cdrom.com, ...

Je crois en avoir vu en France, mais je ne me souvient plus de l'address.

Le dernier kernel (non-officiel) est le 1.1.51,
La derniere version depend de ou tu la prend ie(Slackware 1.22, Debian ??, Ygg ??).

Pour savoir laquelle est la meilleur, faut voir, chacun a ces idees.
Pour ma part j'ai les CD de Walnut Creek, Trans-Ameritech, et Micro Application (Grand Livre UNIX). tous ont des choses differ
ntes. Mon frere, au Canada, vient de commander la derniere version de Walnut Creek, elle vient avec X11R6, et le kernel 1.1.24
?). Il va faire þl'installation cette semaine, ont verra.

Si tu a d'autres question, n'hesite pas. J'en aurai certainement a mon tour!

Bonne chance,
Andre Couture
[email-masked]

------------------------------

From: [email-masked] (Mark Lord)
Subject: Re: Sequential IO only thing lacking in Linux ...
Date: 21 Sep 1994 23:24:51 GMT

In article <[email-masked]> [email-masked] writes:
>
>Hi -- I am posting the contents of e-mail sent to me regarding the recent BYTE
>article evaluating a Fintronics Linux system.  Apparently the only thing
>lacking in Linux as opposed to other X86 PC *nices is the sequential IO
>ability.  The relevant paragraphs are marked with arrows on the right side.

Commercial unix systems usually include optimized support for a limited
number of disk devices, and make use of knowledge of the physical 
characteristics in optimizing system throughput.  

For example, i/o requests can be reordered on the fly based
on the known current rotational position of the spindle,
rather than just waiting for it to come around again..

Knowledge of the true physical geometry of the disk lends itself
to further optimizations, such as organizing data by cylinder
rather than by arbitrary sequential block numbers (close, but not
the same results).  To do a good job of this requires further knowledge
of the sector count/location on each track of the disk.. a complex
task when variable sectors/track are used.

Varying the locations of sector/block 0 on each track can yield impressive
throughput figures, by taking into account the head movement/settling times
from one track/cylinder to the next, such that the next sequential block
is just appearing under the heads as the seek completes..

Lots of nice tricks, most of which require greater internal knowledge of
a restricted subset of available drives.. 

Linux, (un?)fortunately, likes to provide more generic drive support.
-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

------------------------------

Crossposted-To: comp.os.linux.misc
From: [email-masked] (Eric J. Bohm)
Subject: Re: Linux on Pentium P90 PCI---which motherboard?
Date: Sat, 24 Sep 1994 09:13:06 GMT

In article <[email-masked]>,
Vaughan R. Pratt <[email-masked]> wrote:
>If Linux runs on your Pentium P90 PCI, or you know of a working such,
>I'd appreciate knowing what motherboard did the trick.
>-- 
>Vaughan Pratt                  http://boole.stanford.edu/boole.html

Zenon Z-Optimus II 
============================================================================
P90 PCI ISA W/256K Cache
SQ545 Motherboard: 2 ISA/VESA, 2 ISA closts, one XT/PCI shared slot
        and two PCI slots, AT I/O (2S,1P) Built-in 16550
        72 Pin parity or non-parity memory 128 MB max

Using kernel 1.1.50 with patches for the NCR53c810 and Mach64 stuff.  Works
great.  No tricks necessary.

------------------------------

From: [email-masked]
Subject: Re: 900 MHz CB band???
Date: Fri, 23 Sep 94 03:38:14 PDT

<[email-masked]> writes:
>
> Alexandra Griffin ([email-masked]) wrote:
> : I was unaware of the existence of a CB band @ 900MHz.  How much
> : bandwidth is available there?  What restrictions exist w.r.t.
>
> To bring it to topic - there is ALPHA version of Linux driver for
> the WaveLan card, designed by NCR, that gives you about 2.5 Kbit/sec
> link as far as you can beam 1Watt at around 910 MHz. This band is
>
The RatShack FM walkie talkies are 900mhz, as is the new spread spectrum 
hand-held fone from Uniden... there are also some paging freqs up in that 
area... but like the WaveLan.... nothing real powerful or long range..

Oops... cancel that.... One of my suppliers sez: 2.5mbps spread-spec point to 
point links are available with 5-10 mile range and built-in ethernet routers 
for about $5k... I dunno the freq range... but it uses a rubber duck for short 
range and a yagi beam for long range applications..... e-mail for more info

If you want more.... go for the code-less tech license, it's supposed to have 
packet privledges in 2 and 6 meter bands (I think).... ask-a-ham!

        John Barrett
        <[email-masked]>

------------------------------

From: [email-masked] (Shannon Hendrix)
Subject: Re: Future of linux -- the sequel
Date: Fri, 23 Sep 1994 20:44:42 GMT

Hamish Macdonald ([email-masked]) wrote:

: >>>>> I wrote:
: >> I believe that IDE is *1* bit at a time between the controller and
: >> disk.

: >>>>> On 19 Sep 1994 05:09:15 EST,
: >>>>> In message <[email-masked]>,
: >>>>> [email-masked] (Alan Cox) wrote:

: Alan> Then why are their D0-D7 on the cable 8)

: Ah.  It sounds like a definitive answer here.  Not 16 bits, not 1 bit,
: but 8 bits, just like plain-ordinary SCSI (not wide).

According to my manual and what I've read, it's 16-bits.  I will check
again if I can dig up my docs.  Anyone have an IDE cable pinout they
can post?

-- 
csh
===========================================================================
[email-masked]      | Linux and BSD

------------------------------

From: [email-masked] (Drew Eckhardt)
Subject: Re: NCR 53C406A SCSI
Date: 21 Sep 1994 22:30:27 GMT

In article <[email-masked]>,
Pete Cascio <[email-masked]> wrote:
>
>I've got a Media Vision Pro 3D sound card with SCSI-2.  The SCSI-2 chip is an
>NCR 53C406A.  It looks like it's probably something new, since it's not
>mentioned in the SCSI-HOWTO.

>Does anyone know about this chip?  

Sure - the NCR53c406a is a more integrated version of the NCR53c90,
very similar to what NCR did with the NCR53c400 which was based on the 
NCR53c80.

>Is it compatible (no changes required) with
>another supported NCR SCSI chip driver?  

An alpha NCR53c406a driver is available via anonymous FTP from 
tsx-11.mit.edu:/pub/linux/ALPHA/scsi/ncr53c406-0.9.patch.gz.

-- 
Since our leaders won't respect The Constitution, the highest law of our 
country, you can't expect them to obey lesser laws of any country. 
Boycott the United States until this changes.

------------------------------

From: [email-masked] (Steffen Sledz)
Crossposted-To: zer.t-netz.linux,maus.os.linux,fido.ger.linux,de.comp.os.linux,alt.os.linux
Subject: RealTek RTG3106 XFree?
Date: 24 Sep 1994 10:51:47 GMT

The second try:

Primary I'm looking for a SVGA-XFree-Driver (Linux) for the RTG3106
graphics adapter from RealTek.

If there is no chance to get such a driver, I'll try to build one of
my one. Therefor I need - secondary - some information (or contacts to
receive information) about this chipset (registers, clocks, etc.).
I think a voluminous databook would be the best.

Thanx for any help i'll get.

Answer please per email.

-- 
     _/_/_/_/_/_/_/_/_/_/   Steffen Sledz  email: [email-masked]
   _/_ _     _/    _ _ _/   Kuglerstr. 1          [email-masked]
        _/  _/  _/          10439 Berlin
  _/_/_/   _/   _/_/_/      Germany        phone: +49-30-4446311

------------------------------

From: [email-masked] (Hugh Emberson)
Subject: Re: Windows DLL-type linking possible...?
Date: 25 Sep 1994 04:40:11 GMT

>>>>> "RJ" == Rob Janssen <[email-masked]> writes:

RJ> In <[email-masked]> [email-masked]
RJ> (BATES, ROBERT P.) writes:

RB> Howdy!  I'm currently working on a Windows-based app, and want to
RB> try to port it to Linux under XF86... However, one of the
RB> cornerstones of this project is the ability to relink the function
RB> libs on the fly, without having to exit and restart the
RB> application... Is there anything even remotely similar available on
RB> the Linux or any other Un*x platform?

It's called DLD, you can ftp the linux port (by Aubrey Jaffer & co)
from altdorf.ai.mit.edu:/archive/scmdld-3.2.4.src.tar.gz.

Cheers,
        Hugh
-- 
Hugh Emberson              | ... from the end of the Information 
[email-masked] | Super-four-wheel-drive-track.

------------------------------

From: [email-masked] (Pete Kruckenberg)
Crossposted-To: utah.linux
Subject: Re: pseudo ftp mirrors
Date: 24 Sep 1994 19:27:31 GMT

Brad Midgley ([email-masked]) wrote:

: I know of at least two public dialin linux systems which have a
: dedicated slip connection... After reading about ftp-fs (userfs), I
: think this would be a very useful thing for this type of system.

: For those who haven't read up on it, ftp-fs provides ftp services
: which appear to be a normal file system.  If users make a directory in
: a magic directory, the system actually opens an ftp connection to the
: site named by the directory, after which normal cd, copy, and other
: operations work.

: But the useful thing for public sites with limited bandwidth is the
: fact that ftp-fs caches the files which are brought in.  With a big
: enough (and well-managed) cache area, the site could appear to have a
: much faster connection than it really has.

: What ftp-fs needs before this can be useful:

:       -multiple concurrent accesses to the same site

I haven't used or even dl'd userfs, but I'm confused about this
part. First, why is it necessary to have multiple concurrent accesses
to the same site? Couldn't the interface to ftpfs be a queue of
{localdir, remotedir/file}? Having multiple accesses will not be any
faster than this, and would not be necessary. 

Also, I've used many sites with simultaneous anonymous logins, to
concurrently download several files. It worked just fine. So, unless
ftpfs restricts this, what's the problem with it?

:       -better cache invalidation (perhaps using an access count)
:        currently uses a user-invoked LRU algorithm.
:         -automatic closing of idle connections, with transparent
:          reopen (maybe it already has this.)

: Anyone else looked into or using ftpfs?  Can any sysops estimate just
: how useful the cache would be?

I've just come across this today, but I'd thought about a similar
thing some time ago. Again, I haven't looked at userfs yet (I'll get
to it as soon as an idle cycle comes up), but here are some other
things that'd be interesting to see:

- Automatic mirroring of directories (and maybe index files) at
specified sites. That way, you can see the directory immediately (and
the index file, too), and it is always kept up to date (say, once per
day). When you try to access any of the files, then it is dnloaded via
ftp. This would also provide a mechanism to mark entries in the cache
as 'dirty' based on the new directory info.

These updates could be done on a strictly periodic basis, or the
program could "learn" how often updates needed to be done based on how
often it found updates at the site. Some sites (such as sunsite,
oakland, cica, etc) are updated very frequently, whereas many others
are only updated weekly, monthly, or even quarterly. In fact, you
could extend this algorithm to include directories at each site, since
changes probably tend to be centered on a few directories at a time
(eg, the OS/2 sites probably receive few updates to the 1.x
directories, but quite a few to 2.x and 2.1).

- ftpfs should understand the concept of mirrors, and allow (at the
minimum) the ability to define redundant sites. If it can't get on at
one, it tries the others, until one is open. A priority should be
assigned to let you pick the fastest, or closest, one first. ftpfs
could also dynamically re-assign this priority based on how well the
sites work, so that it will eventually pick the best one by itself.

I'd be interested in your comments on these ideas. I won't have time
for a little while to work on these types of changes (due to other
projects), but I'd love to help when I get the time.

Pete.

  ------------------------------------------------------------------------
  Pete Kruckenberg                       School: [email-masked]
  University of Utah                       Work: [email-masked]
  Computer Engineering    For even more addresses, "finger [email-masked]"

------------------------------

From: [email-masked] (Andreas Busse)
Subject: Re: Linux for DEC 5000s ???
Date: 22 Sep 1994 07:53:17 GMT

In article <[email-masked]>, [email-masked] (Marc Fraioli) writes:
|> In article [email-masked],  [email-masked] (Hrvoje Dogan) writes:
|> >Hi!
|> >
|> >I've heard from a friend of mine that someone out there is developing
|> >Linux for DEC 5000 stations... Could anyone give me some exact piece of
|> >information about it... perhaps an email address of the developers :-))
|> >
|> 
|> Not quite correct, but close.  See the Linux-MIPS FAQ, which is still
|> sitting at:  sunsite.unc.edu:/pub/Linux/Incoming.
|> 
|> ---
|> Marc Fraioli       | "They couldn't hit an elephant at this dist- " 
|> [email-masked]         |    - Last words of Union General John Sedgwick,
|>                    |    Battle of Spotsylvania Court House, U.S. Civil War
|> 
|> 

It is also on ftp.uni-mainz.de:/pub/Linux/MIPS and on
ftp.waldorf-gmbh.de:/pub/linux/mips. In addition, we
have a WWW page: http://www.waldorf-gmbh.de/linux-mips-FAQ.html.
Regarding the actual port, we're looking for people willing
to help. We are currently working on a R4x00 port with the
Deskstation Tyne Computers as the first target. Others as well
as R3000 platforms like DECstations, might follow if there's enough 
demand.
If you have questions, please feel free to mail to 
<[email-masked]>.

Cheers,
Andy
 
==========================================================
Andreas Busse                      | [email-masked]
Waldorf Electronics GmbH, R&D Dep. | Phone: +49 2636-80294
Neustrasse 9-12, D-53498 Waldorf   | Fax:   +49 2636-80188
==========================================================
      >> Windws is ine for bckgroun comunicaions <<

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: 680x0: Ext2 incompatibility with i386
Date: 22 Sep 1994 14:03:21 GMT

In article <[email-masked]>, [email-masked] writes:
|> I have a complaint.
|> 
|> The 680x0 and the x86 versions of the ext2 filesystem are not compatible
|> with each other.
|> 
|> I have a linux box (486/33) that downloaded a lot of files from the
|> 680x0 project (very interesting and cool stuff, that!) and it is currently
|> sitting on a linux/x86 system.  I thought "well, let's preload a cartridge
|> that the linux/680x0 system could boot"(*).  Simple, eh?
|> 
|> Nope.  Turns out the formats are different (the code appears to be
|> very similar though).  No big surprise -- endianity has struck again.
|> Aargh!
|> 
|> As soon as I figure out how the bits are ordered I will add an option
|> to ext2-fs0.5a (sp?) to swap endianity on the x86 box, and hopefully
|> it will also work on the 680x0 box in the reverse direction (though I
|> have my doubts).  However, if someone has fixed this already please
|> point me to a file somewhere.  (Or should I use minix???)

Minix won't fix the problem, too. Since that Minix format used by Linux/68 originated
in another operating system which is called "Minix" (how surprising...) one can
definately say that this is not a bug!

There shouldn't be any real problem in creating a ext2fs code portable to
an other endianess. You could try to make the code recognize some magic
values of ext2fs so user won't even have to know about byte sex of filesystems
on media.

|> There may also be the issue that the 680x0 project is using ext2-fs0.4.

No, Linux/68k uses version 0.5a. In general you can say that the kernel code is
mostly equivalent to Linux/i386 version 1.0.9.

|> Any ideas on how to fix this mess?  Thanks.

I've discussed the problem with someone some time ago. He said "that's why god
made tar". That's another point of view...

   Ralf

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: 680x0: lib incompatibility (4.5.21/26)
Date: 22 Sep 1994 14:16:01 GMT

|> The ramdisk boots fine, but I can't do much with it.  It seems that the
|> root.tar.gz and usr.tar.gz were built using libc.4.5.21, whereas the
|> ramdisk is using libc.4.5.26.  This means that, whenever I try to boot
|> from the system disk, as opposed to the ramdisk,
|> I get problems, the most prevalent one being:
|> 
|> some.file: Error -2

This negative number error messages result from some necessary changes in
/usr/include/linux/unistd.h which have broken all code which has linked
with libc/libm version 4.5.21 or earlier. Furthermore shared libraries
with that version number must be replaced.

You should try to install binaries from tsx-11.mit.edu:/pub/linux/680x0/bin/,
which have been build using the most recent versions of the libraries via the
RAMdisk onto your harddisk(s). After reboot everything should be ok.

The Linux/68k installation is a horrible thing, but wait for version 1.0...

|> (evidently errno isn't getting set right, or something...)
|> 
|> whenever I try to create a file.  Needless to say this wreaks havoc
|> on my ability to build kernels.

With correct gcc setup for either AmigaDOS the kernel builds just like on
Linux/i386. And running Linux/68k you won't see any difference when building
the kernels.

|> My ultimate objective would be to merge the two kernels (680x0 and i386)
|> (unless someone has done this already, in which case kindly point the way!),
|> since the i386 kernel has some nice stuff regarding networking, PPP support,
|> and lots of other stuff.  It appears Linus (or someone, with Linus's approval)
|> has started the work already with the 'arch' subdirectory in /usr/src/linux.

Network stuff (inet) has been portet to Linux/68k just some days ago and is still
pretty untested.

|> I would like to do at least one of the following:
|> 
|> 1. Get an up-to-date version of root.tar.gz and usr.tar.gz.
|> 2. Build new kernels and boot from them.
|> 3. If I have to, use the Amiga as a cross-compiler (can someone give me
|>    some instructions on how to do so, or point me at a FAQ?  The docs
|>    in the project aren't real clear...)
|> 4. Enable networking on the Amiga (I have an A2065 network board).  This
|>    would simplify my life very much, as it means I don't have to reboot
|>    every time I want to transfer data).

Write a driver for that card. You might base your work on the NetBSD driver. Or
use the Golden Gate passive bridge board. This would make porting drivers for
almost all PC cards without DMA a children game.

  Ralf

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: 680x0: separate newsgroup?
Date: 22 Sep 1994 14:19:34 GMT

In article <[email-masked]>, [email-masked] writes:
|> Is there a separate news group for the 680x0 version of Linux?
|> Or do we just use comp.os.linux.* like everyone else?
|> 
|> (Go ahead and tell me "Read the FAQ" if it's appropriate.)

The FAQ won't tell you very much about Linux/68k. But if you're interested, subscribe the 680x0 channel of the Linux mailing list. A newsgroup names maus.os.linux68k exists (languages both german and english), but isn't spread very far. You might however try to read it via the newsserver news.uni-stuttgart.de. No postings, sorry...

 Ralf

------------------------------

** 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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