642 lines
25 KiB
Plaintext
642 lines
25 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 01:13:33 EDT
|
|
Subject: Linux-Development Digest #141
|
|
|
|
Linux-Development Digest #141, Volume #2 Fri, 9 Sep 94 01:13:33 EDT
|
|
|
|
Contents:
|
|
Re: Survey: who wants f77,cc,c++,hpf for linux? (Richard Maine)
|
|
Re: Alpha Linux (Richard Coleman)
|
|
Re: XFconfig86 problems - HELP! (Mike Treadwell)
|
|
Re: Unicode & Linux's future (was Re: Acid) (Andries Brouwer)
|
|
Re: News Spool File System - new filesystem type?? (Alan Barrow)
|
|
Hangs with 1.1.49 ? (Ray Bellis)
|
|
Re: News Spool File System - new filesystem type?? (Pete Deuel)
|
|
Re: Survey: who wants f77,cc,c++,hpf for linux? (Carl Schott)
|
|
ATI Mach64... Does it work...? (Pete Walker)
|
|
Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (Gary R. Hook)
|
|
Re: SyQuest removable SCSI driver? (Rob Janssen)
|
|
Re: [Q] on Linux/MIPS port (Andreas Busse)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
Crossposted-To: comp.lang.fortran
|
|
From: maine@altair.dfrf.nasa.gov (Richard Maine)
|
|
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
|
|
Date: Thu, 8 Sep 1994 15:13:02 GMT
|
|
|
|
|
|
On 7 Sep 1994 22:24:25 -0700, lfm@pgroup.com (Larry Meadows) said:
|
|
|
|
Larry> Given the interest in Linux, I thought I'd post a short survey:
|
|
|
|
Larry> 1. Are people interested in a commercial compiler suite for Linux on
|
|
Larry> Intel Architecture platforms? The suite would include...
|
|
|
|
I have no C/C++ needs that gcc and friends don't satisfy. I can't imagine
|
|
a commercial product successfully competing there; anyway I wouldn't pay
|
|
more than pocket change for one.
|
|
|
|
For f77, f2c is marginal, and g77 isn't yet out of beta. However, I
|
|
don't do new code in f77 any more. I might pay a little for an f77
|
|
compiler on Linux, but not enough to make it worth your while. Say <$100.
|
|
|
|
Hpf is built on f90. I'm not personally interested in the HPF extensions,
|
|
but if your HPF would include a *full* f90 for Linux, then I'd definitely be
|
|
interested (say to the tune of $500-$1000). Subsets need not apply.
|
|
|
|
Larry> 2. How much would people pay for such a product [ loaded question ]?
|
|
|
|
See above.
|
|
|
|
Larry> 3. What distribution media would be required?
|
|
|
|
CDROM preferred. Floppy ok. Various tape media I could deal with
|
|
one way or another, but would be last resorts.
|
|
|
|
Larry> 4. Is there interest in accompanying GUI/non-GUI debuggers and
|
|
Larry> performance analysis tools?
|
|
|
|
Minor.
|
|
|
|
--
|
|
This is all in reference to my personal interests, not NASA's.
|
|
I can't speak for NASA, and I did, I'm sure the answers would be
|
|
different. I don't run Linux out at work anyway, but I do use it at
|
|
home.
|
|
|
|
--
|
|
--
|
|
Richard Maine
|
|
maine@altair.dfrf.nasa.gov
|
|
|
|
|
|
------------------------------
|
|
|
|
From: coleman@math36.gatech.edu (Richard Coleman)
|
|
Subject: Re: Alpha Linux
|
|
Date: 08 Sep 1994 15:17:22 GMT
|
|
|
|
> : Why drop one?
|
|
> : 16 bits = short int
|
|
> : 32 bits = int
|
|
> : 64 bits = long
|
|
>
|
|
> 128 bits = long long :)
|
|
|
|
|
|
I've always thought that C should have some way
|
|
of letting you decided how many bytes to use
|
|
for your computation. It could be as simple as
|
|
having the types
|
|
|
|
int8 ( = char )
|
|
int16 ( = short )
|
|
int24
|
|
int32 ( = int )
|
|
...
|
|
|
|
up to some reasonable value like
|
|
int128. Of course, other syntatic sugar
|
|
would probably be necessary, but the idea
|
|
*appears* simple enough.
|
|
|
|
As we move to 64bit chips and beyond, it seems
|
|
like this will become very desirable.
|
|
|
|
|
|
Richard Coleman
|
|
coleman@math.gatech.edu
|
|
|
|
------------------------------
|
|
|
|
From: miket@cyberspace.net (Mike Treadwell)
|
|
Crossposted-To: comp.windows.x.i386unix,comp.os.linux.help
|
|
Subject: Re: XFconfig86 problems - HELP!
|
|
Date: 8 Sep 1994 15:08:19 GMT
|
|
|
|
Carlos Dominguez (carlos@dorsai.dorsai.org) wrote:
|
|
|
|
: Hi..
|
|
|
|
: Day three, and I still cannot get X up and running on my linux box.
|
|
: I'm using the slackware 2.0 distribution from the morse cd-rom.
|
|
|
|
: As per the HOW-TO's I tried to run the XFconfig86 shell scripts.
|
|
|
|
: I still am getting errors like "cannot cat /tmp/??????"
|
|
: whenever I try to run Xfconfig86 included in my slackware 2.0 cdrom
|
|
: distribution.
|
|
|
|
You are not alone, Carlos. I've been having troubles with an S3 card. At
|
|
one point, I had the same error you do. Xfconfig86 was trying to write a
|
|
temp file to the CD-ROM. I had to change the links to the cd so it wrote
|
|
into a "real" directory. That fixed that problem.
|
|
|
|
Now I had a nice blue Xwindow and no mouse. :(
|
|
|
|
Mike
|
|
|
|
treadwell@attbath.sdi.maine.net
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: aeb@cwi.nl (Andries Brouwer)
|
|
Subject: Re: Unicode & Linux's future (was Re: Acid)
|
|
Date: Thu, 8 Sep 1994 15:15:25 GMT
|
|
|
|
goer@quads.uchicago.edu (Richard L. Goerwitz) writes:
|
|
|
|
>For Arabic, please help me out: Arabic varies letter shapes according to
|
|
>context. A word-initial qof, for example, looks very different from a
|
|
>word-final one. How should this be handled?
|
|
|
|
You can choose: either consider initial, medial and final qof to be
|
|
three distinct letters (in which case the kernel, properly instructed
|
|
using loadkeys and setfont, will display them correctly for you),
|
|
or consider them to be one letter, and have a process between the kernel
|
|
and your application, that handles input and output.
|
|
Similarly, one has these possibilities in Greek (for final and non-final
|
|
sigma) and in English (for capitalization and fi,fl ligatures).
|
|
|
|
The example of English shows that one may leave the choice between
|
|
a and A to the user. It is easy to make a program that will be right
|
|
about capitalization most of the time, but impossible to make a program
|
|
that is always correct.
|
|
It also shows that there are details that only matter in high quality
|
|
printing.
|
|
|
|
It is the same with Arabic. No doubt it will be easiest if you indicate
|
|
yourself which form of the letter you want, but teaching emacs to do
|
|
the choosing for you should not be too difficult either.
|
|
That special glyphs exists for certain combinations of letters only
|
|
matters in high quality printing.
|
|
I think I once showed you in private mail how easy it is to produce
|
|
Arabic with TeX.
|
|
|
|
Anyway, none of this concerns the kernel, with the possible exception
|
|
of the directionality of the text.
|
|
|
|
>There are lots of issues here all wrapped into one. First of all, how
|
|
>will multilingal text be stored? Let us suppose we have an Arabic
|
|
>word in the midst of some English text. The English will run left-to-
|
|
>right, while the Arabic will run right-to-left (-thgir nur lliw cibarA
|
|
>tfel-ot). Does the underlying text get stored in the same direction
|
|
>as the English? (English-Arabic) Or does it get stored in its natural
|
|
>order (English-cibarA)?
|
|
|
|
There is only one natural order, and that is the time order.
|
|
What is said first is stored first.
|
|
The order on a storage medium has nothing to do with the appearance
|
|
when printed.
|
|
|
|
> The advantage of the second order is that the
|
|
>applications don't need to know what is what. They just display the
|
|
>string as-is. However, when it comes to wordwrap time they will fal-
|
|
>ter. You have to know where text in one language begins and another
|
|
>ends in order to get things right.
|
|
|
|
>So what do we do? Should all applications be smart enough to know how
|
|
>to wrap every script on the face of the planet, and be able to recog-
|
|
>nize codes for those languages (i.e. know where the English ends and
|
|
>the cibarA begins?). Seems overkill.
|
|
|
|
Unicode includes symbols for direction change. That suffices for most
|
|
purposes. For specialized cases you need special programs.
|
|
|
|
>I like the idea of a multilingual "window" except that this implies X,
|
|
>and X is largely out of our control. Even the development of a multi-
|
|
>lingual "window" would be silly, since we'd essentially have to write
|
|
>a new set of widgets that probably wouldn't be anywhere near as good
|
|
>as Motif, etc. :-).
|
|
|
|
>Anyone thought this all through? My feeling is that right now the best
|
|
>course is to encourage programmers to avoid code that relies on things
|
|
>like the exact underlying code for 'a' and that assumes characters will
|
|
>be 8-bits.
|
|
|
|
Plan 9 made a different choice, but I found that very few applications
|
|
need to know how many bytes there are in a symbol. That is, recoding
|
|
these programs to make them use "runes" is usually unnecessary.
|
|
(However, columns are often messed up, and strlen() has to be replaced.)
|
|
Unicode in UTF-8 encoding yields symbols encoded with a variable number
|
|
of bytes, but most programs only copy text strings, or parse them into
|
|
identifiers etc., and since ASCII is embedded as a collection of symbols
|
|
each represented by a single byte, this does not pose any problems.
|
|
|
|
So, internal representation is no problem. Input is easy enough with
|
|
some version of loadkeys when the alphabet is small, and requires a
|
|
separate daemon when the alphabet is large, or when your input is not
|
|
easily converted to the internal representation.
|
|
|
|
Output is difficult. The precise rules are complicated, and fonts take
|
|
a lot of space. The console driver can only handle the very simplest
|
|
cases.
|
|
|
|
------------------------------
|
|
|
|
From: jab@narcesc.atl.hp.com (Alan Barrow)
|
|
Crossposted-To: news.software.b
|
|
Subject: Re: News Spool File System - new filesystem type??
|
|
Date: 9 Sep 1994 00:16:25 GMT
|
|
|
|
Good comments about moving away from the "one file=one article" scheme of
|
|
C-News/INN deleted.....
|
|
|
|
Just an observation:
|
|
|
|
As an admin that ran both a "notes" site and 2 B-news/C-news/INN sites
|
|
for the last 4-5 years, I sure like the convenience of having the
|
|
old clunky flat text files.
|
|
|
|
Notes may not be a good example to use, but it had a database type
|
|
approach similar to our current history approach. (index file and a
|
|
single data file) for each group.
|
|
|
|
There were advantages (fewer inode problems, maybe it was faster, who
|
|
knows) but on a regular basis a "bad" (malformed, etc) article would trash
|
|
a group database. There were no recovery tools, and you would usually
|
|
lose the entire group. Heaven forbid a system failure.
|
|
|
|
The same is true of WinNet, a Windoze uucp based new/mail app. It is
|
|
actually a pretty usable reader, in fact. But it also uses a database, and
|
|
a reboot/power failure, GP fault, whatever while processing articles
|
|
will often trash the DB.
|
|
|
|
I think the modern news systems could avoid most of the the defects in
|
|
the notes and WinNet approach. (just a small matter of programing) :-)
|
|
|
|
But, I really like being able to do "brute force" emergency admin of my
|
|
spool dir using OS cmds and other tools. (find, reap, even rm -rf soc/* on
|
|
a bad day)
|
|
|
|
The convenience of the current approach make it worth enduring the performance
|
|
and space hits. A new design would have to be faster, compress 2-3X, and
|
|
totally compatible with INN to get my interest. Even then I would think hard.
|
|
800 Mb of files under 1k is not pretty. NOV makes it endurable. But it
|
|
works, and I rarely have to "fix" the article base.
|
|
|
|
Someone else wrote:
|
|
|
|
>:The Right Way to implement this kind of filesystem would be a
|
|
>:user-space process, reading and writing the raw device -- essentially
|
|
>:just using /dev/hd<foo> as a database. Putting it in the kernel gains
|
|
>:you nothing but more kernel bloat.
|
|
|
|
I do agree with Ian here. Make it general enough, like the real DB's do
|
|
on unix. You can write to a raw partition, or to a file, depending on
|
|
your preferences. Unix does not care. Individual OS's often have
|
|
restrictions that make one approach preferable. An example:
|
|
|
|
HP-UX 8.0- Max raw partition 2Gb, Max individual file size was
|
|
2Gb less FS overhead.
|
|
|
|
HP-UX 9.0x- Max raw partition is still 2Gb, but with LVM
|
|
(logical volumes) you could easily have a logical volume of 4Gb
|
|
or more. (In or out of a filesystem) You can have a bigger file
|
|
than you can have a raw partition. (due to lseek limitations)
|
|
|
|
With the general approach like "real DB's", you pick what is best for
|
|
your site. At least we do not (usually) have to worry about backup and
|
|
restore of article bases. This adds another layer. (Just another tool that
|
|
would be needed)
|
|
|
|
Someone else wrote:
|
|
|
|
>I hate to disagree, but doing it through the kernel gains you portability.
|
|
|
|
I really disagree here. I have never seen an instance when moving a
|
|
function from user space to the kernel made it more portable. Usually
|
|
the opposite occurs. This is how we ended up with Streams, etc. (To
|
|
avoid driver writing) Stick with things you can implement with POSIX
|
|
type generic calls. (Good luck on your project, though :-> )
|
|
|
|
But do not let me persuade anyone from writing the next generation
|
|
system. (Or even an enhancement) If it were not for the Rich Salz's and
|
|
Henry Spencer's, I would still be stuck using (and repairing) Notes! :-)
|
|
|
|
Have fun!
|
|
|
|
Alan Barrow km4ba | If a little knowledge.....
|
|
Work: jab@atl.hp.com | is a dangerous thing.....
|
|
Home: alan@km4ba.ampr.org | then what is the Anti-Dote???
|
|
|
|
------------------------------
|
|
|
|
From: rpb@psy.ox.ac.uk (Ray Bellis)
|
|
Subject: Hangs with 1.1.49 ?
|
|
Date: 08 Sep 1994 15:25:41 GMT
|
|
|
|
I'm having problems where my linux box hangs when doing any significant
|
|
network access, such as compiling or running X applications (I've got
|
|
/usr remote mounted using NFS).
|
|
|
|
When the system hangs there aren't any debug messages, the system
|
|
just stops dead. This didn't used to happen when running 1.0.9.
|
|
Unfortunately I can't stay running 1.0.9 since the precompiled
|
|
version on the Slackware 2.0 distribution doesn't contain the
|
|
devices I need, and if I build 1.0.9 myself it hangs when trying
|
|
to detect my NE2000 ethernet card.
|
|
|
|
I've posted this to the development group because it seems to be
|
|
a problem with the new kernel.
|
|
|
|
Thanks,
|
|
|
|
Ray.
|
|
--
|
|
==============================================================================
|
|
R. P. Bellis E-Mail: <Ray.Bellis@psy.ox.ac.uk>
|
|
Computing Officer
|
|
MRC Centre in Brain and Behaviour
|
|
Dept. of Experimental Psychology
|
|
University of Oxford Whois: (RB83)
|
|
South Parks Road Tel: +44 865 271359
|
|
Oxford OX1 3UD Fax: +44 865 310447
|
|
==============================================================================
|
|
|
|
------------------------------
|
|
|
|
From: deuelpm@craft.camp.clarkson.edu (Pete Deuel)
|
|
Crossposted-To: news.software.b
|
|
Subject: Re: News Spool File System - new filesystem type??
|
|
Date: Thu, 8 Sep 1994 21:57:24
|
|
|
|
In article <3h0buA4DBh107h@scs.scs.no> lregebro@scs.scs.no (Lennart Regebro) writes:
|
|
>From: lregebro@scs.scs.no (Lennart Regebro)
|
|
>Subject: Re: News Spool File System - new filesystem type??
|
|
>Date: 8 Sep 1994 15:00:04 -0000
|
|
|
|
>In <ROB.94Sep7164407@gangrene.berkeley.edu> rob@agate.berkeley.edu (Rob Robertson) writes:
|
|
|
|
>>I don't think this would work, as so many words in usenet postings are
|
|
>>misspelled that looking them up in a dictionary, probably won't buy
|
|
>>you anything, cuz they won't be found!
|
|
>> ^
|
|
>> c whut i meen?
|
|
|
|
>The very common words 'Newsgroups:', 'Subject:', 'References:', 'alt.sex'
|
|
>and 'cuz' would still be common enough to be in a common directory.
|
|
|
|
Well, the easiest way to compile such a dictionary, I would think, is to do
|
|
like Webster's does--steal the top 50,000 from the front page of the
|
|
Times. Of course, *we* keep stats on word frequency in all the groups for
|
|
about... a week? Whatever news admins feel is a good amount of
|
|
time...
|
|
|
|
But, not on *my* system! :)
|
|
(Maybe someone with access to a 3-6 processor machine would volunteer?!!)
|
|
|
|
My .02...
|
|
|
|
Pete
|
|
===================================================
|
|
"Actually, I'm a lab mouse on stilts..."
|
|
|
|
E-mail: deuelpm@craft.camp.clarkson.edu
|
|
===================================================
|
|
|
|
------------------------------
|
|
|
|
From: cgschott@psu.edu (Carl Schott)
|
|
Crossposted-To: comp.lang.fortran
|
|
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
|
|
Date: Thu, 8 Sep 1994 15:30:37 GMT
|
|
|
|
Larry Meadows (lfm@pgroup.com) wrote:
|
|
: Hello
|
|
|
|
: Given the interest in Linux, I thought I'd post a short survey:
|
|
|
|
: 1. Are people interested in a commercial compiler suite for Linux on
|
|
: Intel Architecture platforms? The suite would include true compilers
|
|
: for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
|
|
: High Performance Fortran. C, f77, and C++ could support shared memory
|
|
: parallelism (thread-based) if system support is available in Linux.
|
|
: HPF would support socket-based communications on networked systems,
|
|
: and could support custom interconnects.
|
|
|
|
gcc/g++/f2c are sufficient for my C/C++/Fortran-77 needs, but I WOULD be
|
|
interested in a Fortran-90 compiler. AFAIK, there's no free version of
|
|
such a compiler under development.
|
|
|
|
: 2. How much would people pay for such a product [ loaded question ]?
|
|
|
|
~$300
|
|
|
|
: 3. What distribution media would be required?
|
|
|
|
Floppy/net/QIC-80
|
|
|
|
: 4. Is there interest in accompanying GUI/non-GUI debuggers and
|
|
: performance analysis tools?
|
|
|
|
Not as much as in the compiler itself, but it might be a selling point
|
|
if included (depending on features/performance).
|
|
|
|
Carl Schott
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help,comp.windows.x.i386unix
|
|
From: pwalker@pinocchio.encore.com (Pete Walker)
|
|
Subject: ATI Mach64... Does it work...?
|
|
Date: Thu, 8 Sep 1994 15:22:43 GMT
|
|
|
|
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.
|
|
|
|
|
|
--
|
|
Best Regards
|
|
|
|
Peter
|
|
==================================================================
|
|
Peter Walker
|
|
paw@cs.brown.edu
|
|
_________________________________________________________________
|
|
|
|
------------------------------
|
|
|
|
From: hook@chaco.aix.dfw.ibm.com (Gary R. Hook)
|
|
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
|
|
Date: Thu, 8 Sep 1994 15:36:01 GMT
|
|
Reply-To: hook@vnet.ibm.com
|
|
|
|
In article <34kk8o$jdb@bosnia.pop.psu.edu>, barr@pop.psu.edu (David Barr) writes:
|
|
|> >
|
|
|> >Why don't you just use LD_LIBRARY_PATH to point to the different library
|
|
|> >location.
|
|
|>
|
|
|> LD_LIBRARY_PATH is a hack, and a painful one at that.
|
|
|>
|
|
|> 1) It increases load time
|
|
|> 2) It applies for _all_ libraries, not just the one you're interested with.
|
|
|> 3) It interacts badly with ld, such that when things are compiled with
|
|
|> LD_LIBRARY_PATH set, the program then assumes that it will continue
|
|
|> to be set.
|
|
|
|
But there has to be a mechanism for telling the loader where to find
|
|
libraries. IMHO the mistake is in letting ld see the variable and
|
|
use the value. It would be consistent to have LD_LIBRARY_PATH be
|
|
strictly runtime. The downside is (2), but there's got to be some
|
|
pain :-) doesn't there?
|
|
|
|
________________________________________________________________________
|
|
Gary R. Hook | "Yes, John, but when Pirates of
|
|
AIX Application Enabling | the Caribbean breaks down, the
|
|
IBM Corporation, Southlake, Texas | pirates don't eat the tourists."
|
|
The above opinions are all mine. | - the lawyer in "Jurassic Park"
|
|
|
|
------------------------------
|
|
|
|
From: rob@pe1chl.ampr.org (Rob Janssen)
|
|
Subject: Re: SyQuest removable SCSI driver?
|
|
Reply-To: pe1chl@rabo.nl
|
|
Date: Thu, 8 Sep 1994 19:00:48 GMT
|
|
|
|
In <aturnerCvsEoD.66n@netcom.com> aturner@netcom.com (Aaron Turner) writes:
|
|
|
|
>Hi all,
|
|
>I have a SyQuest 3720S (270MB SCSI removeable HD) running off a SB16
|
|
>SCSI-2. I was wondering if someone has written a driver for it like the
|
|
>one SyQuest provides for DOS that allows automatic recognition of a new
|
|
>cartridge when I swap cartridges. (without the driver you can't swap
|
|
>cartridges without rebooting.) Is there one for Linux? If not could one
|
|
>be written? If so could someone point me the way? I can get any spec I
|
|
>might need about the drive (how it reports swapping, etc.) since I work
|
|
>at SyQuest. Or would someone be willing to write it? I'm very new to
|
|
|
|
Removable disks are already supported. Just unmount the disk, swap
|
|
the cartridge and mount the new one.
|
|
|
|
>Linux and have a little programming background, but nothing like this. I
|
|
>could get you anything you might need- I might even be able to con one of
|
|
>my friends who programmed the DOS version to give you some info. BTW,
|
|
>yes, I do know that I can just umount & then mount the new cartridge, but
|
|
>since I swap cartridges so much this is becoming a pain. TIA for anyone
|
|
>who can give me some insight!
|
|
|
|
Ahaaaa! You want to swap cartridges without unmounting.
|
|
That cannot be done. The system *has* to be informed about removing
|
|
the cartridge before you actually do it. It has to write back information,
|
|
and return the state of the filesystem to "clean".
|
|
Linux is not DOS!
|
|
|
|
However, if there is some signal from the drive that you press the
|
|
button to unmount the disk, the unmount operation maybe could be done
|
|
automatically. I don't know if this Syquest model supports "door locking"
|
|
and has motor-driven eject, but if it does this could be possible.
|
|
|
|
(drives with door locking are locked as long as the disk is mounted, so
|
|
that you cannot swap the disk without first unmounting it. This is
|
|
intentional)
|
|
|
|
Rob
|
|
--
|
|
=========================================================================
|
|
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
|
|
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
|
|
=========================================================================
|
|
|
|
------------------------------
|
|
|
|
From: andy@resi.waldorf-gmbh.de (Andreas Busse)
|
|
Subject: Re: [Q] on Linux/MIPS port
|
|
Date: 8 Sep 1994 09:52:34 GMT
|
|
|
|
In article <1994Sep2.103748.4362@ludens>, tiv@ludens.elte.hu writes:
|
|
|> Hello,
|
|
|>
|
|
|> I've read the annonuncement and FAQ on the MIPS/linux port, and there are
|
|
|> still things I'd like to know...
|
|
|> Does this port work only for that specific board ?
|
|
|
|
Currently yes, since we only have this one (besides the MIPS Magnum 4000
|
|
on which I am writing this article...). However, it shouldn't be a problem
|
|
to port Linux/MIPS to other ARC (Advanced Risc Computer, a specification of MIPS, Microsoft and a lot of other companies) compliant boards, since they
|
|
all have ISA, EISA, VLB or PCI bus systems.
|
|
That means: if your MIPS board runs Windoze NT, it will probably run
|
|
Linux/MIPS too, perhaps after *slightly* patching the kernel. There
|
|
might be some differences in the address maps and how DMA is handled.
|
|
|
|
|> What about other architectures based on MIPS processors ?
|
|
|
|
See above.
|
|
|
|
|> Once this project is done, how difficult would be to port _that_
|
|
|> to a MIPS based DECstation for example ? I'm curious because we have a bunch
|
|
|> of DECstation 3100's (Running MIPS R3000 as I know and Ultrix). Currently
|
|
|> we can only use them for X terminals (lack of memory and hd) but maybe with
|
|
|> the efficient memory management of linux ( e.g. shared libs and dynamic buffer
|
|
|> cache - things that Ultrix never heard about ) we could use them as regular
|
|
|> workstations...
|
|
|> Is such a porting project planned anywhere ? I'd contribute, but I have not
|
|
|> enough time, resources and experience to start it alone.
|
|
|> Generally, I think it'd make sense to port linux (as a free, modern and usable
|
|
|> unix clone) to architectures which are the latest ones (like ALPHA and PowerPC)
|
|
|> but they're reliable, incorporate standards (like SCSI) and widely used.
|
|
|>
|
|
|> tivadar
|
|
|>
|
|
|
|
The major problem is that these old DECstations have R3000 processors.
|
|
There are some differences in the MMUs and in the instructions set of
|
|
the R3xxx and R4xxx which will make a R3xxx port a bit more complicated.
|
|
Another thing is that DECstations don't have an ISA (or similar "industry standard") bus. Most drivers must be rewritten to the specific I/O subsystem these boxes have.
|
|
However, the R3xxx and R4xxx processors are similar enough to take
|
|
advantage of our port. It should be at least possible to provide
|
|
user-mode binary compatibility between R3xxx and R4xxx boxes - and this
|
|
would help a lot ! BTW, this is what MIPS has done anyway - the stuff
|
|
I write on my MIPS 4030 runs perfectly on our MIPS 3330 and vice versa.
|
|
It will also help that our Mips Port is native little-endian, just like
|
|
your PC and your DECstation.
|
|
|
|
We already received several questions what's about DECstations
|
|
while others prefer to wait for the ultraP (a module which holds
|
|
both a Pentium and a R4x00 and lets you choose which CPU to use)
|
|
or whatever will come along.
|
|
I guess there will be a lot of MIPS board running Linux/MIPS in
|
|
near future - we just need a little help since we can't buy all
|
|
of them !
|
|
|
|
Andy
|
|
|
|
===============================================================================
|
|
Waldorf Electronics GmbH | Phone: +49 (0)2636-80294
|
|
R&D Department | Fax: +49 (0)2636-80188
|
|
Neustrasse 9-12, 53498 Waldorf, Germany | email: andy@waldorf-gmbh.de
|
|
===============================================================================
|
|
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|