2550 lines
108 KiB
Plaintext
2550 lines
108 KiB
Plaintext
Linus Torvalds Posts on comp.os.minix
|
|
Searched Groups for group:comp.os.minix author:Linus author:Torvalds.
|
|
Results 1 - 44 of 44.
|
|
============================================================
|
|
|
|
From: torvalds@cc.helsinki.fi
|
|
Newsgroups: comp.os.minix
|
|
Subject: gcc on minix-386 doesn't optimize?
|
|
Message-ID: <1991Mar29.151930.5767@cc.helsinki.fi>
|
|
Date: 29 Mar 91 15:19:30 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 22
|
|
|
|
|
|
Hello everybody,
|
|
I've had minix for a week now, and have upgraded to 386-minix (nice),
|
|
and duly downloaded gcc for minix. Yes, it works - but ... optimizing
|
|
isn't working, giving an error message of "floating point stack
|
|
exceeded" or something. Is this normal? I had problems with the crcs, so
|
|
I'm not actually sure I've gotten it right (pretty sure though), but I'm
|
|
somewhat surprised that gcc would use floating point in normal
|
|
optimizations when the program under compilation certainly doesn't.
|
|
|
|
I've downloaded the sources (2.9Mb for just gcc, not gas etc), but due
|
|
to a rather small HD I've been unable to untar them completely, so I
|
|
cannot recompile or anything. I could get one of the floating point
|
|
packages floating around, if that is the problem, but my understanding
|
|
is that the current binary cannot take advantage of them anyway. Could
|
|
somebody please tell me what's the story behind the gcc floating point?
|
|
|
|
advTHANKSance, Linus Torvalds
|
|
torvalds@cc.helsinki.fi
|
|
|
|
PS. No it's not a big problem, even without optimization I get around
|
|
7000 dhrystones, I'm just wondering. And yes - I'll get a bigger HD as
|
|
soon as my somewhat strained economy can make it 8-).
|
|
|
|
=======================================
|
|
=======================================
|
|
From: torvalds@cc.helsinki.fi
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: PS and Minix-386.
|
|
Message-ID: <1991Apr1.123039.5786@cc.helsinki.fi>
|
|
Date: 1 Apr 91 12:30:39 GMT
|
|
References: <7210@munnari.oz.au> <kemp.670399990@convex.convex.com>
|
|
Organization: University of Helsinki
|
|
Lines: 46
|
|
|
|
|
|
In article <kemp.670399990@convex.convex.com>, kemp@convex.com (Phil Kemp) writes:
|
|
> In <7210@munnari.oz.au> bevan@ecr.mu.oz.au (Bevan Anderson) writes:
|
|
>
|
|
>>I recompiled ps.c with bcc -3 so to give me a 32 bit
|
|
>>binary. Now when I execute ps (as root) I get:
|
|
|
|
>>memory fault: core dumped.
|
|
|
|
>>This happens after ps puts up the top line of the output (TTY LINE etc)
|
|
>>I am doing a ps -U but that gets the same problem.
|
|
>
|
|
> I too have had similar problems with the various versions of ps with
|
|
> the 386 Minix kernel. Maybe someone could post a version of ps.c which
|
|
> does in fact work with Bruce's 386 Minix...
|
|
>
|
|
> I know I would sure appreciate it.
|
|
>
|
|
> Thanks.
|
|
> PK
|
|
> --
|
|
> Phil Kemp
|
|
> CONVEX Computer of Canada Ltd.
|
|
> Voice:(403)-233-2815
|
|
> UUCP:kemp@convex.com
|
|
|
|
RTFSC (Read the F**ing Source Code :-) - It is heavily commented and the
|
|
solution should be obvious (take that with a grain of salt, it certainly
|
|
stumped me for a while :-). Simply change the 4 define-lines at the
|
|
start (well, I'd guess about line 40) that read
|
|
|
|
#define kernel "/usr/src/kernel/kernel"
|
|
#define mm "/usr/src/mm/mm"
|
|
#define fs "/usr/src/fs/fs"
|
|
#define init "/usr/src/tools/init"
|
|
|
|
to where-ever you have them now (/etc/system/kernel,fs,init,mm if you
|
|
did as the tutor that is floating around said)
|
|
|
|
NOTE! I wrote this from memory - this is certainly not exactly how the
|
|
defines look (and I'm not certain that there is a define for init, I
|
|
think it never gets used). It should be no problem finding them though -
|
|
there should be nothing like it elsewhere in ps.c. It is inside a #if by
|
|
the way. Cdiffs might be a good idea, but I don't have access to my
|
|
minix-box right now. Doing them manually wasn't any problem.
|
|
|
|
Linus Torvalds torvalds@cc.helsinki.fi
|
|
|
|
===============================
|
|
===============================
|
|
From: torvalds@cc.helsinki.fi
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: 386 goodies sought
|
|
Message-ID: <1991Apr8.125827.5888@cc.helsinki.fi>
|
|
Date: 8 Apr 91 12:58:27 GMT
|
|
References: <1991Apr7.230652.3535@cunixf.cc.columbia.edu>
|
|
Organization: University of Helsinki
|
|
Lines: 47
|
|
|
|
|
|
In article <1991Apr7.230652.3535@cunixf.cc.columbia.edu>, rt2@cunixb.cc.columbia.edu (Rens Troost) writes:
|
|
>
|
|
> I've just gone through upgrading to 386 (thanks, Bruce) and now am looking
|
|
> for some new stuff -- if I remember correctly someone had a set of diffs for
|
|
> emacs. What is the status of this?
|
|
>
|
|
> Also, has anybody gotten bash working for minix? gdb? (this latter must be
|
|
> a dream...)
|
|
>
|
|
> -Rens
|
|
> rt2@cunixb.cc.columbia.edu
|
|
> rens@gnu.ai.mit.edu
|
|
|
|
I'm rather new to 386-Minix myself, but have tried porting some stuff
|
|
and have a few comments:
|
|
|
|
1) Get gcc! Without this your porting will be much more difficult. You
|
|
don't even need to do anything, it's been ported already, and binaries
|
|
can be found on plains. Great!
|
|
|
|
2) I dont know about others, but with 386-minix and gcc the system is
|
|
close enough to "real" unix that most gnu-programs seem to work without
|
|
any major changes. I tried getting a "minix-ported" bash, and had no end
|
|
of troubles. Get the real unmodified gnu-sources.
|
|
|
|
3) gnu tar, gawk and bison are easy - get them, make some small changes,
|
|
and you're up and away. Took me a couple of hours to port them, and I
|
|
was totally new to the game.
|
|
|
|
4) Bash is hell :-) It uses ioctl etc that at least vanilla-minix386
|
|
doesn't care about (anybody hacked the kernel?), but it's doable. I
|
|
ported it yesterday, sort of (you'll need bison), haven't had time to
|
|
test it out yet. I have problems with readline, but I think it's a minor
|
|
problem. It hasn't bombed on me yet though.
|
|
|
|
5) If you want emacs, I think there are patches on plains, but I'm not
|
|
sure. If uemacs will do (it does for me), get that - it takes no porting
|
|
at all (well very little - change some defines in estruct.h, maybe some
|
|
very minor other changes). Be sure to get 3.10 (latest version that I'm
|
|
aware of), it has &kbg, which allows you to make appropriate macros for
|
|
the cursor keys - no need to change the sources. There is a bug in
|
|
bind.c (I think),but there are bug-fixes available that seem to clear it
|
|
up (if you want it, mail me).
|
|
|
|
Happy porting, Linus
|
|
|
|
Linus Torvalds torvalds@cc.helsinki.fi
|
|
|
|
==========================
|
|
==========================
|
|
From: torvalds@cc.helsinki.fi
|
|
Newsgroups: comp.os.minix
|
|
Subject: Anyone in need of bash? (minix-386, maybe ST)
|
|
Message-ID: <1991Apr13.181744.5973@cc.helsinki.fi>
|
|
Date: 13 Apr 91 18:17:44 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 18
|
|
|
|
|
|
I've recently ported bash to minix-386 (nice, but takes about 300kB of
|
|
RAM). It's been "tested" by me using it all the time (good editing and
|
|
history - couldn't live without it any more), but I won't make any
|
|
guarantees. If anybody is interested in cdiffs against bash-1.05, please
|
|
mail me (I'll post if there is enough interest).
|
|
|
|
The port definitely needs GCC, and 386-minix. ST-minix will probably
|
|
work as well (I've sent it to one ST-minixer), after changeing a #define
|
|
LITTLE_ENDIAN to BIG_ENDIAN. If the port already has been done by
|
|
someone else - just ignore this message.
|
|
|
|
Linus Torvalds torvalds@cc.helsinki.fi
|
|
|
|
PS. I've hacked the kernel to accept gcc-compiled programs directly
|
|
without going through gcc2minix, but I haven't tested it very much yet
|
|
(bash works though, so most things probably will). Changes are trivial,
|
|
mail me if interested. (And yes - it accepts old minix format too - you
|
|
don't have to recompile everything :-)
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Gcc-1.40 and a posix-question
|
|
Keywords: gcc, posix
|
|
Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
|
|
Date: 3 Jul 91 10:00:50 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 28
|
|
|
|
|
|
Hello netlanders,
|
|
|
|
Due to a project I'm working on (in minix), I'm interested in the posix
|
|
standard definition. Could somebody please point me to a (preferably)
|
|
machine-readable format of the latest posix rules? Ftp-sites would be
|
|
nice.
|
|
|
|
As an aside for all using gcc on minix - the new version (1.40) has been
|
|
out for some weeks, and I decided to test what needed to be done to get
|
|
it working on minix (1.37.1, which is the version you can get from
|
|
plains is nice, but 1.40 is better :-). To my surpice, the answer
|
|
turned out to be - NOTHING! Gcc-1.40 compiles as-is on minix386 (with
|
|
old gcc-1.37.1), with no need to change source files (I changed the
|
|
Makefile and some paths, but that's it!). As default this results in a
|
|
compiler that uses floating point insns, but if you'd rather not,
|
|
changing 'toplev.c' to define DEFAULT_TARGET from 1 to 0 (this is from
|
|
memory - I'm not at my minix-box) will handle that too. Don't make the
|
|
libs, use the old gnulib&libc.a. I have successfully compiled 1.40 with
|
|
itself, and everything works fine (I got the newest versions of gas and
|
|
binutils at the same time, as I've heard of bugs with older versions of
|
|
ld.c). Makefile needs some chmem's (and gcc2minix if you're still using
|
|
it).
|
|
|
|
Linus Torvalds torvalds@kruuna.helsinki.fi
|
|
|
|
PS. Could someone please try to finger me from overseas, as I've
|
|
installed a "changing .plan" (made by your's truly), and I'm not certain
|
|
it works from outside? It should report a new .plan every time.
|
|
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Gcc-1.40 and a posix-question
|
|
Keywords: gcc, posix
|
|
Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
|
|
Date: 3 Jul 91 10:00:50 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 28
|
|
|
|
|
|
Hello netlanders,
|
|
|
|
Due to a project I'm working on (in minix), I'm interested in the posix
|
|
standard definition. Could somebody please point me to a (preferably)
|
|
machine-readable format of the latest posix rules? Ftp-sites would be
|
|
nice.
|
|
|
|
As an aside for all using gcc on minix - the new version (1.40) has been
|
|
out for some weeks, and I decided to test what needed to be done to get
|
|
it working on minix (1.37.1, which is the version you can get from
|
|
plains is nice, but 1.40 is better :-). To my surpice, the answer
|
|
turned out to be - NOTHING! Gcc-1.40 compiles as-is on minix386 (with
|
|
old gcc-1.37.1), with no need to change source files (I changed the
|
|
Makefile and some paths, but that's it!). As default this results in a
|
|
compiler that uses floating point insns, but if you'd rather not,
|
|
changing 'toplev.c' to define DEFAULT_TARGET from 1 to 0 (this is from
|
|
memory - I'm not at my minix-box) will handle that too. Don't make the
|
|
libs, use the old gnulib&libc.a. I have successfully compiled 1.40 with
|
|
itself, and everything works fine (I got the newest versions of gas and
|
|
binutils at the same time, as I've heard of bugs with older versions of
|
|
ld.c). Makefile needs some chmem's (and gcc2minix if you're still using
|
|
it).
|
|
|
|
Linus Torvalds torvalds@kruuna.helsinki.fi
|
|
|
|
PS. Could someone please try to finger me from overseas, as I've
|
|
installed a "changing .plan" (made by your's truly), and I'm not certain
|
|
it works from outside? It should report a new .plan every time.
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: gcc 1.40 for Minix-386
|
|
Message-ID: <1991Aug20.121735.19947@klaava.Helsinki.FI>
|
|
Date: 20 Aug 91 12:17:35 GMT
|
|
References: <1991Aug19.220059.27322@Informatik.TU-Muenchen.DE>
|
|
Organization: University of Helsinki
|
|
Lines: 26
|
|
|
|
|
|
In article <1991Aug19.220059.27322@Informatik.TU-Muenchen.DE> rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) writes:
|
|
>Someone reported a while ago that compiling gcc 1.40 for Minix-386 would
|
|
>be straightforward with the running gcc 1.37. I have tried this.
|
|
>Compiling gcc was not that difficult. But I have a problem now.
|
|
>cc1 cores on signal 6 when
|
|
>a) a file with floating point is compiled
|
|
>b) -O is used.
|
|
>
|
|
>Kai Uwe Rommel
|
|
>
|
|
|
|
Ok. I'm the one that reported porting was easy. Seems I didn't explain
|
|
enough :-).
|
|
|
|
This is what happens when you either have compiled cc1 without using
|
|
-msoft-float (the gcc from plains uses soft-float by default, but if you
|
|
compile cc1-1.40 with itself you must put a -msoft-float in the
|
|
makefile). The other possibility is that you aren't using the crt0.o
|
|
that was shipped with the original gcc-1.37.1 by black&tobin (?). It is
|
|
needed to get the signal handler started.
|
|
|
|
The thing to do is recompile cc1 from scratch while using -msoft-float,
|
|
or changing DEFAULT_TARGET to 0 in tm.h (and then recompiling cc1).
|
|
This should fix the problem.
|
|
|
|
Linus (torvalds@kruuna.helsinki.fi)
|
|
|
|
==========================
|
|
==========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: What would you like to see most in minix?
|
|
Summary: small poll for my new operating system
|
|
Keywords: 386, preferences
|
|
Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
|
|
Date: 25 Aug 91 20:57:08 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 20
|
|
|
|
|
|
|
|
Hello everybody out there using minix -
|
|
|
|
I'm doing a (free) operating system (just a hobby, won't be big and
|
|
professional like gnu) for 386(486) AT clones. This has been brewing
|
|
since april, and is starting to get ready. I'd like any feedback on
|
|
things people like/dislike in minix, as my OS resembles it somewhat
|
|
(same physical layout of the file-system (due to practical reasons)
|
|
among other things).
|
|
|
|
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
|
|
This implies that I'll get something practical within a few months, and
|
|
I'd like to know what features most people would want. Any suggestions
|
|
are welcome, but I won't promise I'll implement them :-)
|
|
|
|
Linus (torvalds@kruuna.helsinki.fi)
|
|
|
|
PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
|
|
It is NOT protable (uses 386 task switching etc), and it probably never
|
|
will support anything other than AT-harddisks, as that's all I have :-(.
|
|
|
|
==========================
|
|
==========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Free minix-like kernel sources for 386-AT
|
|
Keywords: 386, preliminary version
|
|
Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI>
|
|
Date: 5 Oct 91 05:41:06 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 55
|
|
|
|
|
|
Do you pine for the nice days of minix-1.1, when men were men and wrote
|
|
their own device drivers? Are you without a nice project and just dying
|
|
to cut your teeth on a OS you can try to modify for your needs? Are you
|
|
finding it frustrating when everything works on minix? No more all-
|
|
nighters to get a nifty program working? Then this post might be just
|
|
for you :-)
|
|
|
|
As I mentioned a month(?) ago, I'm working on a free version of a
|
|
minix-lookalike for AT-386 computers. It has finally reached the stage
|
|
where it's even usable (though may not be depending on what you want),
|
|
and I am willing to put out the sources for wider distribution. It is
|
|
just version 0.02 (+1 (very small) patch already), but I've successfully
|
|
run bash/gcc/gnu-make/gnu-sed/compress etc under it.
|
|
|
|
Sources for this pet project of mine can be found at nic.funet.fi
|
|
(128.214.6.100) in the directory /pub/OS/Linux. The directory also
|
|
contains some README-file and a couple of binaries to work under linux
|
|
(bash, update and gcc, what more can you ask for :-). Full kernel
|
|
source is provided, as no minix code has been used. Library sources are
|
|
only partially free, so that cannot be distributed currently. The
|
|
system is able to compile "as-is" and has been known to work. Heh.
|
|
Sources to the binaries (bash and gcc) can be found at the same place in
|
|
/pub/gnu.
|
|
|
|
ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled
|
|
(and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to
|
|
set it up if you want to run it, so it is not yet a standalone system
|
|
for those of you without minix. I'm working on it. You also need to be
|
|
something of a hacker to set it up (?), so for those hoping for an
|
|
alternative to minix-386, please ignore me. It is currently meant for
|
|
hackers interested in operating systems and 386's with access to minix.
|
|
|
|
The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
|
|
you are still interested, please ftp the README/RELNOTES, and/or mail me
|
|
for additional info.
|
|
|
|
I can (well, almost) hear you asking yourselves "why?". Hurd will be
|
|
out in a year (or two, or next month, who knows), and I've already got
|
|
minix. This is a program for hackers by a hacker. I've enjouyed doing
|
|
it, and somebody might enjoy looking at it and even modifying it for
|
|
their own needs. It is still small enough to understand, use and
|
|
modify, and I'm looking forward to any comments you might have.
|
|
|
|
I'm also interested in hearing from anybody who has written any of the
|
|
utilities/library functions for minix. If your efforts are freely
|
|
distributable (under copyright or even public domain), I'd like to hear
|
|
from you, so I can add them to the system. I'm using Earl Chews estdio
|
|
right now (thanks for a nice and working system Earl), and similar works
|
|
will be very wellcome. Your (C)'s will of course be left intact. Drop me
|
|
a line if you are willing to let me use your code.
|
|
|
|
Linus
|
|
|
|
PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
|
|
"forward error - strawberry unknown domain" or something.
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Beginner asking questions.
|
|
Message-ID: <1991Oct21.184940.27505@klaava.Helsinki.FI>
|
|
Date: 21 Oct 91 18:49:40 GMT
|
|
References: <1991Oct21.154757.9187@convex.com>
|
|
Distribution: comp.os.minix
|
|
Organization: University of Helsinki
|
|
Lines: 29
|
|
|
|
|
|
In article <1991Oct21.154757.9187@convex.com> capps@convex.com (Don Capps) writes:
|
|
>
|
|
> I am new to minix. I am interesting in knowing if a version
|
|
> exists that has pageing and swapping ( For those PC`s with
|
|
> an MMU) ?
|
|
>
|
|
> Thanks ahead of time.
|
|
> capps@orion.convex.com
|
|
|
|
Ok, it is obviously time for a small plug once more :-)
|
|
|
|
There is an experimental FREE minix-like thing which supports paging
|
|
(not yet to disk, but using the MMU to share pages after a fork etc
|
|
etc), written only for 386 AT's. It currently isn't very practical,
|
|
even though a number of people have a running system. It is a bit
|
|
faster than minix (except the floppy-disk driver which really sucks :-).
|
|
|
|
This is a kernel for hackers, so if you aren't one, you'd better wait
|
|
for a later release. If anybody wants to look at the sources, there is
|
|
a version available from 'nic.funet.fi' by anonymous FTP. There are
|
|
also some binaries for the kernel there (gcc, tar, make, uemacs and
|
|
fileutils). All this can be found in /pub/OS/Linux. This version
|
|
currently needs minix-386 to compile (but in a week I'll have a bootable
|
|
version there, I think).
|
|
|
|
Anybody interested can finger me, or mail me for info, or just ftp some
|
|
of the text-files from nic. Word of warning: it needs 4MB to be usable.
|
|
|
|
Linus (torvalds@kruuna.helsinki.fi)
|
|
|
|
==========================
|
|
==========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: [comp.os.minix] Free minix-like kernel sources for 386-AT
|
|
Summary: Still only ftp
|
|
Message-ID: <1991Oct31.101252.13981@klaava.Helsinki.FI>
|
|
Date: 31 Oct 91 10:12:52 GMT
|
|
References: <3255@cluster.cs.su.oz.au> <AA7ig3fuR5@inzer.demos.su>
|
|
Organization: University of Helsinki
|
|
Lines: 50
|
|
|
|
|
|
In article <AA7ig3fuR5@inzer.demos.su> moroz@inzer.demos.su writes:
|
|
>chrisa@extro.ucc.su.OZ.AU (C. G. Albone) writes:
|
|
>>Hello all..
|
|
>> I missed the original posting, so could someone please tell me
|
|
>>how I may obtain the sources.
|
|
> And me too !!!!!!!!!!!!!!
|
|
> Also, are them available via e-mail (mail server or smth), as I'm
|
|
>in the former Soviet Union and can't do any FTP.
|
|
|
|
Ok, as I've gotten quite a few questions, I guess I'd better follow up
|
|
again.
|
|
|
|
Linux is currently ONLY available via ftp from nic.funet.fi, directory
|
|
/pub/OS/Linux. As the sources change rather rapidly (next release due
|
|
out this weekend after I have tested some more), it is also currently
|
|
impractical to make them available from other places. There is a
|
|
mail-server possibility fron nic, but I think it's still in testing (you
|
|
could try mailing "mailserver@nic.funet.fi" with "help" in the body,
|
|
but I don't know if it will work).
|
|
|
|
Linux is a full kernel that has so far worked on a number (5-10?) of
|
|
at-386 (and one 486 as far as I know). It supports GNU cc (gcc), bash
|
|
and some other free stuff. It is currently more of a hackers kernel (and
|
|
minix-386 is needed, but that will change with this weeks release), and
|
|
the current version number is 0.03 (next is 0.10 I think).
|
|
|
|
Good things about linux:
|
|
|
|
- it's free, full source, and I try to correct bugs you find.
|
|
- it's a bit faster than minix, I think.
|
|
- uses paging for memory management (not to disk yet)
|
|
- multithreaded fs (but then you can get patches to minix that do
|
|
similar stuff)
|
|
- mostly full termios and vt100-console.
|
|
- most things easy to port (easier than to minix).
|
|
|
|
Bad points:
|
|
|
|
- ONLY 386/486
|
|
- early versions: there might be lots of bugs, and you might need to
|
|
port/hack things to work.
|
|
- minix is recommended even for the upcoming version that doesn't
|
|
absolutely need it.
|
|
- currently only VGA (EGA?) support, limited keyboard drivers (US and
|
|
Finnish) etc
|
|
|
|
You can mail me for more info. "finger torvalds@kruuna.helsinki.fi"
|
|
might tell you something too.
|
|
|
|
Linus (torvalds@kruuna.helsinki.fi)
|
|
|
|
==============================
|
|
==============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix,comp.binaries.ibm.pc.d,comp.os.coherent,comp.os.mach,comp.os.misc,comp.unix.sysv386,comp.unix.programmers,gnu.misc.discuss
|
|
Subject: Linux information sheet (non-monthly posting)
|
|
Summary: free unix in beta
|
|
Keywords: i386 unix
|
|
Message-ID: <1992Jan9.121044.18825@klaava.Helsinki.FI>
|
|
Date: 9 Jan 92 12:10:44 GMT
|
|
Organization: University of Helsinki
|
|
Lines: 150
|
|
|
|
|
|
|
|
This is a blatant plug for my own unix-like kernel, as I'm
|
|
always interested in more beta-testers. It should be self-explanatory,
|
|
although interested persons should note that version 0.12 (still beta)
|
|
will be out in a week or so. 0.12 will have some additional features,
|
|
most notably:
|
|
|
|
- real paging to/from disk (but gcc is /slow/ on a 2M machine)
|
|
- POSIX job control
|
|
- virtual consoles & pty's
|
|
- some 387-emulation
|
|
|
|
but no, it doesn't do X yet. It looks a lot like minix, if you are
|
|
familiar with that (but much better, of course :).
|
|
|
|
LINUX IS STILL IN BETA!! You are probably not interested in this
|
|
if you only know DOS - it helps /a lot/ if you have managed unix even a
|
|
little: used minix or similar. Reading C-source and understanding what
|
|
happens is another nice ability. Being beta also means it has many
|
|
potential bugs, so watch out (although 0.11 seems to have been
|
|
relatively stable).
|
|
|
|
This information sheet has been compiled by Robert Blum
|
|
(blum@cip-s01.informatik.rwth-aachen.de), but he has problems posting
|
|
it. Questions/suggestions about the SHEET should go to him, about Linux
|
|
either to me or to the mailing-list.
|
|
|
|
Linus (torvalds@kruuna.helsinki.fi)
|
|
|
|
PS. Sorry about the 100+ newsgroups (well, 8 I think) - I'm not certain
|
|
which groups would be best.
|
|
|
|
--------------------------------------------------
|
|
|
|
LINUX INFORMATION SHEET
|
|
(last updated 13 Dec 1991)
|
|
|
|
1. WHAT IS LINUX 0.11
|
|
LINUX 0.11 is a freely distributable UNIX clone. It implements a
|
|
subset of System V and POSIX functionality. LINUX has been written
|
|
from scratch, and therefore does not contain any AT&T or MINIX
|
|
code--not in the kernel, the compiler, the utilities, or the libraries.
|
|
For this reason it can be made available with the complete source code
|
|
via anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting
|
|
to non-Intel architectures is likely to be difficult, as the kernel
|
|
makes extensive use of 386 memory management and task primitives.
|
|
|
|
Version 0.11 is still a beta release, but it already provides much
|
|
of the functionality of a System V.3 kernel. For example, various
|
|
users have been able to port programs such as bison/flex without having
|
|
to modify code at all. Another indication of its maturity is that
|
|
it is now possible to do LINUX kernel development using LINUX itself
|
|
and freely-available programming tools.
|
|
|
|
2. LINUX features
|
|
- System call compatible with a subset of System V and POSIX
|
|
- Full multiprogramming (multiple programs can run at once)
|
|
- Memory paging with copy-on-write
|
|
- Demand loading of executables
|
|
- Page sharing of executables
|
|
- ANSI compliant C compiler (gcc)
|
|
- A complete set of compiler writing tools
|
|
(bison as yacc-replacement, flex as lex replacement)
|
|
- The GNU 'Bourne again' shell (bash)
|
|
- Micro emacs
|
|
- most utilities you need for development
|
|
(cat, cp, kermit, ls, make, etc.)
|
|
- Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.)
|
|
- Currently 4 national keyboards: Finnish/US/German/French
|
|
- Full source code (in C) for the OS is freely distributable
|
|
- Full source code of the tools can be gotten from many anonymous ftp sites
|
|
(Almost the entire suite of GNU programs has been ported to Linux.)
|
|
- Runs in protected mode on 386 and above
|
|
- Support for extended memory up to 16M on 386 and above
|
|
- RS-232 serial line support with terminal emulation, kermit, zmodem, etc.
|
|
- Supports the real time clock
|
|
|
|
|
|
3. HARDWARE REQUIRED
|
|
- A 386 or 486 machine with an AT-bus. (EISA will probably work, also,
|
|
but you will need an AT-bus hard disk controller.)
|
|
Both DX and SX processors will work.
|
|
- A hard disk implementing the standard AT hard disk interface--
|
|
for example, an IDE drive. SCSI drives are not supported yet.
|
|
- A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB).
|
|
- At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use
|
|
gcc at least 4 MB are required.)
|
|
- Any video card of the following: Hercules,CGA,EGA,VGA
|
|
|
|
In addition, LINUX supports
|
|
- Up to two serial lines
|
|
- A real time clock
|
|
|
|
4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.11
|
|
- The MTOOLS package (reading/writing to DOS filesystems)
|
|
- The complete GNU filetools (ls, cat, cp, mv, ...)
|
|
- The GNU C compiler with GNU assembler, linker, ar, ...
|
|
- bison
|
|
- flex
|
|
- rcs
|
|
- pmake (BSD 4.3 Reno/BSD 4.4 make)
|
|
- kermit
|
|
- Micro emacs
|
|
- less
|
|
- mkfs
|
|
- fsck
|
|
- mount/umount
|
|
|
|
|
|
5. LINUX BINARIES
|
|
The LINUX binaries and sources are available at three
|
|
anonymous FTP sites. These are:
|
|
|
|
nic.funet.fi:/pub/OS/Linux
|
|
tsx-11.mit.edu:/pub/linux
|
|
tupac-amaru.informatik.rwth-aachen.de:/pub/msdos/replace
|
|
|
|
|
|
6. LEGAL STATUS OF LINUX
|
|
Although LINUX is supplied with the complete source code, it is
|
|
copyrighted software. Unlike MINIX, however, it is available for free,
|
|
provided you obey to the rules specified in the LINUX copyright.
|
|
|
|
|
|
7. NEWS ABOUT LINUX
|
|
Since LINUX's introduction to the public there has been a rapidly
|
|
growing mailing list, "linux-activists@niksula.hut.fi". To subscribe to
|
|
this list, mail to "linux-activists-requests@niksula.hut.fi". If the
|
|
traffic in this lists increases further, there are plans to swap ( at
|
|
least partially ) over to comp.os.misc, so watch out for any LINUX
|
|
articles in this group. For the current status of LINUX, do "finger
|
|
torvalds@kruuna.helsinki.fi".
|
|
|
|
|
|
8. FUTURE PLANS
|
|
Work is underway on LINUX version 1.0, which will close some of the
|
|
gaps in the present implementation. Various people are currently working
|
|
on:
|
|
- Math support/fp emulation in the kernel
|
|
- Page swapping (since paging is already implemented)
|
|
- A virtual filesystem layer
|
|
- STREAMS
|
|
- POSIX job control (This is already alpha and will probably be
|
|
out with Version 0.12.)
|
|
- init/getty/login
|
|
- symbolic links
|
|
- Interprocess communication
|
|
- IEEE POSIX P1003.1 / P1003.2 compatibility
|
|
- SCSI support
|
|
If you want to help, join the mailing list.
|
|
|
|
========================
|
|
========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Linux
|
|
Message-ID: <1992Jan13.160250.25332@klaava.Helsinki.FI>
|
|
Date: 13 Jan 92 16:02:50 GMT
|
|
References: <1992Jan13.141829.2257@maths.tcd.ie>
|
|
Organization: University of Helsinki
|
|
Lines: 48
|
|
|
|
|
|
Sorry, but this post is too good just to leave hanging around :)
|
|
|
|
In article <1992Jan13.141829.2257@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
|
|
>Is any independent person actually running Linux,
|
|
>and can give an opinion on its merits
|
|
>vis-a-vis 386-Minix?
|
|
|
|
Ok, somebody else should answer this, I can only say that the latest
|
|
count on the activists-list is 196. Some of them are actually using
|
|
linux. Many are just interested, and aren't actually going to use it,
|
|
but there are quite a few that have started making changes and sending
|
|
in patches: About half the new things in 0.12 have been implemented by
|
|
others (job control, ptys, select, and virtual consoles are mostly tthe
|
|
work of others, although I have hcaked them heavily)
|
|
|
|
>While I could be convinced on this,
|
|
>it seems to me pretty unlikely on the face of it
|
|
>that anyone could really write a reliable operating system
|
|
>from scratch in a short time.
|
|
>
|
|
>After all, it took Tanenbaum years to write Minix,
|
|
>and he worked night and day without stop,
|
|
|
|
[ editors note: he probably slept alternate sundays so that he could
|
|
start afresh for next fortnights hacking. ast, can you confirm :-? ]
|
|
|
|
>and had a team working under him too.
|
|
>One only has to look at the sources
|
|
>to see the sheer intellectual work involved
|
|
>in such an enterprise.
|
|
|
|
Are you writing this seriously? There are a lot of smileys missing. The
|
|
reason unix has been so successful is that it's actually a very clean
|
|
and simple operating system. I would seriously doubt anybody will
|
|
implement VMS in a year (or 5, and even after that I wouldn't want to
|
|
actually use it :-)
|
|
|
|
On the off chance that this was a real post, and not just a joke then:
|
|
|
|
yes, linux is a viable alternative to minix-386. Minix has a bigger
|
|
base, and "the book", which are definitive advantages, but if a person
|
|
knows unix a bit, then linux is entirely possible to use. There are
|
|
bugs, and "reliable" might be too strong a word for linux still, but
|
|
most things are easier to do under linux than under minix. Porting is
|
|
much easier (I remember porting bash-1.05 to minix: it wasn't just "make
|
|
and go".)
|
|
|
|
Linus
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: A doubt about Linux
|
|
Message-ID: <1992Jan16.111400.7038@klaava.Helsinki.FI>
|
|
Date: 16 Jan 92 11:14:00 GMT
|
|
References: <1992Jan16.011837.16304@utdallas.edu>
|
|
Organization: University of Helsinki
|
|
Lines: 23
|
|
|
|
|
|
In article <1992Jan16.011837.16304@utdallas.edu> $user@utdallas.edu writes:
|
|
>I remember reading a(may be several) posting that mentions that curently
|
|
>available version of Linux (is it .11)
|
|
[ actually 0.12 is out]
|
|
> does not have init/login. Then am I
|
|
>correct in presuming that I will always be root in Linux. Does this mean that
|
|
>I cannot change my uid and change my previlege level (or is it just that
|
|
>you don't have login/su to do it.). As you can see, I am confused by the real
|
|
>meaning of the phrase "init/login not available".
|
|
|
|
There is no problem with writing a small C-program to change your
|
|
uid/gid - I use one myself (I write 'linus' on the command-line and get
|
|
to be non-supervisor). This after I mistakenly tried to auto-dial my
|
|
harddisk, and trashed a partition as root :)
|
|
|
|
In fact there is now also available a small init/login - I haven't even
|
|
had time to test it myself. I have to admit that all the protection
|
|
features might not work very well: I haven't tested linux very much as
|
|
non-root. Possibly you get to do things you shouldn't or you are unable
|
|
to do things you should be able to do - that's what beta-testing is all
|
|
about (as well as testing the drivers which don't work on all machines).
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Linux-0.11
|
|
Message-ID: <1992Jan20.001203.18340@klaava.Helsinki.FI>
|
|
Date: 20 Jan 92 00:12:03 GMT
|
|
References: <1992Jan13.120357.5333@fel.tno.nl> <1992Jan14.090756.21579@colorado.edu> <sulkanen.695693813@xanth>
|
|
Followup-To: alt.os.linux
|
|
Organization: University of Helsinki
|
|
Lines: 18
|
|
|
|
|
|
In article <sulkanen.695693813@xanth> sulkanen@xanth.msfc.nasa.gov (Martin Sulkanen - NRC/ES65) writes:
|
|
>
|
|
>what are the chances linux will be ported to macintosh?
|
|
|
|
None. Or at least /very/ small. I wrote linux partly to learn the 386
|
|
architecture (and boy did I), so it uses every conceivable feature I
|
|
could find. It is also written in assembler to a greater degree than
|
|
really necessary (I wrote parts of linux defore I fully knew the gcc
|
|
inline assembler syntax, so I wrote more in assembler when I started the
|
|
thing than actually necessary).
|
|
|
|
Also NOTE! I have changed the followup-to to alt.os.linux: comp.os.minix
|
|
isn't the place to discuss linux, and this is absolutely the last post
|
|
I'm going to answer on this forum, as people have been irritated by the
|
|
number of posts. Sorry. For those not able to read the alt-groups, we
|
|
are working on a comp.os.linux, but it will take time.
|
|
|
|
Linus
|
|
|
|
===============================
|
|
===============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: LINUX is obsolete
|
|
Message-ID: <1992Jan29.231426.20469@klaava.Helsinki.FI>
|
|
Date: 29 Jan 92 23:14:26 GMT
|
|
References: <12595@star.cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 91
|
|
|
|
|
|
Well, with a subject like this, I'm afraid I'll have to reply.
|
|
Apologies to minix-users who have heard enough about linux anyway. I'd
|
|
like to be able to just "ignore the bait", but ... Time for some
|
|
serious flamefesting!
|
|
|
|
In article <12595@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
|
|
>
|
|
>I was in the U.S. for a couple of weeks, so I haven't commented much on
|
|
>LINUX (not that I would have said much had I been around), but for what
|
|
>it is worth, I have a couple of comments now.
|
|
>
|
|
>As most of you know, for me MINIX is a hobby, something that I do in the
|
|
>evening when I get bored writing books and there are no major wars,
|
|
>revolutions, or senate hearings being televised live on CNN. My real
|
|
>job is a professor and researcher in the area of operating systems.
|
|
|
|
You use this as an excuse for the limitations of minix? Sorry, but you
|
|
loose: I've got more excuses than you have, and linux still beats the
|
|
pants of minix in almost all areas. Not to mention the fact that most
|
|
of the good code for PC minix seems to have been written by Bruce Evans.
|
|
|
|
Re 1: you doing minix as a hobby - look at who makes money off minix,
|
|
and who gives linux out for free. Then talk about hobbies. Make minix
|
|
freely available, and one of my biggest gripes with it will disappear.
|
|
Linux has very much been a hobby (but a serious one: the best type) for
|
|
me: I get no money for it, and it's not even part of any of my studies
|
|
in the university. I've done it all on my own time, and on my own
|
|
machine.
|
|
|
|
Re 2: your job is being a professor and researcher: That's one hell of a
|
|
good excuse for some of the brain-damages of minix. I can only hope (and
|
|
assume) that Amoeba doesn't suck like minix does.
|
|
|
|
>1. MICROKERNEL VS MONOLITHIC SYSTEM
|
|
|
|
True, linux is monolithic, and I agree that microkernels are nicer. With
|
|
a less argumentative subject, I'd probably have agreed with most of what
|
|
you said. From a theoretical (and aesthetical) standpoint linux looses.
|
|
If the GNU kernel had been ready last spring, I'd not have bothered to
|
|
even start my project: the fact is that it wasn't and still isn't. Linux
|
|
wins heavily on points of being available now.
|
|
|
|
> MINIX is a microkernel-based system. [deleted, but not so that you
|
|
> miss the point ] LINUX is a monolithic style system.
|
|
|
|
If this was the only criterion for the "goodness" of a kernel, you'd be
|
|
right. What you don't mention is that minix doesn't do the micro-kernel
|
|
thing very well, and has problems with real multitasking (in the
|
|
kernel). If I had made an OS that had problems with a multithreading
|
|
filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my
|
|
damndest to make others forget about the fiasco.
|
|
|
|
[ yes, I know there are multithreading hacks for minix, but they are
|
|
hacks, and bruce evans tells me there are lots of race conditions ]
|
|
|
|
>2. PORTABILITY
|
|
|
|
"Portability is for people who cannot write new programs"
|
|
-me, right now (with tongue in cheek)
|
|
|
|
The fact is that linux is more portable than minix. What? I hear you
|
|
say. It's true - but not in the sense that ast means: I made linux as
|
|
conformant to standards as I knew how (without having any POSIX standard
|
|
in front of me). Porting things to linux is generally /much/ easier
|
|
than porting them to minix.
|
|
|
|
I agree that portability is a good thing: but only where it actually has
|
|
some meaning. There is no idea in trying to make an operating system
|
|
overly portable: adhering to a portable API is good enough. The very
|
|
/idea/ of an operating system is to use the hardware features, and hide
|
|
them behind a layer of high-level calls. That is exactly what linux
|
|
does: it just uses a bigger subset of the 386 features than other
|
|
kernels seem to do. Of course this makes the kernel proper unportable,
|
|
but it also makes for a /much/ simpler design. An acceptable trade-off,
|
|
and one that made linux possible in the first place.
|
|
|
|
I also agree that linux takes the non-portability to an extreme: I got
|
|
my 386 last January, and linux was partly a project to teach me about
|
|
it. Many things should have been done more portably if it would have
|
|
been a real project. I'm not making overly many excuses about it
|
|
though: it was a design decision, and last april when I started the
|
|
thing, I didn't think anybody would actually want to use it. I'm happy
|
|
to report I was wrong, and as my source is freely available, anybody is
|
|
free to try to port it, even though it won't be easy.
|
|
|
|
Linus
|
|
|
|
PS. I apologise for sometimes sounding too harsh: minix is nice enough
|
|
if you have nothing else. Amoeba might be nice if you have 5-10 spare
|
|
386's lying around, but I certainly don't. I don't usually get into
|
|
flames, but I'm touchy when it comes to linux :)
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Apologies (was Re: LINUX is obsolete)
|
|
Message-ID: <1992Jan30.153816.1901@klaava.Helsinki.FI>
|
|
Date: 30 Jan 92 15:38:16 GMT
|
|
References: <12595@star.cs.vu.nl> <1992Jan29.231426.20469@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
Lines: 12
|
|
|
|
|
|
In article <1992Jan29.231426.20469@klaava.Helsinki.FI> I wrote:
|
|
>Well, with a subject like this, I'm afraid I'll have to reply.
|
|
|
|
And reply I did, with complete abandon, and no thought for good taste
|
|
and netiquette. Apologies to ast, and thanks to John Nall for a friendy
|
|
"that's not how it's done"-letter. I over-reacted, and am now composing
|
|
a (much less acerbic) personal letter to ast. Hope nobody was turned
|
|
away from linux due to it being (a) possibly obsolete (I still think
|
|
that's not the case, although some of the criticisms are valid) and (b)
|
|
written by a hothead :-)
|
|
|
|
Linus "my first, and hopefully last flamefest" Torvalds
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: LINUX is obsolete
|
|
Message-ID: <1992Jan31.103323.29629@klaava.Helsinki.FI>
|
|
Date: 31 Jan 92 10:33:23 GMT
|
|
References: <12595@star.cs.vu.nl> <1992Jan29.231426.20469@klaava.Helsinki.FI> <12615@star.cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 68
|
|
|
|
|
|
In article <12615@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
|
|
>The limitations of MINIX relate at least partly to my being a professor:
|
|
>An explicit design goal was to make it run on cheap hardware so students
|
|
>could afford it.
|
|
|
|
All right: a real technical point, and one that made some of my comments
|
|
inexcusable. But at the same time you shoot yourself in the foot a bit:
|
|
now you admit that some of the errors of minix were that it was too
|
|
portable: including machines that weren't really designed to run unix.
|
|
That assumption lead to the fact that minix now cannot easily be
|
|
extended to have things like paging, even for machines that would
|
|
support it. Yes, minix is portable, but you can rewrite that as
|
|
"doesn't use any features", and still be right.
|
|
|
|
>A multithreaded file system is only a performance hack.
|
|
|
|
Not true. It's a performance hack /on a microkernel/, but it's an
|
|
automatic feature when you write a monolithic kernel - one area where
|
|
microkernels don't work too well (as I pointed out in my personal mail
|
|
to ast). When writing a unix the "obsolete" way, you automatically get
|
|
a multithreaded kernel: every process does it's own job, and you don't
|
|
have to make ugly things like message queues to make it work
|
|
efficiently.
|
|
|
|
Besides, there are people who would consider "only a performance hack"
|
|
vital: unless you have a cray-3, I'd guess everybody gets tired of
|
|
waiting on the computer all the time. I know I did with minix (and yes,
|
|
I do with linux too, but it's /much/ better).
|
|
|
|
>I still maintain the point that designing a monolithic kernel in 1991 is
|
|
>a fundamental error. Be thankful you are not my student. You would not
|
|
>get a high grade for such a design :-)
|
|
|
|
Well, I probably won't get too good grades even without you: I had an
|
|
argument (completely unrelated - not even pertaining to OS's) with the
|
|
person here at the university that teaches OS design. I wonder when
|
|
I'll learn :)
|
|
|
|
>My point is that writing a new operating system that is closely tied to any
|
|
>particular piece of hardware, especially a weird one like the Intel line,
|
|
>is basically wrong.
|
|
|
|
But /my/ point is that the operating system /isn't/ tied to any
|
|
processor line: UNIX runs on most real processors in existence. Yes,
|
|
the /implementation/ is hardware-specific, but there's a HUGE
|
|
difference. You mention OS/360 and MS-DOG as examples of bad designs
|
|
as they were hardware-dependent, and I agree. But there's a big
|
|
difference between these and linux: linux API is portable (not due to my
|
|
clever design, but due to the fact that I decided to go for a fairly-
|
|
well-thought-out and tested OS: unix.)
|
|
|
|
If you write programs for linux today, you shouldn't have too many
|
|
surprises when you just recompile them for Hurd in the 21st century. As
|
|
has been noted (not only by me), the linux kernel is a miniscule part of
|
|
a complete system: Full sources for linux currently runs to about 200kB
|
|
compressed - full sources to a somewhat complete developement system is
|
|
at least 10MB compressed (and easily much, much more). And all of that
|
|
source is portable, except for this tiny kernel that you can (provably:
|
|
I did it) re-write totally from scratch in less than a year without
|
|
having /any/ prior knowledge.
|
|
|
|
In fact the /whole/ linux kernel is much smaller than the 386-dependent
|
|
things in mach: i386.tar.Z for the current version of mach is well over
|
|
800kB compressed (823391 bytes according to nic.funet.fi). Admittedly,
|
|
mach is "somewhat" bigger and has more features, but that should still
|
|
tell you something.
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Unhappy campers
|
|
Message-ID: <1992Feb6.103331.19702@klaava.Helsinki.FI>
|
|
Date: 6 Feb 92 10:33:31 GMT
|
|
References: <12667@star.cs.vu.nl> <205@fishpond.uucp> <12746@star.cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 75
|
|
|
|
|
|
In article <12746@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
|
|
>
|
|
>If Linus wants to keep control of the official version, and a group of eager
|
|
>beavers want to go off in a different direction, the same problem arises.
|
|
|
|
This is the second time I've seen this "accusation" from ast, who feels
|
|
pretty good about commenting on a kernel he probably haven't even seen.
|
|
Or at least he hasn't asked me, or even read alt.os.linux about this.
|
|
Just so that nobody takes his guess for the full thruth, here's my
|
|
standing on "keeping control", in 2 words (three?):
|
|
|
|
I won't.
|
|
|
|
The only control I've effectively been keeping on linux is that I know
|
|
it better than anybody else, and I've made my changes available to
|
|
ftp-sites etc. Those have become effectively official releases, and I
|
|
don't expect this to change for some time: not because I feel I have
|
|
some moral right to it, but because I haven't heard too many complaints,
|
|
and it will be a couple of months before I expect to find people who
|
|
have the same "feel" for what happens in the kernel. (Well, maybe
|
|
people are getting there: tytso certainly made some heavy changes even
|
|
to 0.10, and others have hacked it as well)
|
|
|
|
In fact I have sent out feelers about some "linux-kernel" mailing list
|
|
which would make the decisions about releases, as I expect I cannot
|
|
fully support all the features that will /have/ to be added: SCSI etc,
|
|
that I don't have the hardware for. The response has been non-existant:
|
|
people don't seem to be that eager to change yet. (well, one person
|
|
felt I should ask around for donations so that I could support it - and
|
|
if anybody has interesting hardware lying around, I'd be happy to accept
|
|
it :)
|
|
|
|
The only thing the copyright forbids (and I feel this is eminently
|
|
reasonable) is that other people start making money off it, and don't
|
|
make source available etc... This may not be a question of logic, but
|
|
I'd feel very bad if someone could just sell my work for money, when I
|
|
made it available expressly so that people could play around with a
|
|
personal project. I think most people see my point.
|
|
|
|
That aside, if Fred van Kempen wanted to make a super-linux, he's quite
|
|
wellcome. He won't be able to make much money on it (distribution fee
|
|
only), and I don't think it's that good an idea to split linux up, but I
|
|
wouldn't want to stop him even if the copyright let me.
|
|
|
|
>I don't think the copyright issue is really the problem. The problem is
|
|
>co-ordinating things. Projects like GNU, MINIX, or LINUX only hold together
|
|
>if one person is in charge.
|
|
|
|
Yes, coordination is a big problem, and I don't think linux will move
|
|
away from me as "head surgeon" for some time, partly because most people
|
|
understand about these problems. But copyright /is/ an issue: if people
|
|
feel I do a bad job, they can do it themselves. Likewise with gcc. The
|
|
minix copyright, however, means that if someone feels he could make a
|
|
better minix, he either has to make patches (which aren't that great
|
|
whatever you say about them) or start off from scratch (and be attacked
|
|
because you have other ideals).
|
|
|
|
Patches aren't much fun to distribute: I haven't made cdiffs for a
|
|
single version of linux yet (I expect this to change: soon the patches
|
|
will be so much smaller than the kernel that making both patches and a
|
|
complete version available is a good idea - note that I'd still make the
|
|
whole version available too). Patches upon patches are simply
|
|
impractical, especially for people that may do changes themselves.
|
|
|
|
>>Where is the sizeable group of people that want to evolve gcc in a way that
|
|
>>rms/FSF does not approve of?
|
|
>A compiler is not something people have much emotional attachment to. If
|
|
>the language to be compiled is a given (e.g., an ANSI standard), there isn't
|
|
>much room for people to invent new features. An operating system has unlimited
|
|
>opportunity for people to implement their own favorite features.
|
|
|
|
Well, there's GNU emacs... Don't tell us people haven't got emotional
|
|
attachment to editors :)
|
|
|
|
Linus
|
|
|
|
==============================
|
|
==============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: MInix386 > Linux0.95c+
|
|
Message-ID: <1992Apr27.090224.25223@klaava.Helsinki.FI>
|
|
Date: 27 Apr 92 09:02:24 GMT
|
|
References: <1992Apr23.082847.13947@ntuix.ntu.ac.sg>
|
|
Organization: University of Helsinki
|
|
Lines: 43
|
|
|
|
|
|
In article <1992Apr23.082847.13947@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
|
|
>I had just tried Linux 0.95c+ for a few minutes. I was not impressed.
|
|
|
|
Well, maybe it takes time to see all the good points... :)
|
|
|
|
> The much acclaimed virtual memory was not possible because I do not
|
|
>have a partition for testing the swapon. I only have 4 partitions. 2 for DOS.
|
|
>1 for Minix 16 bit.
|
|
|
|
You can also use a swap-file: it's a bit slower, but most people seem to
|
|
prefer it due to ease of setting up and size changes.
|
|
|
|
> The multi-threaded file system is not apparent as I do not detect any
|
|
>speed improvement. I only test it for a few minutes. I had not downloaded
|
|
>software.
|
|
|
|
Minix is in fact faster on some things: the minix harddisk driver has
|
|
been hacked heavily (mainly thanks to bruce evans I think) for
|
|
perfomance to overcome the single-threading. Linux has no speed hacks:
|
|
it depends solely on the cleaner interface, and even so it's in the same
|
|
class and sometimes noticeably faster than minix.
|
|
|
|
> Linux does not have debuggers yet which is a serious limitation.
|
|
>From the alt.os.linux, there are complaints that with swapping on, the system
|
|
>becomes too slow.
|
|
|
|
Surprise surprise: swapping slows down your machine... Try running gcc
|
|
under minix in 2MB and see what happens. Even with 4MB gcc-2.1 can
|
|
seriously deplete you memory, and swapping is your only way out.
|
|
|
|
Also, linux does have a debugger: gdb-4.5 (the newest version) works ok
|
|
with the new kernel. I've had no problems at all, although the lack of
|
|
core-dumps is a minor irritation.
|
|
|
|
> I do not need virtual memory because I have 8 Mbyte or 16 Mbyte
|
|
> but I need shared text which I have not managed to install to my
|
|
> Minix386 yet.
|
|
|
|
Well, with X (already working, but not available for "the masses") even
|
|
8MB is pretty small. minix-386 has been available for a /long/ time, but
|
|
nobody even tried to port X - and don't tell me it was lack of interest.
|
|
|
|
Linus
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: minix kernel structure
|
|
Message-ID: <1992Jun25.093528.5468@klaava.Helsinki.FI>
|
|
Date: 25 Jun 92 09:35:28 GMT
|
|
References: <1992Jun24.121431.22027@philce.ce.philips.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 38
|
|
|
|
|
|
In article <1992Jun24.121431.22027@philce.ce.philips.nl> meulenbr@ce.philips.nl (Frans Meulenbroeks) writes:
|
|
|
|
[ good things deleted ]
|
|
|
|
>This core should have the following functions:
|
|
>- context switching
|
|
>- message passing
|
|
>- basic clock handling
|
|
>- memory copying between tasks
|
|
>- support for interrupt handling
|
|
>- creation and removal of processes.
|
|
>- system call dispatching (perhaps this should be done by a special task)
|
|
|
|
Everything you said sounds very reasonable, but I'd suggest
|
|
|
|
(a) no memory copying between tasks: messages should be used instead
|
|
(b) add mm primitives to the core (get_area, map_area, umap_area etc)
|
|
|
|
(a) is pretty clear: the current minix memory-copy function is horrible,
|
|
and shouldn't work in a real microkernel.
|
|
|
|
(b) shouldn't be a memory-management server, but instead support the
|
|
paging etc hardware. That means giving processes controlled access to
|
|
the page tables (via messages) and send out messages to the processes
|
|
depending on page faults etc. The real mm process would use this to
|
|
implement demand-paging etc, but the core itself should do the
|
|
nitty-gritty details.
|
|
|
|
(b) should also let processes add their own page-fault handlers and
|
|
such, mapping in new memory and initializing it as they wish etc.
|
|
|
|
And I think system call dispatching shouldn't be done by the core, but
|
|
by a special server. I'd also suggest adding threading support: the fs
|
|
and mm processes need to be multithreaded (or page faults etc are very
|
|
difficult indeed to handle, as a page-fault can happen in the fs process
|
|
and often needs the fs process to be handled).
|
|
|
|
Linus
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: minix kernel structure
|
|
Message-ID: <1992Jun26.180727.15763@klaava.Helsinki.FI>
|
|
Date: 26 Jun 92 18:07:27 GMT
|
|
References: <1992Jun24.121431.22027@philce.ce.philips.nl> <1992Jun25.093528.5468@klaava.Helsinki.FI> <meulenbr.709566703@cstw18>
|
|
Organization: University of Helsinki
|
|
Lines: 120
|
|
|
|
|
|
In article <meulenbr.709566703@cstw18> meulenbr@prl.philips.nl (Frans Meulenbroeks) writes:
|
|
>torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
|
|
>
|
|
>>(a) no memory copying between tasks: messages should be used instead
|
|
>
|
|
>Yes, you are right. However, there are a few cases where you want to
|
|
>pass more data than fit in a message. You could pass a pointer into the
|
|
>message, but you cannot use it in another program if you have memory
|
|
>management.
|
|
|
|
The idea should be that messages can have any length, and the
|
|
message-passing code in the kernel does the copying. Thus a read() or
|
|
something would be implemented like this:
|
|
|
|
- user process sends a message to the fs process (possibly going through
|
|
a system call server) that requests a read(). This message wouldn't
|
|
even contain the buffer address, just which file and how much you want
|
|
to read.
|
|
|
|
- the user process does a receive() and blocks. This receive is what
|
|
contains the address to be copied to.
|
|
|
|
- the fs process responds with a message that contains the data. The fs
|
|
doesn't even know where the data goes to, it just replies to a request,
|
|
and the message-passing code automatically copies the data to the right
|
|
place (as it knows where the process expects it due to the receive).
|
|
|
|
Fixed-size messages are a pain, and should be banned: you lose most of
|
|
the nice properties of messages that way.
|
|
|
|
> > [mm in the core]
|
|
>
|
|
>This is maybe also a good idea. I should think about it some more.
|
|
>However, I think that the original proposal is already enough work
|
|
>without this added. Better first get the original proposal implemented.
|
|
>Later on we can discuss how mm should be.
|
|
|
|
Yes, you definitely have enough to do even without my suggestions. I
|
|
still think that even without paging, you should have the low-level
|
|
memory management routines in the core, and if you want a mm process, it
|
|
shouldn't be able to claim memory left and right. I think even amoeba
|
|
has the memory-management in the kernel (Andy?). Then having a mm
|
|
process that does the more high-level things (like actually loading
|
|
executables etc) is a good idea.
|
|
|
|
>A system call server sounds like a very good idea to me. In fact I have
|
|
>already been thinking about it. I'm tempted to keep the proposal as
|
|
>small as possible, so for the time being I have left it out. To me
|
|
>however this would be one of the first things to add after implementing
|
|
>my proposal.
|
|
|
|
I'd suggest that you'd implement some kind of message redirection, so
|
|
that the system call server wouldn't have to direct messages both ways.
|
|
For example, a read() system call might happen something like this with
|
|
a redirecting syscall handler:
|
|
|
|
(a) User does a send-receive to the system call handler
|
|
(b) the syscall handler decides which process to redirect the message
|
|
to.
|
|
(c) the fs process (which got the redirected message) decides which
|
|
handler process (eg the tty process) and redirects it to that
|
|
process.
|
|
(d) the tty process replies to the message directly to the user process
|
|
due to the redirection.
|
|
|
|
Note that without redirection, a lot more messages need to be passed
|
|
(tty process replies to fs process which replies to syscall handler
|
|
which replies to the user process), which means the system is doing a
|
|
lot of context switches. With redirection you can sometimes get only
|
|
half the number of messages, and it might mean that things like the
|
|
system call handler wouldn't have to be multithreaded as it can do any
|
|
requests without blocking.
|
|
|
|
>My thoughts about multithreading are mixed.
|
|
>On the one side I like the performance gain. On the other hand this
|
|
>complicates things, so it does not really fit into the minix scope.
|
|
|
|
Multi-threading isn't a question of performance: you generally get
|
|
better performance too, but the most important part is that some things
|
|
are impossible or much more complicated without multithreading. I
|
|
already mentioned demand-paging and virtual memory that effectively
|
|
/need/ multithreading, but some other quite mundane things are simply
|
|
not possible to do without it.
|
|
|
|
The filesystem simply /has/ to be multithreaded or you need a lot of
|
|
ugly hacks. Look at the tty code in the minix fs: it's not exactly
|
|
logical or nice. As a tty request can take a long time, minix has to do
|
|
small ugly hacks to free the fs process as fast as possible so that it
|
|
can do some other request while the tty is hanging. It does a messy
|
|
kind of message redirection, but it's really rather nasty (as the
|
|
redirection isn't a kernel primitive, but an ugly hack to get this
|
|
particular problem solved).
|
|
|
|
Not having multithreading also results in the fact that the system tasks
|
|
cannot send each other messages freely: you have to be very careful that
|
|
there aren't dead-locks where different system calls try to send each
|
|
other messages. Ugly. Having multithreaded system tasks would make a
|
|
lot of things cleaner (I don't think user tasks need to be able to
|
|
multithread, but if the kernel supports it for system tasks, it might as
|
|
well work for user tasks as well).
|
|
|
|
So while it's true that multithreading actually results in a performance
|
|
increase, that is /not/ the most important reason to implement it. It's
|
|
just another good point.
|
|
|
|
Note that the above arguments are just (a) personal opinions (b) what I
|
|
consider to be a "clean" system [*]. Obviously you can have a message-
|
|
passing fs that isn't multithreaded (as in the current minix
|
|
implementation), but my point is that it leads to ugly hacks and removes
|
|
a lot of the good points of messages. What's the idea in using minix as
|
|
a teaching tool if it does some fundamentally buggy things?
|
|
|
|
Linus
|
|
|
|
[*] I know people might not consider linux "clean", but it is: it does
|
|
what it set out to do cleanly and well. I find minix irritating in that
|
|
it considers itself a good system, but is so badly implemented that all
|
|
the good points drown in the hacks needed to get it going. (Don't flame
|
|
me too badly for that last comment: I'm just drivig in the point as I
|
|
see it.)
|
|
|
|
=========================
|
|
=========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.coherent,comp.os.minix
|
|
Subject: Re: OS compare (Unix/clone)
|
|
Message-ID: <1992Jul29.172406.29587@klaava.Helsinki.FI>
|
|
Date: 29 Jul 92 17:24:06 GMT
|
|
References: <PETRI.VIRKKULA.92Jul27231025@vipunen.hut.fi> <1992Jul28.154817.5839@mtu.edu> <PETRI.VIRKKULA.92Jul29191611@vipunen.hut.fi>
|
|
Organization: University of Helsinki
|
|
Lines: 40
|
|
|
|
|
|
In article <PETRI.VIRKKULA.92Jul29191611@vipunen.hut.fi> Petri.Virkkula@hut.fi (Petri Virkkula) writes:
|
|
>
|
|
> Haven't I understood something correctly? Isn't it possible to
|
|
> swap segments to disk using Valid and Accessed flags in
|
|
> segment descriptors?
|
|
|
|
Yes, it's certainly possible, but it's also almost never worth the
|
|
bother: it's slow, hard to program, and writing a C-compiler (and
|
|
probably any other language) to understand several segments while still
|
|
being efficient is pretty hard. And having just one code-segment and
|
|
one data (and stack) segment is simply not enough for a lot of
|
|
interesting applications.
|
|
|
|
Having several different code/date-segments doesn't lend itself very
|
|
well to high-level languages (it doesn't even work too well in assembly,
|
|
but there the programmer often knows what he/she is doing). Thus
|
|
coherent 3.2 and minix don't even try: they keep to one segment, and
|
|
limit all data to 64kB. You can do a lot in 64kB, but I'd rather miss
|
|
the experience.
|
|
|
|
OS/2 1.x tried to implement a "real" system on a 286, and while some
|
|
people think it worked well, most people (including the OS/2 2.0
|
|
designers) seem to agree that the 286 protected mode memory management
|
|
is simply not enough for any good real system. Of course, you can still
|
|
use them for DOS or some other embedded system (a toaster, washing
|
|
machine etc).
|
|
|
|
That doesn't mean the 386 is perfect: it has got it's own number of
|
|
idiocyncracies (especially when used in AT hardware). But at least you
|
|
don't have to fight the hardware all the way if you want to do something
|
|
bigger on a 386.
|
|
|
|
Linus
|
|
|
|
PS. "Being able to" and "suitable for" are totally different things:
|
|
you can write a fully multitasking VM system with 32-bit pointers on a
|
|
Z80 (for example by writing a 386 (or why not a cray-XMP?) emulator on
|
|
it), and all general-purpose processors are theoretically able to solve
|
|
the same set of problems. Thus even a lowly 286 can provably do the
|
|
same things a 386 does. It's just not worth it in most cases.
|
|
|
|
========================
|
|
========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: GNU-C recompiled minix wanted
|
|
Message-ID: <1992Sep3.122349.16731@klaava.Helsinki.FI>
|
|
Date: 3 Sep 92 12:23:49 GMT
|
|
References: <1992Sep3.103808.12710@mnemosyne.cs.du.edu>
|
|
Organization: University of Helsinki
|
|
Lines: 22
|
|
|
|
|
|
In article <1992Sep3.103808.12710@mnemosyne.cs.du.edu> vromano@nyx.cs.du.edu (Vincenzo Romano) writes:
|
|
>I'm looking for a copy of the Minix Operating System recompiled by using
|
|
>the GNU-C compiler. I already own the Minix 1.5 but I'm sure that on my
|
|
>386sx machine such a recompiled OS should be faster, isn't it?
|
|
>
|
|
>Can anyone help me? Can anyone tell me where I can FTP this OS or, at least
|
|
>a pre-compiled minix port of the GNU-C?
|
|
|
|
As far as I know, there is no gcc-compiled version of PC-minix
|
|
available. Gcc won't even run on the basic minix setup: you have to
|
|
upgrade to 386-minix by Bruce Evans (this is a good idea anyway, as it
|
|
allows you to run other programs that won't work under normal minix
|
|
otherwise). The 386-patches are available (or were when I got them) at
|
|
least from plains.nodak.edu, (/pub/minix/oz/ I think).
|
|
|
|
If you don't have to run minix, you could be better off trying out linux
|
|
or 386bsd instead: they give you everything minix does and then some
|
|
(and is compiled using gcc). For good performance you need at least 4MB
|
|
of memory, though, or you'll swap your brains out trying to run all the
|
|
GNU software. Read comp.os.linux/comp.unix.bsd for additional info.
|
|
|
|
Linus
|
|
|
|
===============================
|
|
===============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: (none given)
|
|
Message-ID: <1992Sep11.120003.27063@klaava.Helsinki.FI>
|
|
Date: 11 Sep 92 12:00:03 GMT
|
|
References: <ETLMIKE.92Sep10173232@jerry.ericsson.se> <1992Sep11.093444.223@email.tuwien.ac.at> <ETLMIKE.92Sep11121917@jerry.ericsson.se>
|
|
Organization: University of Helsinki
|
|
Lines: 35
|
|
|
|
|
|
[ egg on my face - I didn't think a gcc-compiled minix existed at all.
|
|
Btw, did you rewrite all the .x files in gas syntax, or are you using
|
|
some weird combination of gcc/bcc/bas? ]
|
|
|
|
In article <ETLMIKE.92Sep11121917@jerry.ericsson.se> etlmike@jerry.ericsson.se (Mike Wilcox) writes:
|
|
>
|
|
>Hmmm - it is very slow when no options are used. I have many
|
|
>screenful's of benchmark speeds with the kernel compiled with
|
|
>different compilers, and different options (especially to GCC).
|
|
>Also with different speeds for different versions of GCC!
|
|
>
|
|
>I think best compilation is with -O -fomit-frame-pointer
|
|
>-fstrength-reduce -fcombine-regs.
|
|
|
|
You might also try gcc-2.2.2, which gives some noticeable speed
|
|
increases under some circumstances (notably floating-point which is
|
|
essentially useless under minix unless you have patched that too, but
|
|
integer performance is also better).
|
|
|
|
>I seem to remember that using -finline-functions actually made things
|
|
>worse. If anyone can explain THAT one to me, I'd be grateful!
|
|
|
|
This could be related to the general gcc speed decrease: has the kernel
|
|
by any chance grown noticeably? -finline-functions (and some other
|
|
options line -fstrength-reduce, -m486) can make the executable image
|
|
noticeably bigger. In general, gcc doesn't even try to make things
|
|
small, and binaries compiled with gcc can be bigger than those of other
|
|
compilers.
|
|
|
|
Size is normally not a problem, but if your minix has buffer-size
|
|
limitations (low 1MB or similar - I know the version I used had that
|
|
limit), over-all performance can go down due to much smaller buffer
|
|
space.
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Linux?
|
|
Message-ID: <1992Sep21.123312.27713@klaava.Helsinki.FI>
|
|
Date: 21 Sep 92 12:33:12 GMT
|
|
References: <1992Sep21.110338.21830@udel.edu>
|
|
Followup-To: comp.os.linux
|
|
Organization: University of Helsinki
|
|
Lines: 60
|
|
|
|
|
|
In article <1992Sep21.110338.21830@udel.edu> S90405184@hsepm1.hse.nl writes:
|
|
>
|
|
>Can smebody, in a few wrds, tell me wha linux is?
|
|
>I've seen it mentined in info minix a few times.
|
|
|
|
[ This should be in comp.os.linux - see the Follow-Up. If you have
|
|
c.o.minix, but not c.o.linux, you should contact your newsfeed
|
|
administrator ]
|
|
|
|
Linux is a unix-like OS for the 386 - it's *not* available for any other
|
|
architecture (and it currently doesn't work even on PS/2 (ie MCA)
|
|
machines). Like minix, it comes with full source code, and is
|
|
copyrighted. Unlike minix, it's freely re-distributable under the GNU
|
|
copyleft (ie it doesn't cost you anything if you have ftp access).
|
|
|
|
Linux has some ties the the minix community: I originally used minix for
|
|
linux developement, and the standard filesystem is still mostly
|
|
compatible with the original minix fs (ie you can mount the same
|
|
partitions both from minix and linux). That's about the only thing
|
|
minix/linux have in common any more, but it may make a transition
|
|
easier.
|
|
|
|
The best way to get a picture of linux is probably to read comp.os.linux
|
|
for a while, and/or ftp to 'tsx-11.mit.edu' (pub/linux) or
|
|
'nic.funet.fi' (pub/OS/Linux) and try it out. Documentation isn't too
|
|
hot (if you are timid about that, you should probably get minix or
|
|
coherent), but it's possible to set up a linux system even with very
|
|
limited unix knowledge.
|
|
|
|
Linux runs in full 32-bit protected mode, giving each process a 3GB
|
|
process space (1GB used for virtual kernel memory). It supports paging
|
|
to disk, shared libraries etc, and runs about everything from gcc to
|
|
X11r5. 2MB physical RAM minimum, with >=4MB preferred for good
|
|
performance.
|
|
|
|
Linux supports virtual filesystems: the standard kernel understands the
|
|
minix fs, DOS disks (non-stacked), and a ext-fs format, giving 255 char
|
|
character names and bigger partitions than the minix format. There are
|
|
also patches for a xenix-filesystem mode as well as for actual emulation
|
|
of some xenix binaries (but this isn't part of the standard kernel).
|
|
|
|
Additional patches include tcp/ip (which will be in the next major
|
|
release, probably next week), a soundblaster driver and a CDROM fs.
|
|
There is some work going on to use linux as the base for the FSF
|
|
single-server (ie not Hurd, but a simpler unix-server) on top of
|
|
mach-3.0, but this is so far only in it's infancy. Additional info from
|
|
the newsgroup and ftp-sites.
|
|
|
|
I'd also suggest you check out "comp.os.coherent" and "comp.unix.bsd"
|
|
for other alternatives to DOS - while I obviously think linux is the
|
|
best of minix/linux/coherent/386bsd, there are those who disagree:
|
|
|
|
Minix is good for education (source, the book), coherent for simpler
|
|
home use (easier installation, manual), linux for hacking (source,
|
|
completeness) and 386bsd for people who simply want "the real McCoy"
|
|
(source, compatibility). Linux and 386bsd are both freely
|
|
distributable, although under different conditions, while minix and
|
|
coherent are commercial (although cheap: $169 v $99 USD).
|
|
|
|
Linus
|
|
|
|
=========================
|
|
=========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: source code to standard library functions
|
|
Message-ID: <1992Oct1.185039.14249@klaava.Helsinki.FI>
|
|
Date: 1 Oct 92 18:50:39 GMT
|
|
References: <9929@kralizec.zeta.org.au>
|
|
Organization: University of Helsinki
|
|
Lines: 18
|
|
|
|
|
|
In article <9929@kralizec.zeta.org.au> craig@kralizec.zeta.org.au (Craig Dewick) writes:
|
|
>
|
|
>I'm trying to get access to the source code of the standard library functions
|
|
>provided with Unix/Minix/etc., but so far I've had no luck.
|
|
>
|
|
>Is is possible to gain access to source for these functions somewhere?
|
|
|
|
If you have no problems with the GNU copyleft, I'd suggest you take a
|
|
look at the GNU libc.a replacement. It's starting to get pretty
|
|
complete and working, and you should be able to find it on most bigger
|
|
ftp-sites that carry GNU software (the only one I know about is at
|
|
nic.funet.fi: pub/gnu/glibc-1.05.tar.Z, but you should be able to find
|
|
something nearer).
|
|
|
|
You'd probably have to hack on it some, but at least it's a starting
|
|
point.
|
|
|
|
Linus
|
|
|
|
==============================
|
|
==============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Dynamically Linked Libraries?
|
|
Message-ID: <1992Oct16.152838.2655@klaava.Helsinki.FI>
|
|
Date: 16 Oct 92 15:28:38 GMT
|
|
References: <1992Oct16.132202.892@udel.edu> <1992Oct16.140510.25779@mnemosyne.cs.du.edu>
|
|
Organization: University of Helsinki
|
|
Lines: 35
|
|
|
|
|
|
In article <1992Oct16.140510.25779@mnemosyne.cs.du.edu> hpoe@nyx.cs.du.edu (Howard Poe) writes:
|
|
>Glen Cornell <gcornell%core1@kssib.ksc.nasa.gov> writes:
|
|
>>
|
|
>>AmigaDOS, as well as MS-Windows, provide the capability of linking
|
|
>>object code to a program at run-time.
|
|
>>
|
|
>>How does an OS dynamically link object code? Is it taken care of in
|
|
>>the kernel?
|
|
>>Is it possible for an OS like MINIX or UNIX to have this capability?
|
|
>
|
|
>Linux now uses a similar scheme for linking object files at runtime.
|
|
>Maybe you can check it out.
|
|
|
|
Yes, linux has shared libraries (X is a pain without them - both in
|
|
memory and disk usage), but it's not actually done using dynamic
|
|
linking, but by a simpler scheme which essentially just mmap()'s the
|
|
library at a hardcoded address. This is fine and works, but if you
|
|
really want dynamic linking (not that I see why), you'll have to look
|
|
elsewhere. They were talking about it over in comp.os.bsd for 386bsd -
|
|
I don't know if anything got decided (using hardcoded addresses and
|
|
jump-tables like under linux, or doing truly dynamic libraries both have
|
|
their good and bad sides).
|
|
|
|
As to how dynamic linking is done - it can be done totally in user space
|
|
(essentially just running 'ld' on the binary at startup or by having
|
|
stub functions that load in the library when they get called), but for
|
|
good performance you would probably want kernel support (in order to be
|
|
able to share pages between different invocations of the same library
|
|
etc). Getting dynamic linking right seemed too hairy for the good
|
|
points it offers, so linux went with the simpler scheme where all the
|
|
work is done at library creation time. This may be slightly less
|
|
flexible, but it's much easier (and it does have some other good points
|
|
too).
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: NNTP under MINIX
|
|
Message-ID: <1992Oct30.161022.19335@klaava.Helsinki.FI>
|
|
Date: 30 Oct 92 16:10:22 GMT
|
|
References: <1992Oct29.081417.1951@udel.edu> <klamer.720431886@mi.el.utwente.nl> <BwxHyK.57y@cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 28
|
|
|
|
|
|
In article <BwxHyK.57y@cs.vu.nl> philip@cs.vu.nl (Philip Homburg) writes:
|
|
>In article <klamer.720431886@mi.el.utwente.nl> klamer@mi.el.utwente.nl (Klamer Schutte) writes:
|
|
>%Three certainly are enough? Things like TCP/IP is needed for minix to
|
|
>%keep up with other UNIX flavours. Now somebody who:
|
|
>% 1) NFS running ;-)
|
|
>
|
|
>An NFS server is no problem (the v2 filesystem can even store a 32 bit
|
|
>protection key in the inode). An NFS client that can be mounted (apposed to
|
|
>a user level shell like ftp) will be very hard.
|
|
|
|
The server just needs tcp/ip - the nfs client needs a *lot* of rewriting
|
|
in the minix fs and might be more trouble than it's worth. You'd
|
|
essentially need a vfs layer to take care of different types of
|
|
filesystems, and I don't think this is supported even with the new
|
|
kernels can handle different fs's (I assume the new minix fs isn't
|
|
really NEW - I guess it's only a case of extending the inode and block
|
|
nr fields).
|
|
|
|
>% 2) get X11 running ;-)
|
|
>
|
|
>Also not very hard, just a lot of work. Infact I know a minix system that
|
|
>runs X11R5 clients over TCP/IP :-)
|
|
|
|
Yours? Again, the *real* fun comes in when you can run the X11 server on
|
|
the system. After all, most minix machines probably don't have a X
|
|
terminal or Sun hooked up to them..
|
|
|
|
Linus "yes, linux does it all" Torvalds
|
|
|
|
===========================
|
|
===========================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: Is MINIX much better than LINUX?
|
|
Message-ID: <1992Dec12.090926.28084@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <1992Dec12.034538.14723@netcom.com>
|
|
Date: Sat, 12 Dec 1992 09:09:26 GMT
|
|
Lines: 75
|
|
|
|
|
|
In article <1992Dec12.034538.14723@netcom.com> sjs@netcom.com (Stephen Schow) writes:
|
|
>I need some reasons for buying minix versus just getting linux for free.
|
|
>Anyone got any concrete ones. I won't really be doing any commercial things.
|
|
>I just want to get through my BSCS, where all of our programming has to be
|
|
>on UNIX machines.
|
|
|
|
Can't pass on this one... The simple answer is a resounding NO.
|
|
|
|
There are two circumstances when you may find minix better:
|
|
|
|
- studies with the book: minix documentation is better, and if you are
|
|
reading the Tanenbaum book, minix will naturally be closer to what is
|
|
covered in the text.
|
|
- if linux won't run on your hardware (ie PS/2 or any non-386
|
|
hardware, or <2MB memory).
|
|
|
|
Linux has all the features that minix has (except minix-specific things
|
|
like amoeba support), as well as a lot of features minix doesn't have:
|
|
|
|
- a real mm taking advantage of the 386 features. Virtual memory,
|
|
demand-loading, shared pages, the works. There seem to be patches
|
|
for some of this to minix as well, but I haven't heard how well they
|
|
work.
|
|
- multithreading filesystem. 'Nuff said. Available in a limited form
|
|
for minix as a cludge.
|
|
- better buffer cache handling. The cache grows/shrinks dynamically
|
|
with memory consumption.
|
|
- virtual filesystem layer: you can have several different fs's active
|
|
at once. The current standard filesystems are: minix (old 1.5 type),
|
|
extended (255 char filenames, 4GB partitions), msdos, proc (for
|
|
process information), isofs (CDROM filesystem) and NFS client fs.
|
|
- floating point support (ie you can use your coprocessor if you have
|
|
one - the kernel makes sure processes don't mess with each others
|
|
state)
|
|
- coprocessor emulation (so that you can ignore the lack of coprocessor
|
|
if you don't mind the performance hit)
|
|
- netowrking support with tcp/ip and NFS (SLIP is in the works)
|
|
- pretty much 100% POSIX and features from both sysv and bsd worlds:
|
|
porting most stuff is mostly very simple.
|
|
- X11 and most GNU software, as well as a lot of other free software
|
|
out there.
|
|
- shared libraries, so X11 binaries don't take up all your disk space..
|
|
- Active support (me + probably several thousand activists: c.o.linux
|
|
has been on the top-40 lists of most active newsgroups for the last
|
|
couple of months).
|
|
|
|
And a lot more...
|
|
|
|
Linux is lacking in (relative to some other unixes, not minix):
|
|
|
|
- No sysv shared memory yet (well, there are patches, but not part of
|
|
the official kernel), and no real mmap().
|
|
- Not binary compatible with anything
|
|
- Documentation and "real" support (although the c.o.linux newsgroup is
|
|
pretty good)
|
|
- ...?
|
|
|
|
Ok, after having beaten my breast about linux, I'd also better mention
|
|
that 386bsd is also free, and has about similar features. Linux is
|
|
better in some respects: it seems to work on a wider variety on machines
|
|
and is actually stabler on some configurations. On the other hand,
|
|
386bsd has a more mature networking setup, as well as having the
|
|
advantage of being "the real McCoy". Check out both comp.os.linux and
|
|
comp.unix.bsd for details.
|
|
|
|
Note that both linux and 386bsd are good for people who aren't afraid to
|
|
set up the system themselves, and are willing to find documentation from
|
|
various sources. Coherent (USD $99) might be an alternative if you want
|
|
good printed manuals and don't care about X11 or features, but just want
|
|
a simple working unix that has support and is easy to install. And
|
|
although minix doesn't do as much as linux or 386bsd, and doesn't have
|
|
the support of Coherent, it's still a real contender in academic courses
|
|
etc.
|
|
|
|
Linus
|
|
|
|
======================
|
|
======================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: Is MINIX much better than LINUX?
|
|
Message-ID: <1992Dec14.141659.7045@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <1992Dec12.034538.14723@netcom.com> <1992Dec12.090926.28084@klaava.Helsinki.FI> <1ggtrdINN4tb@hrd769.brooks.af.mil>
|
|
Date: Mon, 14 Dec 1992 14:16:59 GMT
|
|
Lines: 37
|
|
|
|
|
|
In article <1ggtrdINN4tb@hrd769.brooks.af.mil> news@hrd769.brooks.af.mil (InterNet News) writes:
|
|
>>
|
|
>>Can't pass on this one... The simple answer is a resounding NO.
|
|
>>
|
|
>
|
|
>Linus,
|
|
> How soon they forget. They leave home and the folks seem like such
|
|
>bumphins :-).
|
|
>
|
|
> You DID cut your operating system teeth on Minix, as I recall. It was
|
|
>pretty spiffy at the time, wasn't it?
|
|
|
|
Well, I used minix for half a year, but why do you think I wrote my
|
|
own...
|
|
|
|
Seriously, I agree with your points: minix is absolutely better than
|
|
nothing, so on older (or non-clone) hardware it's perfectly fine, as
|
|
well as for learning about unix. But the original question (in case
|
|
anybody still remembers it instead of the linux-minix flame-war) was
|
|
whether minix was much better than linux, with the obvious implication
|
|
that he had the hardware to run either. And I've got enough of an ego
|
|
not to let that kind of question go unanswered (besides, the minix group
|
|
has been mostly empty lately, so it can't hurt to get some discussion
|
|
going anyway).
|
|
|
|
Also, Bruce Evans (general good guy and the author of the 386-minix
|
|
patches as well as lots of other minix code) pointed out per email that
|
|
some of the linux features can be gotten as patches (math support etc),
|
|
and that some minix device drivers are better (with patches - mainly
|
|
written by him I suspect) than the linux ones (the reverse is also true,
|
|
of course). So it's not a question of linux being perfect, but assuming
|
|
you have the hardware linux is generally much nicer to use and hack on
|
|
than minix is. That doesn't detract from the usability of minix on
|
|
other hardware (or in special circumstances like university studies
|
|
etc).
|
|
|
|
Linus
|
|
|
|
=======================
|
|
=======================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: Is MINIX much better than LINUX?
|
|
Message-ID: <1992Dec20.235535.4281@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <Bz76pu.AE0@cs.vu.nl> <ARL.92Dec15210739@deathstar.cs.hut.fi> <1992Dec19.162027.1604@frmug.fr.mugnet.org>
|
|
Date: Sun, 20 Dec 1992 23:55:35 GMT
|
|
Lines: 58
|
|
|
|
|
|
In article <1992Dec19.162027.1604@frmug.fr.mugnet.org> archer@frmug.fr.mugnet.org (Vincent Archer) writes:
|
|
>
|
|
>So buy, buy more. I thought that the whole point of Linux was that it was
|
|
>free? I'll have to spend $150 to buy a 386 board. Ok. Then what?
|
|
|
|
No, the whole point of linux isn't that it's free, and never has been.
|
|
It's one of the points that come up most regularly, as it's certainly
|
|
something that gets the attention of most people. It's also one thing I
|
|
stressed in the "linux is obsolete" flamewar, as it's one thing I think
|
|
minix *should* have had as one of it's main points due to being meant
|
|
for studies.
|
|
|
|
In fact, if you want to, you can pay for your linux installation: there
|
|
are at least two CD-roms available already which contain linux sources,
|
|
and a third one seems to be in the making. Also, SLS in Canada sells
|
|
linux on floppies. I'm not getting any money on them, but that doesn't
|
|
mean they are giving linux away for no cost. And I don't mind, because
|
|
'free' wasn't the whole point, just a big plus.
|
|
|
|
The *point* with linux is that I didn't have a good OS on my machine (I
|
|
had DOS and minix, and my definition of good is obviously different from
|
|
ast's), so I wrote one. Making it freely available was a separate
|
|
decision not directly connected with the conception of it, and one that
|
|
paid off handsomely: thanks to that it's now a lot better system than it
|
|
would otherwise have been. It resulted both in me getting good feedback
|
|
and testing for the system, as well as actual patches to make it run
|
|
better: both the SCSI code, the networking code and the new and improved
|
|
math-emulator have been totally written by others.
|
|
|
|
So while you can get linux for free, the real reason you'd want to
|
|
actually *use* (and even pay for it) it is that it's a pretty good
|
|
unix-like OS. After all, even a free program is no better than what it
|
|
does or gives you.
|
|
|
|
>I've never used a 386. I'll never use one, unless you put a gun on my head
|
|
>(then I'll do everything you say. And shoot you in the back at the first
|
|
> occasion).
|
|
|
|
You are missing out on something. I programmed a 68k machine before
|
|
getting a PC, and yes, I was a bit worried about the intel architecture.
|
|
It turned out to be ok, and more importantly: it's the cheapest thing
|
|
around. A 386 in protected mode is in fact a very pleasant processor,
|
|
and while it could do with some more registers (at least double the
|
|
current number), there are no major problems with it.
|
|
|
|
The worst part of a PC-compatible is the BIOS and DOS, and I no longer
|
|
have to care about them. Even the much maligned ISA bus is pretty good:
|
|
it may not be technically superior, but it does what a bus is supposed
|
|
to do very well: hook up hardware. A lot of hardware.
|
|
|
|
It's not even too hateful to program in assembly, and when you program
|
|
it in C, it looks like any other 32-bit computer. Except for being a
|
|
lot cheaper than anything else that fast... Not to say I wouldn't like
|
|
a Mac or an Amiga, but it's certainly a bad idea not to even consider a
|
|
386 now that there are good alternatives to MS-DOS around (and no, I'm
|
|
not necessarily talking linux).
|
|
|
|
Linus
|
|
|
|
=====================
|
|
=====================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: Long filenames
|
|
Message-ID: <1992Dec23.131313.10139@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <a75d0246@mtlookitthat.chi.il.us>
|
|
Date: Wed, 23 Dec 1992 13:13:13 GMT
|
|
Lines: 65
|
|
|
|
|
|
In article <a75d0246@mtlookitthat.chi.il.us> chanson@mtlookitthat.chi.il.us (Chris Hanson) writes:
|
|
>Hi! Can anyone point me to some info (or tell me themselves) on how to
|
|
>implement long filenames for minix? [I know someone's done it -- one
|
|
>of the dudes in the 'MINIX vs LINUX' discussion mentioned it.] I'm
|
|
>thinking that 30 chars or 62 chars shouldn't be that hard (we'd be
|
|
>keeping a dir_entry at an even multiple of 16 bytes), but I know it'll
|
|
>involve more than just recompiling the kernel with MAX_NAME changed.
|
|
|
|
The problem shouldn't be so much the kernel as all the binaries you are
|
|
using: changing the directory structure will break everything that reads
|
|
directory entries - this includes important binaries like 'ls'
|
|
(obviously), the shell (for filename globbing, name completion etc),
|
|
'make', etc.
|
|
|
|
>Will I need to make new filesystems and move everything to them? Or is
|
|
>a compatibility hack (such as puting an optional fstype flag or a
|
|
>different magic number in a device's superblock to tell whether it has
|
|
>long or standard pathnames) trivial?
|
|
|
|
I'd go for the compatability hack: creating a new filesystem from
|
|
scratch for the new kernel is simply too painful (as well as making
|
|
debugging pretty mcuh impossible... much easier to start off with just
|
|
one partition with the extended setup, and test out all the new binaries
|
|
on that one first). I'd also suggest you add a "readdir()" system call
|
|
while you are at it, which checks the magic number and returns the
|
|
correct type of directory entry. That way binaries compiled to use it
|
|
will be able to function correctly on both the new and old type of
|
|
filesystem.
|
|
|
|
There are a couple of alternatives you could do:
|
|
|
|
(a) go for a complete vfs (virtual filesystems) interface. This would
|
|
make it possible to later add totally different types of filesystems.
|
|
It's more general, but it's also a lot more coding. This is the
|
|
approach linux uses, and it gives the possibility to mount msdos etc
|
|
filesystems transparently.
|
|
|
|
(b) do the long filenames by fooling around with several consecutive
|
|
minix-type directory entries. Depending on how you do it, you can make
|
|
old binaries see only th first characters of a extended filename, while
|
|
new binaries see them all. Besides, this means you won't waste a full
|
|
64-char direntry for short files, but instead use several entries only
|
|
when necessary. The downside is that it's a bit more work in the
|
|
kernel.
|
|
|
|
The directory entries in (b) could be made to work by using a magic
|
|
cookie at the end of a filename to mean that the filename continues in
|
|
the next entry (which has a inode nr of 0 to make old programs ignore
|
|
it). It could look something like this:
|
|
|
|
file "really_long_name", use '\000\377' as continuation marker:
|
|
|
|
.word inode_number
|
|
.byte 'really_long_\000\377' /* first 12 chars */
|
|
.word 0x0000 /* next entry is a continuation */
|
|
.byte 'filename\0' /* rest of the filename */
|
|
|
|
This can be extended to any filename length, and old programs will see
|
|
only the first 12 characters, but they should work otherwise. I think
|
|
somebody implemented something like this. Patches, anybody? Naturally,
|
|
you'd have to make sure that none of your current filesystems happen to
|
|
have the '\000\377' sequence at the end of a directory entry, but that
|
|
should be simple enough.
|
|
|
|
Linus
|
|
|
|
=========================
|
|
=========================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: ACK ANSI Compiler
|
|
Message-ID: <1993Jan3.115527.11032@klaava.Helsinki.FI>
|
|
Keywords: ACK, ANSI, compiler
|
|
Organization: University of Helsinki
|
|
References: <1i5nm6INN40n@werple.apana.org.au>
|
|
Date: Sun, 3 Jan 1993 11:55:27 GMT
|
|
Lines: 34
|
|
|
|
|
|
In article <1i5nm6INN40n@werple.apana.org.au> hock@werple.apana.org.au (Warwick Hockley) writes:
|
|
>
|
|
>I think the main point is that most people feel that the 3 compilers should
|
|
>be unbundled, and the price for each reduced appropriately.
|
|
|
|
The problem with this is probably ACK itself: ACK is a general compiler
|
|
generation package, so in fact giving three compilers away for the price
|
|
of one is not such a problem, while selling just one compiler for a
|
|
third of the price is probably not something ast & co want to do.
|
|
Remember, it's not really three different compilers, as most of the code
|
|
is probably the same in all of them. So the $200 can probably be
|
|
thought of as the price of one compiler, with the others thrown in for
|
|
free (or something close to that). ast?
|
|
|
|
I also wonder what people really need the new compiler for? On a 68k
|
|
minix box or a 386, you are probably better off using gcc anyway if you
|
|
have the memory for it, and if you don't it's probably cheaper (and
|
|
easier) to buy memory than the compiler. Alternatively you can use the
|
|
smaller CvW compiler that seemed to work quite well the one time I
|
|
tested it (but no, I don't think it's ANSI - but unprotoize should
|
|
probably work with it). For PC's, there is also Bruce Evans' compiler
|
|
for both 16- and 32-bit code (unprotoize...).
|
|
|
|
The only people I see using the new ANSI compiler extensively would be
|
|
people with old PC/XT's, and if they can put up with that kind of
|
|
hardware, thay should certainly be able to put up with an older release
|
|
of the compiler as well (*). It's not as if you could port many
|
|
standard unix programs to a 64+64kB machine anyway, so the lack of ANSI
|
|
shouldn't be that bad an experience: you'd just have to write your
|
|
programs using K&R.
|
|
|
|
Linus
|
|
|
|
(*) It's a joke guys. Well, mostly. Tongue in cheek, you know.
|
|
|
|
==============================
|
|
==============================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: 68000/i386 C Compiler V4.1 -> V4.2 Patch [Part 1/4]
|
|
Message-ID: <1993Jan21.140146.8688@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <1668@ozz.oasis.icl.co.uk> <1705@uitecgw.uitec.ac.jp> <1993Jan21.124103.6725@email.tuwien.ac.at>
|
|
Date: Thu, 21 Jan 1993 14:01:46 GMT
|
|
Lines: 19
|
|
|
|
|
|
In article <1993Jan21.124103.6725@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
|
|
>nemossan@uitec.ac.jp (Sakurao NEMOTO) writes:
|
|
>> I am using C386 version 4.1 on the 486 (33 MHz) machine. I works
|
|
>>fine. But new Version (4.2 - compiled by 4.1) can not compile itself.
|
|
>>This new c386 loops forever at compiling src/optimize.c.
|
|
>
|
|
>I tried to compile it with gcc 2.2.2, but it wouldn't link. The linker
|
|
>(from gcc 1.37.1) doesn't print any error messages, but it doesn't
|
|
>produce an executable either. There must be something magic about
|
|
>c386 4.2 :-(
|
|
|
|
No - it's probably due to a bug in the linker. I had similar problems
|
|
when I used the original 1.37 version of gcc+binutils under minix, and
|
|
solved most of them by compiling gcc-1.40 and a newer version of
|
|
binutils. I don't remember what the exact reason for the bug was, but
|
|
it was annoing: 'ld' just died without doing anything (I don't think it
|
|
even returned an error code to tell you something went wrong).
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Minix, Minix, Linux, and SunOS.
|
|
Keywords: speed
|
|
Message-ID: <1993Feb12.232505.21737@klaava.Helsinki.FI>
|
|
Date: 12 Feb 93 23:25:05 GMT
|
|
References: <C2C58p.4Cq@cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 54
|
|
|
|
|
|
In article <C2C58p.4Cq@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
|
|
>Linux is fast, so they claim. This is also what I myself was thinking,
|
|
>after all, how can a single monolithic kernel with sources that contain
|
|
>more asm() statements than comments not be fast?
|
|
|
|
:-) I think the problem is more a lack of comments than the number of
|
|
__asm__ statements..
|
|
|
|
>Testing time:
|
|
>
|
|
>$ cat > x.c
|
|
>main(argc, argv) char **argv;
|
|
>{
|
|
> write(1, &argv[1][0], 1);
|
|
> exit(0);
|
|
>}
|
|
>$ cc -o x x.c
|
|
>$ cat > xtest
|
|
>#!/bin/sh
|
|
>(
|
|
> (while :; do ./x x; done & a=$!; sleep 10; kill $a) &
|
|
> (while :; do ./x y; done & a=$!; sleep 10; kill $a)
|
|
> sleep 1
|
|
> echo
|
|
>)
|
|
|
|
You don't mention what shell you are using under minix: under linux
|
|
/bin/sh is automatically the bourne again shell ("and in the blue
|
|
corner, bash from GNU, weighing in at a whopping 230kB even when
|
|
stripped and using shared libraries"). If your /bin/sh under minix is
|
|
the original minix shell ("in the red corner, the original bourne shell,
|
|
weighing in at 40kB"), your numbers aren't too surprising.
|
|
|
|
>The number of fork+exec's on each system:
|
|
>
|
|
> Minix-i86 Minix-i386 Linux SunOS
|
|
> 673 1219 502 192
|
|
>
|
|
>How? Why? I don't understand it much myself. My mind boggles when I
|
|
>think about the number of messages Minix-i386 must be producing. Are
|
|
>Linux shared libraries slowing things down? Half the binaries and half
|
|
>the speed? :-)
|
|
|
|
No, I doubt it's the shared libraries: they are reasonably efficient.
|
|
Could you try to compile the minix shell under linux and use that for
|
|
the testing purposes (alternatively use bash under minix-386: this won't
|
|
work under normal minix-i86, but should at least give some kind of idea
|
|
of relative speeds).
|
|
|
|
As to the SunOS performance: hard to say. /bin/sh under SunOS is also
|
|
more then double the size of the minix shell, and the hardware is
|
|
different, so the numbers aren't really very meaningful.
|
|
|
|
Linus
|
|
|
|
==========================
|
|
==========================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Minix, Minix, Linux, and SunOS.
|
|
Keywords: speed
|
|
Message-ID: <1993Feb13.121719.5907@klaava.Helsinki.FI>
|
|
Date: 13 Feb 93 12:17:19 GMT
|
|
References: <C2C58p.4Cq@cs.vu.nl> <1993Feb12.232505.21737@klaava.Helsinki.FI> <C2DuE2.1uv@cs.vu.nl>
|
|
Organization: University of Helsinki
|
|
Lines: 24
|
|
|
|
|
|
In article <C2DuE2.1uv@cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes:
|
|
>
|
|
>The shell I use is /bin/sh, the shell that comes with the system.
|
|
>That's the shell people are using. The bash shell is as much part of
|
|
>Linux as those asm() statements.
|
|
|
|
Fair enough - the default linux shell is slow and big when compared to
|
|
some other shells.
|
|
|
|
>If the system is to be tested, then it must be tested as is. You don't
|
|
>start by replacing every other utility by some crippled but fast
|
|
>replacement.
|
|
|
|
True, but in that case the tests should be a bit more meaningful. The
|
|
only thing your test showed was how fast the shell forks under the
|
|
systems, and not much else. Lies, damned lies and benchmarks.. Shell
|
|
fork time does have *some* meaning, but it's usually not noticeable.
|
|
You might want to try out the BYTE benchmarks - I haven't tested them
|
|
myself, but they have probably been written to test a more "real" setup
|
|
(yes, they have a shell benchmark, and I won't mind if you use bash
|
|
under linux for it). The BYTE benchmarks are probably available for ftp
|
|
from most bigger sites.
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: Help with .z files from minnie
|
|
Message-ID: <1993Apr3.110820.2529@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <Mike_Peters-020493172744@greer.az.stratus.com>
|
|
Date: Sat, 3 Apr 1993 11:08:20 GMT
|
|
Lines: 23
|
|
|
|
|
|
In article <Mike_Peters-020493172744@greer.az.stratus.com> Mike_Peters@vos.stratus.com (Mike Peters) writes:
|
|
>I've been t5rying for several hours to get several ".z" files from minnie
|
|
>"decompressed". I'm using Minix on a Mac, but I've transferred the files
|
|
>to a pc and tried PKUNZIP on them with no luck. I've also tried zcat under
|
|
>unix (I know that .z means PC ZIP format, but I hoped the .z was mistyped
|
|
>and a .Z was really intended). I've also tried several Mac versions of
|
|
>UnZip without luck.
|
|
|
|
Th GNU world has gone over from the original unix [un]compress to GNU
|
|
zip (aka gzip), which produces noticeably smaller compressed files and
|
|
has no problems with patents. Maybe minnie also now uses the gzip
|
|
format: .z is the standard extension for gzipped archives. You should
|
|
find sources for gzip at most GNU ftp-sites - it's worth a try. Gzip
|
|
can also uncompress normal .Z files (the uncompression code isn't
|
|
patented), and I think it also handles the old 'pack' format (as
|
|
somebody already pointed out, 'pack' also uses .z, but almost nobody
|
|
actually uses pack).
|
|
|
|
GNU zip uses the same compression algorithms as pkzip, but has a
|
|
different header (pkzipped archives contain path information etc,
|
|
gzipped don't), so pkzip won't uncompress them.
|
|
|
|
Linus
|
|
|
|
============================
|
|
============================
|
|
Newsgroups: comp.os.minix
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: v1.6.25 on i386
|
|
Message-ID: <1993Jun1.200514.14817@klaava.Helsinki.FI>
|
|
Organization: University of Helsinki
|
|
References: <BROMAN.93Jun1110427@schroeder.nosc.mil>
|
|
Distribution: comp
|
|
Date: Tue, 1 Jun 1993 20:05:14 GMT
|
|
Lines: 96
|
|
|
|
|
|
In article <BROMAN.93Jun1110427@schroeder.nosc.mil> broman@nosc.mil writes:
|
|
>| prot_init() has set up a gdt compatible with the BIOS interrupt to switch
|
|
>| modes. The boot monitor has done this already however, but without a proper
|
|
>| idt. So we reload gdtr, idtr and the segment registers to this better table.
|
|
>| This is what the BIOS call would have needed:
|
|
>| gdt pointer in gdt[1]
|
|
>| ldt pointer in gdt[2]
|
|
>| new ds in gdt[3]
|
|
>| new es in gdt[4]
|
|
>| new ss in gdt[5]
|
|
>| new cs in gdt[6]
|
|
>| nothing in gdt[7] (overwritten with BIOS cs)
|
|
>| ICW2 for master 8259 in bh
|
|
>| ICW2 for slave 8259 in bl
|
|
>
|
|
> lgdt _gdt+BIOS_GDT_SELECTOR
|
|
> lidt _gdt+BIOS_IDT_SELECTOR
|
|
|
|
Hmm?? I don't know what you are doing, but this looks wrong. 'lgdt' and
|
|
'lidt' both take 48-bit pointers as argument, containing the absolute
|
|
virtual memory address of the table and the extent of the table. This
|
|
*looks* like you are trying to set up a new GDT/IDT using a selector. I
|
|
haven't used the BIOS interface, but if I remember correctly, gdt[1] is
|
|
supposed to contain a memory selector that covers the real GDT, but that
|
|
does not mean that you can use 'lgdt' on it. Similarly for 'lidt'.
|
|
|
|
You should do something like:
|
|
|
|
lgdt gdt_mem48
|
|
lidt idt_mem48
|
|
|
|
where 'gdt_mem48' and 'idt_mem48' look something like this:
|
|
|
|
gdt_mem48:
|
|
dw 8*nr_gdt_entries-1
|
|
dl vm_offset_of_gdt_table
|
|
idt_mem48:
|
|
dw 8*nr_idt_entries-1
|
|
dl vm_offset_of_gdt_table
|
|
|
|
And note that "vm_offset_of_XXX_table" is not an offset within the
|
|
current segment, but actually a 32-bit "flat address" offset = the
|
|
actual physical address of the table assuming you haven't got paging
|
|
enabled yet.
|
|
|
|
Additionally, if you want to use the BIOS, I think you'll have to
|
|
initialize gdt[1] and gdt[2] to be memory segments that cover the gdt
|
|
and idt tables respectively (ie with the segment base being the offset
|
|
of the gdt/idt, and the segment limit being at least as long as the
|
|
gdt/idt table).
|
|
|
|
> jmp far CS_SELECTOR:csinit | ?????
|
|
>csinit:
|
|
> mov ax,#DS_SELECTOR
|
|
|
|
This point has several potential problems:
|
|
- mov ax,#DS_SELECTOR is a 16-bit load in 16-bit mode, but when you
|
|
change into 32-bit mode the same instruction bitpattern is
|
|
interpreted as a 32-bit insn. So what happens is that eax is loaded
|
|
with a 32-bit value, the low 16 bits of which are DS_SELECTOR, and
|
|
the high 16 bits are from the next instruction.. You have to be
|
|
*very* careful when trying to create 32-bit code with a 16-bit
|
|
assembler or vice versa.
|
|
- are you sure you are jumping to the correct address? Does the old
|
|
16-bit segment have the same offset as the new 32-bit segment? In
|
|
most cases when using 32-bit segments, they are set up to cover the
|
|
whole 32-bit VM space (or at least a noticeable portion of it), while
|
|
the old 16-bit segment probably covers only a very small part. And
|
|
the offsets within those segments to the 'csinit' instruction may
|
|
well differ.
|
|
|
|
>I infer that the GDT that was just loaded must have been bad, so that
|
|
>reloading CS causes the crash. But the descriptor tables were created
|
|
>by C code in protect.c . Is that code designed only for 286 protected mode?
|
|
|
|
While I'd guess that the GDT is bad, you could also have a bad 'csinit'
|
|
offset (as well as a bad "hanghere" offset) due to possibly different
|
|
segment bases with the new 32-bit segments? In fact, there are so many
|
|
things that can go wrong during the switch (and they tend to result in
|
|
instant reboots), that it's hard to say which of them is the reason..
|
|
|
|
>The comments found in mpx386.x indicate that the descriptor tables were to be
|
|
>compatible with the requirements of "the" BIOS. Which BIOS and which
|
|
>requirements are these?
|
|
|
|
Any 286/386 BIOS has an interface for changing into protected mode: the
|
|
comments just tell you what the BIOS routines expect to see in the GDT.
|
|
Actually, using the BIOS interface is probably more pain than gain, and
|
|
unless the rest of the bootup sequence wants to use it, I'd suggest
|
|
doing it by hand (but that's not exactly easy either), as it gives you
|
|
more control of what to set into the segment descriptors. Besides, it's
|
|
more interesting that way :-). But you probably *will* need a good book
|
|
in order to understand the "somewhat non-intuitive" 386 segmentation
|
|
setup.
|
|
|
|
Linus
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix,comp.os.386bsd.misc,comp.os.386bsd.questions,comp.os.linux,alt.uu.comp.os.linux.questions
|
|
Subject: Re: Choosing a Unix like OS for a pc
|
|
Date: 20 Jun 1993 13:48:25 +0300
|
|
Organization: University of Helsinki
|
|
Lines: 21
|
|
Message-ID: <201f9p$kkv@klaava.Helsinki.FI>
|
|
References: <1993Jun19.125224.17510@colorado.edu> <C8wC29.9qq@world.std.com>
|
|
NNTP-Posting-Host: klaava.helsinki.fi
|
|
|
|
|
|
In article <C8wC29.9qq@world.std.com> jimr@world.std.com (James A Robinson) writes:
|
|
>
|
|
>As I understand it Linux has more features then Minix and takes up
|
|
>less space then 386bsd. Apparently the TCP/IP of BSD is more stable
|
|
>then Linux, but that may have already changed, as I only have an old
|
|
>FAQ. In any case Linux is one of the hottest unix look-alikes around,
|
|
>since Linux seems to have the knack of making the kernel look like it
|
|
>was running on a RISC rather then an 80486. :-) All the tools run
|
|
>very fast, and I can compile the kernel in about 18 minutes, which in
|
|
>my opinion is darn fast for a 486sx 25MHz.
|
|
|
|
To give minix some credit: Bruce Evans told me he was able to recompile
|
|
the kernel in less than one minute if I remember correctly. Of course,
|
|
he has a reasonably fast machine and minix sources are smaller, but the
|
|
main time-saver is that the minix (and coherent) C-compilers are much
|
|
faster than gcc... Not that I would trade the compilers, but if you are
|
|
looking for speed of compilation, minix and coherent both do it faster
|
|
than either linux or 386bsd (at the expense of features and code
|
|
quality).
|
|
|
|
Linus
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Choosing a Unix like OS for a pc
|
|
Date: 29 Jun 1993 21:56:22 +0300
|
|
Organization: University of Helsinki
|
|
Lines: 29
|
|
Message-ID: <20q38m$bj1@klaava.Helsinki.FI>
|
|
References: <1993Jun29.182612.23802@udel.edu>
|
|
NNTP-Posting-Host: klaava.helsinki.fi
|
|
|
|
|
|
In article <1993Jun29.182612.23802@udel.edu> Steve_Kilbane@gec-epl.co.uk writes:
|
|
>In article <9306291722.AA17256@cuthbert.bashstreet> Chris Maeda, Grad Student and RetroGrouch <cmaeda@cs.cmu.edu> writes:
|
|
>
|
|
>>What a breakthrough! If you want your kernel to compile twice as
|
|
>>fast, use a compiler that's twice as dumb or leave out half the
|
|
>>functionality. You guys should write a paper for usenix.
|
|
>
|
|
>I hope this should have a smilie after it... the point is that Oberon goes
|
|
>for a *minimalist* system, not a *non-functional* system. The functionality
|
|
>is there, but you've got a smaller, cleaner set of primitives. Contrast
|
|
>bash with rc for a rough idea of this concept - it's what UNIX used to be
|
|
>synonymous with, instead of with a bloated morass of ageing code ...
|
|
|
|
It's also a question of resource-handling: some systems that are smaller
|
|
and simpler will work a lot better on a small machine, even though "we
|
|
real men" laugh and ridicule them. I tried to stress-test the linux mm
|
|
routines the other day by re-compiling the kernel on a machine with only
|
|
2MB of memory, and I simply gave up after 5 hours when it hadn't even
|
|
made it half-way... gcc was simply swapping itself to death, and 'time'
|
|
reported that of the 5 hours passed, only about 6 minutes had been used
|
|
for any real user-level work.
|
|
|
|
I'll be the first one to say that I prefer linux over minix, but even
|
|
when linux works, it does need more resources to run (not so much due to
|
|
kernel bloat as to memory requirements of the standard programs,
|
|
although the kernel is bigger too). The same is usually true of other
|
|
similar comparisons.
|
|
|
|
Linus
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@cc.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Minix + Linux...
|
|
Date: 26 Jul 1994 14:29:18 +0300
|
|
Organization: University of Helsinki
|
|
Lines: 16
|
|
Message-ID: <312s2e$a7t@klaava.Helsinki.FI>
|
|
References: <gshinCtH35H.JJ@netcom.com>
|
|
NNTP-Posting-Host: klaava.helsinki.fi
|
|
Mime-Version: 1.0
|
|
Content-Type: text/plain; charset=ISO-8859-1
|
|
Content-Transfer-Encoding: 8bit
|
|
|
|
|
|
In article <gshinCtH35H.JJ@netcom.com>, George Shin <gshin@netcom.com> wrote:
|
|
>
|
|
>2. Since Linux can work with Minix filesystem formats, can i prepare the
|
|
> Minix partition and make the file system before installing Minix
|
|
> to my hard disk? When i was installing Linux, i set aside 50MB of
|
|
> partition for Minix...
|
|
|
|
If you make the partition from within linux, make sure (a) to use
|
|
14-character filenames ("-n14" for mkfs.minix, if I remember correctly -
|
|
long time since I wrote it :-) and (b) don't use symbolic links which
|
|
are not supported in standard minix.
|
|
|
|
(I think the minix symlink extension patches uses the same symlink
|
|
format linux does, but I don't know)
|
|
|
|
Linus
|
|
|
|
=============================
|
|
=============================
|
|
From: torvalds@cc.Helsinki.FI (Linus Torvalds)
|
|
Newsgroups: comp.os.minix
|
|
Subject: Re: Minix + Linux, File Systems
|
|
Date: 29 Jul 1994 10:30:24 +0300
|
|
Organization: University of Helsinki
|
|
Lines: 29
|
|
Message-ID: <31ab6g$k7r@klaava.Helsinki.FI>
|
|
References: <317uls$l77@louie.udel.edu>
|
|
NNTP-Posting-Host: klaava.helsinki.fi
|
|
Mime-Version: 1.0
|
|
Content-Type: text/plain; charset=ISO-8859-1
|
|
Content-Transfer-Encoding: 8bit
|
|
|
|
|
|
In article <317uls$l77@louie.udel.edu>,
|
|
Georg Wagner <wagg@zellweger.ch> wrote:
|
|
>>Also note that Minix and Linux have a minor(*) difference in how they
|
|
>>remove a file:
|
|
>
|
|
>A word of warning however! Linux and Minixfs are still incompatible in some
|
|
>ways. The bitmap formats are currently incompatible! This means you shouldn't
|
|
>write to Minixfs partitions with Linux or vice versa before running the native
|
|
>fsck. [ big-endian / little-endian ]
|
|
|
|
Note that this is not true for the i386 version, at least. But it might
|
|
be true for the 68k version of linux, although I haven't looked into it.
|
|
|
|
However, if I remember correctly, there is one small incompatibility
|
|
even on the i386 version - I think the minix bitmaps wrap around to use
|
|
bit #0 as the highest bit under some very rare circumstances (when the
|
|
bitmap is exactly a multiple of the blocksize). They don't wrap around
|
|
under linux (bad idea in the first place).
|
|
|
|
Note that if you use the linux mkfs.minix, I added some silly stuff to
|
|
change the size of the bitmaps so that this one-bit-difference would
|
|
never occur (and if you use minix mkmf you will also have to work very
|
|
hard to find the right parameters to make it happen).
|
|
|
|
It's a long time since I wrote that stuff, and I no longer have minix to
|
|
check it, so the above may be a bit off. Nobody has ever even noticed
|
|
the differences, I think (well, bde did, but he's not really human).
|
|
|
|
Linus
|
|
|
|
===========================
|
|
===========================
|
|
From: torvalds@cc.Helsinki.FI (Linus Torvalds)
|
|
Subject: Re: FS size supported in 1.7
|
|
Date: 1995/12/24
|
|
Message-ID: <4bjd8l$hpu@klaava.helsinki.fi>#1/1
|
|
sender: torvalds@cc.helsinki.fi
|
|
references: <DJzBDs.4J7@bercos.de> <DJzzp7.EIt.0.-s@cs.vu.nl> <DK1JEA.A41@bercos.de> <DK33sn.8xz.0.-s@cs.vu.nl>
|
|
content-type: text/plain; charset=ISO-8859-1
|
|
organization: University of Helsinki
|
|
mime-version: 1.0
|
|
newsgroups: comp.os.minix
|
|
|
|
|
|
In article <DK33sn.8xz.0.-s@cs.vu.nl>, Kees J Bot <kjb@cs.vu.nl> wrote:
|
|
>
|
|
>>BTW: How does Minix (old) FS acces more than 64M? I saw the BLOCKS_SIZE
|
|
>>defined as 1024 Bytes.
|
|
>
|
|
>The disk drivers use a 32-bit block number even under Minix 1.5. So the
|
|
>size of the disk or a partition is limited to 4 G as far as the drivers
|
|
>are concerned.
|
|
|
|
Actually, in this day of multi-GB harddisks, it might be worth pointing
|
|
out that 32-bit block numbers are good for 4TB worth of disk-space, as
|
|
long as you do block-addressing (assuming a 1kB block size here). This
|
|
is how the linux ext2fs is able to handle large (where large means ">>
|
|
4GB", not "> 256MB" ;-) filesystems even though all block numbers are 32
|
|
bit.
|
|
|
|
We have a 20GB filesystem on our university linux NFS server, and you
|
|
can even keep fsck times down by (a) using a UPS and (b) having a
|
|
reasonably clever fsck.
|
|
|
|
> FS further limits this to 2 G because file positions are
|
|
>signed (off_t).
|
|
|
|
A file size limit of 2GB is not nearly as debilitating as a filesystem
|
|
limit of 2GB. Generally you need larger files only for large databases
|
|
(famous last words: I'm sure somebody will shoot me down for this), and
|
|
lots of databases want to do their own "filesystem" anyway (ie write to
|
|
the raw disk device).
|
|
|
|
> A file system is further limited by the maximum number
|
|
>of 32 zone bit maps. (One bit map can see 8 K zones = 8 M bytes for a
|
|
>1 kb zone size.)
|
|
|
|
Sure, that can be a problem. I haven't taken a look at the new minix
|
|
filesystem, but this can generally be handled by having a lot of zone
|
|
bitmaps, and not having them all in memory at the same time. That does
|
|
make the filesystem code more complex, though.
|
|
|
|
Linus
|
|
|
|
|
|
=========================
|
|
=========================
|
|
From: torvalds@cc.helsinki.fi (Linus Torvalds)
|
|
Subject: Re: Minix Source
|
|
Date: 1996/03/27
|
|
Message-ID: <4jb4m1$dc0@kruuna.helsinki.fi>#1/1
|
|
references: <31573026.7516@rcsn.nb.ca> <31a7cc$ffe.1e0@news.hampshire.edu>
|
|
content-type: text/plain; charset=ISO-8859-1
|
|
organization: University of Helsinki
|
|
mime-version: 1.0
|
|
newsgroups: comp.os.minix
|
|
|
|
|
|
In article <31a7cc$ffe.1e0@news.hampshire.edu>,
|
|
Albert S Woodhull <aswNS@hamp.hampshire.edu> wrote:
|
|
>On Mon, 25 Mar 1996 15:45:42 -0800 Geoffrey Hamilton
|
|
>(hamiltong@rcsn.nb.ca) wrote in comp.os.minix:
|
|
>
|
|
>: I've been trying to read the minix source code from ftp.cs.vu.nl. I've
|
|
>: followed the actions to a "tee" and when I attempt to mount /dev/fd0 (the
|
|
>: 1.44 Mb drive it's in) specifying type minix (I'm using Linux) it gives
|
|
>: me a "wrong fs or bad superblock" error. What am I doing wrong..?
|
|
>
|
|
>Linux supports an old version of the Minix file system, but a new (V2)
|
|
>file system was introduced some time ago, and Linux doesn't know how
|
|
>to handle it. (At least my fairly old Linux 1.0.8 kernel doesn't, it
|
|
>may be supported in newer versions).
|
|
|
|
It is indeed supported in the newer versions, but I haven't tested this
|
|
myself (the code is there, and it obviously worked for gertjan@cs.vu.nl,
|
|
but there hasn't been any feedback on it that I have seen).
|
|
|
|
However, you do have to get a fairly recent linux kernel in order to get
|
|
this functionality - and I don't think any of the CD-ROM's have anything
|
|
that recent pre-compiled so you have to do that yourself (obviously, if
|
|
you're interested in the minix sources, you are not likely to be nervous
|
|
about compiling your own linux kernel).
|
|
|
|
Linus
|
|
|
|
|
|
===========================
|
|
===========================
|