Subject: Re: SVGA and the kitchen sink. Date: Mon, 6 Jan 1992 21:49:06 PST From: pmacdona@sanjuan.UVic.CA (Peter MacDonald)
Two things. First I think bios and therefore V86 access will be required
if for no other reason than because two many clone vendors rely on it
to deliver "compatibility".
Second. Before X11 can even be looked at, another feature will be
required. That is, shared dynamic linked libraries. I just finished
working on a Decstation 3100 for 6 months using Ultrix which does
not have this. The executables are monsterous, and the only thing
they eat more of than disk space is memory. Plus, if Linux is to
be distributed over ftp, and we wish to permit access to distributing
binaries, then much net-width can be saved. But most of all, since
Linux is fast evolving, if we want to avoid frequent recompiles of
all utilities every time a library routine changes (such as job
control requires) then we better get shared libs fast.
The moral of the tale is, if anyone out there is currently idle,
and knows something about compilers, and is willing to tackle
shared libs, please step forward at the sound of the tone.
^G
Original post in KCLUG archives
Subject: Re: Device driver text with source. Date: Mon, 13 Jan 1992 01:34:24 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
"Thomas E. Kunselman": "Device driver text with source." (Jan 12, 17:56):
> I was reading misc.books.technical and thought someone on here might be
> interested in this. I'm a new subscriber, so hope this hasn't been
> posted before.
>
> Writing UNIX Device Drivers
> By George Pajari [deleted]
A small word of warnig: linux looks like a unix, but I implemented it
from scratch, and with very little litterature on how things "should" be
done. In fact the only things I knew were how the interface should
appear to the user: the result is not the same as either minix, sysv or
bsd when it comes to the kernel innards. Some of the choises I made
worked out well, some not so well. So far nothing has been a total
disaster: most things have been relatively easily adaptible to the linux
kernel (demand-loading and paging comes to mind: they were essentially
painless to do for linux).
This doesn't mean that this book wouldn't be very practical (it probably
is), but it does mean that you cannot take the code and use it directly
for linux. Of course the underlying algorithm may well work splendidly.
The three books I had as references were:
"Maurice J Bach: The design of the unix operating system". This is a
nice general text, and has some simple algorithms for some things.
Recommended.
"Tanenbaum: Operating Systems, Design and Implementation". Hmm. I didn't
use this book much for the actual implementation (other than getting the
minix filesystem design out of it), but unless you understand the
principles ast writes about, unix kernel hacking is difficult at best.
"Crawford & Gelsinger: Programming the 80386". What can I say. If you
want to program the 386-specific stuff, this is a must.
Linus
Original post in KCLUG archives
Subject: linux-0.12 is available Date: Wed, 15 Jan 1992 02:13:40 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
Ok, the subject says it all. The kernel source and the disk-images are
available on nic.funet.fi, and I'm assuming they will migrate to other
places in a couple of days. There is a RELNOTES-0.12, but installation
is similar to 0.11, so the installinfo in relnotes is pretty minimal.
Note that even users of 0.11 should boot up from floppy first and copy
all the binaries to their proper places on the harddisk partition: fsck,
ls etc have changed with symlinks, and bash (/bin/sh) due to job
control.
Also note that I've decided to change the copyright to have the same set
of rules as the GNU copyleft - I got some mail asking about it, and I
agree. The old copyright still holds for now - I want to make sure none
of the "co-authors" would mind, but I'm pretty sure they won't. It won't
actually change the copyright very much: it's the handling-costs extra
etc.
I'll send some additional files (the complete fileutils, the new library
and libc.a etc) tomorrow.
Linus
Original post in KCLUG archives
Subject: the rest of the linux-0.12 distribution Date: Wed, 15 Jan 1992 19:49:55 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
Ok, I have uploaded the rest of the linux distribution to nic.funet.fi.
They aren't visible yet, but I guess they'll show up tomorrow or so.
The new files are:
- fileutil.tar.Z, which contains most of the GNU fileutils. It's not
the latest release, so if you want that, you'll have to compile it
for linux. No source changes, but a lot of -DSTPCPY_MISSING etc in
the makefiles.
- hd.c. I have gotten one problem report already about hd-handling in
0.12. This is a correction to kernel/blk_drv/hd.c, and should
hopefully correct the problem. There was also a problem with a
second harddisk not working although the first one did: I think I
found the problem, and fixed it. If you cannot get linux operating
at all (but the bug wasn't that severe, I think), and are thus unable
to recompile it, mail me.
- include.tar.Z. Yes. Yet another include.tar.Z. I don't save old
versions, so I don't do cdiffs :(. I still expect patches to be
cdiffs. Bastard, ain't I?
- lib.tar.Z. The library sources.
- libc.a.Z. Compiled libc.a
- mkswap. This should have been on the root-diskette, but was
forgotten. See description in RELNOTES.
- system.tar.Z. The latest sources to the system files: mkswap, mkfs,
fsck and fdisk.
- utils.tar.Z. Contains a new tar (you can use the old one to untar
this, but this should understand about symbolic links etc), make,
uemacs and some minor programs (sed and basename I think).
The old utilbin.tar.Z file should be replaced by 'fileutil' and 'utils'.
The old include.tar.Z, libc.a library.tar.Z should be replaces by their
newer versions. The old uemacs.Z, bash.Z can also be removed from the
archives.
There is some overlapping between these files and the root-diskette (and
older versions of linux).
And over to other things:
Someone asked on comp.os.minix how to move non-tar files to a linux
partition: the INSTALL-0.11 told about tar-files, but not about things
like libc.a. The easiest answer is to tar the single file into a
tar-file, and then the problem is reduced to something we can handle.
Another possibility is to use the mtools package, but there were so many
questions about it the last time that I'm not even going to mention it
this time around.
A third possibility is to just write the file to a floppy using
rawrite.exe or NU or something, and then reading the floppy and
truncating at the filelength. This means you have to remember how long
the file was. Truncation can be done by 'dd' or by 'head -c'.
And one warning...
There are easy ways to make fsck report errors on your harddisk that
were introduced with the demand-loading in 0.11. It's not a bug, but I
thought I'd warn everyone:
While a program is running, it's inode is marked in use. Thus if you
delete a running command, it seems to be gone, but the file is still
there (standard unix practice). Sync a thousand times, and the file
will still not be really deleted until the inode no longer is in use:
This may not happen if the file was /bin/update or /bin/sh.
The result is that if you reboot with a deleted file in use, fsck will
wanr about a lot of unused blocks that are marked in use. No problem,
'fsck -a' repairs it, and it /really/ isn't a bug, it's just that we
haven't got something like shutdown yet that sees to these kinds of
problems.
Linus
Original post in KCLUG archives
Subject: policy for accepting patches to 0.12 Date: Wed, 15 Jan 1992 22:09:37 +0200 From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
Ok, I forgot to mention this in my last post, but I'm afraid I'll have
to warn all of you that want to implement a new feature: I will not
accept big non-localized patches to 0.12. This doesn't mean you cannot
implement something neat, but it does mean that it probably won't be in
0.13 unless it's so neat I cannot live without it.
There are good reasons for this: I'll have to do some studuing that I
missed the last semester due to working on linux, and the courses start
tomorrow. That was one of the reasons for the fixed release-date of the
current version.
Also, VFS support (which is missing in 0.12, although there were
alpha-patches for it) will probably be implemented for 0.13, and I need
a relatively clean kernel for that: as pmacdona found out, the patches
that get in put after other patches have to be extensively edited to
fit.
This does NOT mean that I won't accept bug-reports and patches. Also,
it doesn't mean I won't accept the init/login package: I assume that
won't touch the kernel very much. I hope this won't be a big problem:
most of the things people wanted are in 0.12. And with VFS we'll
eventually get the longer filenames that was also high on the list of
wanted things.
Linus
Original post in KCLUG archives
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Linux Information Sheet Date: Sat, 18 Jan 1992 04:36:50 GMT
LINUX INFORMATION SHEET
(last updated 13 Jan 1992)
1. WHAT IS LINUX 0.12
LINUX 0.12 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.12 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
- Virtual memory: swapping to disk when out of RAM
- POSIX job control
- virtual consoles on EGA/VGA screens
- pty's
- some 387-emulation
- 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 4 MB is a good idea.)
- 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.12
- 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-request@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:
- A virtual filesystem layer
- STREAMS
- init/getty/login
- Interprocess communication
- IEEE POSIX P1003.1 / P1003.2 compatibility
- SCSI support
If you want to help, join the mailing list.
Original post in KCLUG archives
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Subject: Re: Mach? Date: 19 Jan 1992 10:50:29 GMT
In article <ANLHILLE.92Jan18184427@cochiti.ucs.indiana.edu> anlhille@arapahoe.ucs.indiana.edu writes:
>Does Linux use Mach as it's kernel? I don't know how hard it would
>be, but I would think it would save steps and lead to higher
>compatibility in the long run.
Linux does not use Mach, nor any other pre-existing kernel. Is
completely written by Linus Torvalds (+ collaborators, from the
Linux-activists mailing list (which this newsgroup tries to replace for
people with news access)).
I don't think saving steps has been a guiding priciple for Linus. In
fact, I secretly think he started the project because he got tired of
playing Prince of Persia (or something like that, I never bothered to
take a look at the game).
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: V86, echo, *P=NULL etc updates Date: 23 Jan 1992 11:25:40 GMT
Replying to questions (mostly from the mailing-list - I'm trying to move
over to alt.os.linux):
> V86-mode and DOS sessions under Linux?
Right. Seems everybody wants these, but the problem is that Linux wasn't
designed with V86-mode in mind, and the memory management makes some
assumptions that are simply incompatible with V86 tasks. The problem is
that a V86-task /has to/ be at virtual address 0-1M, and doesn't care
about the current linux protections scheme that uses segments. All right
so far: but the current kernel also lives in that space. Ooops.
This means that either (1) the mm has to be totally rewritten, (2) we
resort to ugly tricks with changing IDT's and page tables by hand, or
(3) I come up with something clever.
(1) has several problems: the current mm may not be a work of art, but
it /does/ have the good point of working, and it's extremely simple.
Changing the mm to something more like "real" unices would complicate
things. I don't feel this is a good option.
(2) The "ugly" tricks needed are so ugly I'm probably going to have
nightmares just because I thought about them. Trust me: you don't want
DOS compatability that bad.
(3) is of course optimal: the problem is that the I want:
- the first 16 megabytes to be "identity mapped" to the physical
memory. This is one of the reasons the mm is so simple (and there is
no need to translate DMA addresses etc)
- the first megabyte (+64kB) would have to be paged memory for the V86
mode (with all the current frills: demand loading, VM etc).
And these two things don't mix very well. So I thought V86 would have to
wait.
Things aren't really that bad: I brainstormed a little, and I think I've
got the problem solved by using segments and paging at the same time to
make the first 16M /look/ identity mapped, although they aren't. It's
not even going to be very ugly: just a few hacks, that could be said to
be "interesting". I'm not promising anything, though.
> [ echo command ]
No, there is no echo for linux. Not that big a problem: use
#! /bin/sh
echo $*
or port (or write) something in C if you wish. Using a shell-script
isn't that bad: it probably doesn't use much memory, as most of the
pages get to be shared.
> I get "*P=NULL" printed on the console.
Right. This is a debugging message: the sleep-function changed
behaviour in 0.12, and I added a few sanity checks. This message just
means that something is sleeping/waking up without using the proper
routines: I don't know where this happens, but at least it's harmless.
If you know something that consistently brings up this message, I can
probably track it down. I have seen it once, and didn't notice what
caused it.
> mvdir/rename system call
As already mentioned, it doesn't exist. Yet. I'm coding it right now,
and it will work today on my machine (I think), and by the weekend, I
should be able to send out (minor) kernel patches to get it working for
those that want it. I hope.
> Shared libs
Seem to work. The kernel features are there already (even in the
released 0.12), and pmacdona an I have made some simple scripts/programs
to create shared libraries from the current unshared ones. Small
utility programs usually shrink to half their size, but my guess is that
debugging programs using shared libs will be impossible even when we do
get a debugger. I think the 0.13 root-image will contain the first
"real" use of shared libraries.
> Linux-0.13
I still don't know when this will be out: it depends on several things.
Don't try to get TCP/IP, sockets and X all working in time for it - I
think it's going to be released February (mumble mumble 20?)th, and I'm
totally satisfied if it just adds the higher-level routines for VFS and
minor fixes (faster floppy, rename, one totally unnecessary panic-call
etc) and a init/login (I'll use the simple version available already if
the "real" version doesn't get implemented).
Mail me about anything bigger you have already started on: we'll try to
work something out.
Linus
PS. I still try to reply to all personal mail the same day I get it, but
I know I've missed some (not many though). My mail-box grows by about
30-70 messages per day, so I definitely don't have time to go back and
check them out. Re-mail any questions/suggestions if you don't hear from
me.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: shared libs Date: 23 Jan 1992 19:59:46 GMT
In article <FISCHER.92Jan23191836@solsort.iesd.auc.dk> fischer@iesd.auc.dk (Lars P. Fischer) writes:
> Yeah, debugging with shared libs can be a pain. I believe it's
> important to have the option of doing a static link, just as you can
> compile without optimization if need be.
Yes, the shared libs are optional: change the libc.a and crt0.o files
and you can choose between shared/unshared libs. There weren't even any
changes to the compiler/linker: the shared libs are misusing the linker
a bit, but it works.
> The SunOS system of having shared libs with
>version numbers is also a good idea -- makes it possible to update a
>library withput messing up programs using the old version.
Right. Even this is handled "correctly" in linux: it would be even
better with hardcoded addresses in the shared lib, but that was too much
work, so we settled for version numbers. It's going to be interesting
to see if the linux approach to shared libs even closely resembles
anything else: neither I nor pmacdona had any actual references to how
they "should" be implemented.
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: V86, echo, *P=NULL etc updates Date: 24 Jan 1992 11:37:09 GMT
In article <1992Jan23.210023.4021@smsc.sony.com> mb@smsc.sony.com (Michael Burg) writes:
>
>A V86-Task doesn't physically have to reside below the 1MB region.
No, but it /does/ have to be at VIRTUAL address 0. Thus it IS a special
task: all other linux tasks are given 64M slices of the 4GB address
space, and can use segments to keep them off each others (and make them
beleive they are at address 0). Not so a V86 task. Other unices
haven't got this problem, as they use a flat 32-bit address space, and
change page tables when they change tasks: linux doesn't. This has some
problems, but I'm willing to bet that linux has the simplest mm of any
unix that implementes paging/sharing/demand-loading/VM on a 386. And
frankly, simplicity is the name of the game when you try to implement a
kernel from scratch.
I like the 386 chip (but x86, x<3 are pure sh*t, gimme 68k any day), but
there are two problems with it: write-protected pages are ignored in
kernel mode (corrected in the 486), and V86 cannot be relocated to an
arbitrary virtual address. That's ok if you use only paging to
implement memory management, but frankly, I'd like to see something
where V86 can live /inside/ a 386-segment. Remember: linux isn't really
unix: it's a operating system I wrote with the unix API in mind, and I
didn't do it the same way everybody else did.
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: linux/mm/memory.c Date: 25 Jan 1992 10:54:53 GMT
In article <TYTSO.92Jan25002639@SOS.mit.edu> tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
>
>Am I correct is suppose that a consequence of this is that every single
>dirty page of the parent has to be swapped in during a fork()? If so, I
>wonder what sort of hit you will take when something like GNU emacs
>fork()'s. (My GNU emacs on my Vax 3100 workstation is currently
>weighing in at 5.4 meg.)
Yes. This is bad, but not /that/ bad: linux only swaps /dirty/ pages: I
doubt the GNU emacs eceutable pages get dirtied, and are thus just
reloaded by the demand-loading mechanism (and nothing happens at the
fork()). But yes, when editing big files (where there are a lot of
dirty pages) will force a swap-in.
Swapping was added as a quick hack: it wasn't really meant to extend
virtual memory to really big values - more just to get gcc working on a
2M machine, and have that small extra memory when your executables don't
quite fit. More like a temporary "panic-memory": it linux swaps on a
more regular basis the algorithms should be changed to something better
as well, they are rudimentary right now..
Linus
Original post in KCLUG archives
From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: random historical lore (directory locations, sync) Date: 28 Jan 1992 17:38:48 GMT
A couple of questions in this group are related to Unix history that
it seems worth explaining:
At some point somebody asked about doing sync more than once.
Traditionally before taking down a system people type sync three
times. There is actually a reason. The first sync simply scheduled
all dirty blocks for writing. But it didn't wait for them all to be
written. However a second sync would block until the first one had
finished, i.e. all dirty blocks had actually been written out. So if
you wanted to make sure the disk was up to date, you had to do two
syncs. Why 3 rather than 2 I couldn't say though.
Recently somebody was asking where to put binaries. The question was
whether to abandon the distinction betweeen /bin and /usr/bin, as
SunOS has done. I'm not sure what I think, but let me suggest reasons
why the current structure might still make sense. In older systems, I
can think of two reasons for having separate /bin and /usr/bin: (1)
Because non-BSD systems search their directories linearly, you don't
want a commonly used directory to get too big. By putting the most
common programs like "ls" and "pwd" in /bin, you avoid having to
search through a single huge directory. Indeed the suggestion is that
no directory should be allowed to grow too large, so if you have lots
of utilities, splitting them into /usr/bin, /usr/gnu/bin, etc., might
make sense. (2) Most Unix systems had more than one partition. The
root partition was kept small, and had only the most essential files
and programs. The idea was to minimize the likelihood of file system
damage on root in a crash by keeping it small (and ideally having no
files on it that changed regularly -- /etc/wtmp and /etc/utmp of
course violated this, but they could be symlinks to /usr/adm).
However the root file system should have all the tools that would be
needed in doing file system diagnosis and repair, so that if /usr was
damaged, you could fix it with tools on root.
SunOS ended up getting rid of /bin, making it simply a symlink
to /usr/bin. There were several reasons for this:
- under BSD, the directories are not searched linearly, so
you can handle bigger directories.
- /usr is intended to have only things that don't change, so
it can be mounted readonly. Since nothing on it is
changing, there isn't much chance of file system
damage in a crash. Thus tools are actually safer on
/usr than root, even through /usr is bigger. This was
a consequence of the split into /usr and /var, which
was done to allow readonly mounting of /usr.
Linux is probably closer to a traditional Unix system than to SunOS.
It does search directories linearly, and /usr typically has files that
change. Thus the original arguments for a separate /bin still make
sense. In fact there's now a new one: for ease of installation and
diagnosis of damaged disks, you really want to have a reasonable
subset of software on a floppy. I'd suggest that having /bin be the
utilities that we want to be on the floppy, and /usr/bin be everything
else. I do not suggest using /sbin. /sbin is really only software
for use in single-user or during boot. It's not normally even on the
PATH, so it would typically contain duplicate copies of essential
binaries (except maybe for init, which is only needed during boot).
You only need it if you get rid of /bin and move all executables to
/usr/bin. I don't think that's something we need to do.
By the way, I'm against using /usr/local/bin for standard system
software. The whole point of /usr/local is that it's an area for
software supplied by the site. The separation makes new releases
easier to install: you can just replace /usr/bin with the contents of
the new release. Since everything installed by the site is on
/usr/local, blowing away /usr/bin and replacing it with software from
the new release won't hurt you. Having standard parts of Linux be on
/usr/local defeats the purpose: /usr/local is local. No operating
system vendor should ever put stuff there.
Also, I'd like to put in a plug for avoiding the Gnu convention of
starting everything with g's. When I put up the man pages, I noticed
that the man pages had the Gnu names: gcp instead of cp, grm instead
of rm, etc. This makes sense in the usual Gnu environment. Since
there isn't yet a GnuOS, most Gnu utilities are optional extras which
will coexist with standard utilities from the vendor. Then "cp" is
the normal system "cp" from Sun or whoever, and gcp is the Gnu
version. But for Linux, the Gnu utilities are the the basic ones that
come with the system. Thus they should be given the basic names. I
don't really want all the commands to start with g.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Gnu make & gas porting problem! Date: 1 Feb 1992 10:03:38 GMT
>hcg6805@uxa.cso.uiuc.edu (Heien-Kun Chiang) writes:
>: Hi there:
>:
>: I am trying to port Gnu make and gas to linux without much success.
>: There was no problem in compiling Gnu gas but in the linking phase Gcc
>: complained it couldn't find the library 'libg.a'. I searched the Gnu ftp
>: sites and couldn't find 'libg.a', could anybody points me out where to find
>: it.
As has already been noted, libg.a is used only for debugging, and linux
doesn't support that very well (understatement of the year: I've
sometimes used 'od -hx' on the binaries to find bugs :). The fast fix
is not to use -g, the real fix would be to make a libg.a. Anybody
willing to look into debugging?
>: When compiling Gnu make, the compiler said 'couldn't find <nlist.h>', and
>: quit. Have anybod succeded in porting them.
Well, the make for linux is some older version of GNU make (not /that/
old: 3.60, I just checked), so I know it's possible to compile it... I
think nlist is only used for load average calculation, and linux doesn't
support that anyway, so add a -DNO_LDAV (or something like that) to the
Makefile. I think this is also the reason make seems to be wanting to
be installed as suid root or something.
Sorry for being vague - I've had to delete some of my sources to get
other things to fit, and the sources to make was one of the things that
went overboard.
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Help! My filesystem is *censored*, and fsck -a doesn't help! Date: 1 Feb 1992 16:23:40 GMT
In article <1992Feb01.102951.25667mrs@netcom.COM> mrs@netcom.COM (Morgan Schweers) writes:
>Greetings,
> The messages coming up are: "Zone X: in use, counted=0"
>
> And a comment about a directory which is missing both it's "." and
>its ".." directories. (Moreover, I can't remove said directory.)
Right. fsck (and no, it's /not/ filesystem f*ck :) doesn't try to remove
directories even when they look bad - it wouldn't be too hard to do: do
people think this would be a good idea (possibly handled by a new flag)?
This is one reason why I like multiple smaller partitions: fsck isn't
that reliable a way to clean up things, so I'd rather copy all the files
that are salvageable onto another filesystem, and clean the bad one up
by way of "mkfs". fsck is better at just simple problems, and to find
out that things are wrong.
> Worse yet, there's a constant process (init) which is writing to a
>file named 'annoy.log', as part of my debugging, and I didn't realize
>at first that this might ('might' hell, WOULD!) interfere with fsck.
Yes, /very/ bad idea. I use fsck -vs quite often to just see the general
state of the filesystem, and that is guaranteed not to worsen things: it
doesn't even try to repair things. Using 'fsck -a' is really something
that should be avoided, and it should definitely /not/ be done while
anything is writing to the disk (including piping the output from fsck
itsel to a file, as you found out).
> fsck -a didn't do ANYTHING for the Zone messages. I managed to
>dealwith all of the "Zone X: not in use, counted=1" errors by removing
>files that I guessed were causing problems.
Ok, this one seems like a bug in fsck when repairing: I'll take a look
at it. Fsck repairing is somewhat untested: I never get filesystem
errors (but then I'm careful.. syncing by hand often just in case...),
unless I'm testing out new features.
> In general, my filesystem seems to be okay, but *SOMETHING* is
>fucked somewhere. I can't recover the directory that has been
>trashed, and I'm not sure what files have lost sectors...
The best idea is to backup onto another partition (or using tar to
floppies) .. then mkfs and copy back. I'll look into fsck, but even if
I got these particular things to work all right, the back-up strategy is
still the best one - fsck will never be /that/ clever that it cannot
f*ck up sometimes.
Those of you with minix fsck could try to use that (won't work if you
use symbolic links: minix fsck doesn't understand them), as that one is
a lot more tested. It gives you no end of "mode not cleared" messages,
but other than that it's ok. I've used linux mkfs since I wrote it, and
it has cleared up my minor problems (when I implemented symlinks I had
some /major/ bugs the first time but fsck worked ok), but that doesn't
mean it's totally safe yet.
Linus
Original post in KCLUG archives
From: nolan@tssi.com (Michael Nolan) Subject: linux being uploaded to GEnie unix RoundTable Date: Mon, 3 Feb 1992 07:07:45 GMT
I've started uploading the linux information and files to the unix RoundTable
on GEnie. I posted a couple of messages asking for interest, and got quite
a few replies. I may have to upload the more important patches as well,
along with the highlights from alt.os.linux. Now all I need is to get
one of my 386's freed up so I can work with it myself! :-/
Original post in KCLUG archives
From: entropy@ee.WPI.EDU (Lawrence C. Foard) Subject: X and named sockets Date: Tue, 4 Feb 1992 03:20:09 GMT
If someone is planning to work on X please write to me, I should have
something functionaly equivalent to named sockets very soon although
I've decided to do a few things differently (and make compatibility
libraries later), I really need to talk to people who need to use these
to make sure they will do everything that is needed.
I've designed the interface to be equivalent to what TCP/IP will require
so code written and tested on these will work with only minor changes over
a network.
I started to port the BSD socket code only to find that I would have to
implement a large quantity of BSD specific kernel stuff (yuck), write
compatible kernel sockets from scratch (ick) or make a much simpler and cleaner
interface and use socket compatibility libraries. Given this choice
compatibility libraries seem to be the more logical option since free ware
ones already exist and can be adapted once the kernel stuff is there to handle
them.
I've decided in to leave room open for "random access" sockets in the kinder
and gentler kernel code, so hopefully this will make for a less kludgy system
in the long run. This also means that something will be working in days rather
than weeks.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Serial support Date: 4 Feb 1992 13:40:47 GMT
In article <Feb.3.23.55.22.1992.9885@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>I think the problem is that the interrupt level code calls the streams
>processing, and finishes with a character before sending EOI and
>dismissing the interrupt. [ deleted ]
This is how 0.13 will do things: my current driver just sets a bit (this
is part of the better timer-routines I wrote just for things like this),
and the characters are then processed under the timer interrupt. This
way, we still get instant echoing (well, it waits for the timer-intr,
but that happens fairly often: 100 Hz), but we don't get the
copy_to_cooked() function call several thousands of times a second with
speeds > 19200.
The current linux still has a limit of 2kB of buffer, so if the
characters aren't read out of the buffer fast enough, you still lose
characters due to buffer overrun. Also, linux doesn't support the 16550
chip in buffered mode: I don't have the hardware.
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Deadline for 0.13 Date: 4 Feb 1992 14:27:32 GMT
Ok, once more a new release seems to be in order: as far as I know I
should get the VFS patches in a week, so I'll probably be able to come
out with linux version 0.13 late February or early March (I'd guess
March).
The new version will be the first one where most of the patches weren't
written by me: nice going. As far as I can see, the new features of 0.13
will be:
- virtual consoles patches: these are already in place in my kernel, and
I'm happy to report that the scrolling speed is impressive once more.
The VC's should also work on other than EGA/VGA's although there might
be small problems still (I've been unable to test it, but I haven't
changed the patches very much).
- VFS. I haven't seen this yet, so I cannot say anything about it. I
expect longer filenames will be in 0.14 (April-May?).
- Floppy patch. This one I haven't yet even stared on, and I'll probably
work on it a bit, but I'll expect floppies are much faster in 0.13.
- The swapon-patch to swap from the filesystem. I've applied this one,
but I expect it will have to be changed for the VFS, and I'll have to
work on it a bit (making the swap-pointer buffer dynamic etc).
- minor (but pretty important) fixes like the incorrect error code from
a read past the end of a device, non-blocking IO on pipes/ttys etc.
+ some fixes by me: changes in the serial interrupts and removal of some
races with the VM etc.
Additionally, I guess one of the init/getty/login packages should be
included this time: if you have a working init/login, please mail me
(not the full thing, just mail me /about/ it). Size is somewhat an
issue: I want to fit it on the floppy with all the other programs.
I still haven't applied the lp-patch, and I'll try to do that one too:
but I don't have a printer, so I'm not really motivated ...
Additional patches will be received until a **** deadline of February
15th ****: if you think you have a neat patch, but cannot get it ready
for that, you can try to mail me about it. We'll work something out (or
then you might have to wait for the next release). Note that even
patches received before the deadline might not make it if I have some
good (or not so good) reason for it.
==========
That said, over to other (but related) business: future releases. A
couple of points:
- linux starts to get ready to be called version 1.0. It's not perfect
(and never will be), but it's useable on many machines. I like being
able to call it beta (and it /does/ warn people that there are bugs),
but I guess it isn't really so much beta after two more releases. I
don't think it has to be able to run X etc before we can call it 1.0: my
original goal was to run gcc (one of my personal tests of a system), and
that I did under 0.01.
- I'd also suggest we move away from me as the upkeeper of linux: my
resources start to get thin. Maybe not right now, possibly not for the
next release, but perhaps by summer? When SCSI (and even things like
printer support) means I cannot test the patches out, things won't work
very well any more. I'd like to hear some discussion on this (moving
1.0 to be under rcs, and some "linux-kernel" mailing list for patches
and discussions on the "canonical" system etc)
- I hope people calm down in the feature-hunting: linux still needs some
things (sockets/named pipes, a better fs), but I'd like to keep linux
small ("keep" doesn't mean I will fight anyone if he wants to make a
"super-linux", it just means I think /I/ cannot support it). If linux
grows much more, ast's comments will actually mean something: I admit
that keeping up a big kernel without any underlying design philosophy
(other than "get it working") probably won't be worth the result.
Linus
Original post in KCLUG archives
From: entropy@ee.WPI.EDU (Lawrence C. Foard) Subject: pipes Date: Thu, 6 Feb 1992 08:18:40 GMT
For one way pipes I think I greatly prefer the old Linux way to the standard,
with one way pipes all you care about is the fact that the data will get from
one end to the other. Completely satisfying reads accomplishs this with the
least overhead, not to mention that it allows you to use read rather than
fread reliably.
NOS:
I thought someone said that it was restricted to educational use or something
like that?
Another problem I have with using NOS, I really think network support has to
go in the kernel, there are just to many things that require TCP/IP to be fast
(X,NFS,etc.). Many other things should run as user processes but I think file
systems (except for specialized ones), device drivers and networking really
need to stay in the kernel. Eventhough Tanenbom (sp?) flamed Linux for the
monolithic kernel the real effect is that people switching from Minix to Linux
have seen large speed ups.
VFS:
Will this help to resolve the problems of having to update a number of tables
when adding a new device? The BSD file system code seems to have a somewhat
"object oriented" design where the file table contains function pointers.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: References for info on 386 and AT architecture. Date: 6 Feb 1992 09:47:57 GMT
In article <1992Feb05.183836.16346thinman@netcom.COM> thinman@netcom.COM (Lance Norskog) writes:
>
>The Intel 386 hardware books are ridden with typos,
>or so I have been informed by someone who wrote software
>for an embedded 386 gizmo.
The best book around is definitely "Programming the 80386" by John H.
Crawford and Patrick P. Gelsinger. It contains everything, and doesn't
seem to have typos (not so you'd notice at least) - it may be a bit
overkill if you just want to learn the user-space assembly language, but
if you are interested in segment descriptors, pagine etc I can recommend
it: without it, linux probably would never have been written.
Sybex books, ISBN 0-89588-381-3
Re: AT-hardware books. There aren't any good ones around. Thom Hogans
book contains /some/ info, but it's usually not what you want. Peter
Norton is a joke. Most books seem to assume you have access to the
BIOS, even though they call themself "advanced" "hardware" or whatever.
If someone can find a book that (a) even mentions the weird 386-387
coupling in an AT (no, it's not the intel standard way) or (b) doesn't
contain pages and pages of totally useless BIOS entry-points, I'd be
very much interested. (Sanches & Canton: IBM microcomputers: A
programmers handbook is better than most, but cops out when it comes to
harddisks etc)
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Lock-ups, init/login Date: 9 Feb 1992 19:12:22 GMT
Ok, there has been some talk about lock-ups with linux: notably when
doing big compiles (linking gnu-emacs etc) or when having several
programs running under the VC's. The only solution has been to reboot
with ctrl-alt-del, and this has mostly resulted in a more-or-less
destroyed filesystem (the problem is compounded by the fact that these
lock-ups happen just when you are running the most memory-intensive
programs, which often write to the disk as well). Happily this doesn't
happen very often (I haven't got many reports about this).
As far as I've been able to find out, the problem isn't a filesystem
problem (directly that is: the filesystem is just the first casualty
after a reboot) - it seems to be directly linked with memory usage.
When linux gets low in memory, it doesn't just give up and terminate the
process: it tries to swap things out (even on a nonswapping system it
can swap executable pages out - they can be demand-loaded back when
necessary).
This is mostly good: it allows programs to run to completion even after
the memory really got totally used up, but it doesn't cope too well with
programs that don't want "just a couple more pages", but a /lot/ of
them: it might eventually give up with a "out of memory" error and
terminate one of the processes, but it seems linux stubbornly tries to
run some programs when it thinks it can juggle the pages, but in reality
the program is just totally trashing between 2 or more pages (one single
machine-insns can result in several page exceptions).
Even update doesn't get the time to run, and the result is a machine
that seems totally dead, and won't sync. Not good (understatement of
the year). If somebody (who knows about swapping etc) has some
constructive ideas of how to solve the problem, I'd be interested: right
now I don't want to release 0.13 before this is solved. My current idea
is to look at which pages have recently been swapped out, and if linux
notices that one page gets swapped out/in all the time, it just kills
the process. I'll get it solved: I just wanted to warn people that this
problem does exist.
Then over to other things:
> floating point with gcc.
Yes, gcc floating point stinks (not gcc's fault). The library is
incomplete (doesn't even handle add with floats, you have to use
doubles), but there are better times ahead: hlu@eecs.wsu.edu re-ported
gcc without the soft-float hack needed for earlier versions of linux,
and I hope all the problems will go away: people with 387's will finally
get to use them automatically, and the kernel 387-emu should make it
possible to run the same programs (albeit not that efficiently) without
any ugly soft-float libraries. The first reports seem positive.
> init/login.
Oh, well: I asked this before, and I even got some replies. Sadly I've
misplaced most of them. I have one init/login by poe@xxx.xxx, and that
will be the one I use unless somebody else comes up with something even
better. If you think you have the ultimate (well...) init/login, mail me
about it (preferably with a subject like: "init/login"): tell me how to
get it, what it does, and possible problems.
> deadline for 0.13
is still on February 15th.
Linus
Original post in KCLUG archives
From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: KA9Q tcp is now available Date: 10 Feb 1992 05:28:40 GMT
I've put KA9Q on athos.rutgers.edu:/pub/linux, as ka9qbin.tar.Z and
ka9qsrc.tar.Z. The READ.ME in the binary is as much documentation as
I have. This is the pre-NOS version, with compressed SLIP and bootp
retrofitted. The only major missing feature is the domain name
server. I ran out of time. I also suspect it might be better to port
NOS rather than spend more time on this version.
Unfortunately, this depends upon at least two kernel patches:
nonblocking I/O and the select fix posted earlier today. Also, on my
machine I've seen the serial output hang when using KA9Q. serial-hang
is a workaround for this. I believe Linus is working on a better fix.
Mine is sort of questionable if you have more than one serial line.
I've tried to do the best I can with performance tuning. I use
select, but in a way different than the optional select support in the
original code. I'm getting as good response as with the version that
sits there in a continuous loop waiting for input, but it doesn't use
as much CPU.
I've only tested this is a SLIP configuration. It's unlikely to be
useful with Ethernet, as that requires kernel support. It might work
with the AX25 and other stuff that sits on a serial line, though my
patches could conceivably have broken something. If so, the fix
shouldn't be major
I'm not sure where to get documentation for this version. the READ.ME
in the binary version has a list of commands, but that's no
substitute for real documentation.
Original post in KCLUG archives
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) Subject: Re: OK, OK, I get the message! Date: 10 Feb 1992 23:23:47 GMT
In article <1992Feb10.155653.1@cc.curtin.edu.au>
nmurrayr@cc.curtin.edu.au writes:
>using Linux v0.12 (BTW, is it pronounced line'-ux or linn'-ux?).
I'm not an expert on the subject, but I think the pronounciation depends
on whether you speak Swedish or not :-)
The way Linus pronounces it (as far as I can remember at this moment,
he'll flame me if I get it wrong, I'm sure), is that the 'lin' part is
pronounced like the 'lin' of linen. The 'ux' part is more difficult, it
probably is the same sound as you would use if the first part would be
pronounced 'line'.
Perhaps we should get Linus record it on audio tape, and sell those
tapes :-)
Original post in KCLUG archives
From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: new copy of KA9Q TCP/IP Date: 16 Feb 1992 08:28:25 GMT
I've just put up new copies of ka9qbin.tar.Z and ka9qsrc.tar.Z in
athos:/pub/linux. The primary difference compared with last week's
copy is that I've done a lot more testing and bug fixing. I've also
revised the READ.ME in ka9qbin.tar.Z, to give a bit more advice about
configuration, and added (primitive) domain name server support.
Here are the primary bug fixes:
cd and pwd now work
"tcp mss" used to affect only outgoing but not incoming connections
there was a bug in header compression that would cause connections
to hang when sending files with a small mss
there was a bug in the IP code that cause cause bytes to be missing
in files retrieved via ftp.
This is all the work I plan to do on KA9Q for the moment. The major
problem now is really in the kernel: the tendency to lose characters
coming in one serial lines.
By the way, I've been doing a lot of file manipulations today, and
have had no hangs or file system problems. I begin to think Linus is
right that the apparently file system problems are really memory
management problems. I made them go away by allocating a swap
partition, which I hadn't been using before.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: mmap & shared memory Date: 16 Feb 1992 11:32:31 GMT
In article <1992Feb14.144302.8897@daimi.aau.dk> tthorn@daimi.aau.dk (Tommy Thorn) writes:
> What's status for shared memory? I'd suspect that
> about the same interface in the kernel is needed
> to provide both. I'm willing to dive into it,
> but suspect others must be doing something similar
> (shared libs.)
Well, shared libs aren't using shared memory (oh, they share pages if
they can, but basically the shared libs are just a "secondary
executable" loaded at the 60M mark in the process space). To my
knowledge nobody else is working on shared memory.
Shared memory should probably be relatively easy (from the page-sharing
point of view: you'd have to keep track of it all, of course): I did
think about it when I wrote the mm. The problem with this (and so many
other things) is that I've never used the shared memory syscalls, so I
don't feel I'm the right person to implement them: I wouldn't see a bug
if it hit me on the head with a sledgehammer, as I wouldn't know the
expected behaviour.
Linus
Original post in KCLUG archives
From: jwinstea@jarthur.claremont.edu (Jim Winstead Jr.) Subject: More stuff at TSX-11 Date: Fri, 21 Feb 1992 03:06:08 GMT
A while back I uploaded a new set of the GNU Text Utilties to TSX-11,
with the fixed sort, so if you've still got the bad sort from the
previous upload available, you will want to at least grab the seperate
sort that has been uploaded. If you're looking for all the neat GNU
text utilities (such as sort, cut, paste, join, head, tail, wc, cmp,
and most of the other basic text filters on unix systems), just grab
tsx-11.mit.edu:pub/linux/binaries/usr.bin/text-1.1.tar.Z
I compiled the GNU bc utility, which is "an arbitrary precision
calculator language," and is part of the POSIX draft standard. It
appears to work fine, but I'm open to criticisms.... Find it as:
tsx-11.mit.edu:pub/linux/binaries/usr.bin/bc.tar.Z
Next, I compiled the GNU fgrep for Linux. It's not part of POSIX
(since it duplicates (e)grep to a large degree, but it is a fairly
fast, fairly small grep for those cramped for disk space or just
love having all sorts of extra utilties around. (It seems like my
Linux partitions are empty!) You can find it as:
tsx-11.mit.edu:pub/linux/binaries/usr.bin/fgrep.tar.Z
Lastly, I've been playing around compiling games/other fun stuff on
Linux lately, and I've come up with rain (BSD), larn (pd), and best
of all: worms (BSD), which I've modified to have _color_ worms! So,
worms and rain, at least, will show up on TSX-11 in the near future.
(Once I apply the color diffs to my system so I can fix worms' colors,
and fix a small problem with worms (it crashes mightily if you try
and tell it how many worms to use. Sigh.).) <- I've been programming
too much!
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: A couple of problems... Date: 24 Feb 1992 16:06:53 GMT
In article <1992Feb24.122225.2924@sbcs.sunysb.edu> kroe@sbstaff2.cs.sunysb.edu (KiYun Roe) writes:
>
>I think this hanging is easily the most serious deficiency in Linux,
>but I have made zero progress in identifying the cause. I hope Linus
>figures it out before he releases 0.13.
Yes, I think I've got it licked: it was /both/ a memory problem and a
filesystem problem. No wonder people have had hangups. Due to the
bugs, 0.13 might be a bit late, but I still expect it to be out about
March 5th or so..
The filesystem problem gets much worse when writing out the buffer-cache
to disk (several requests in the request-queue), and is especially
noticeable on slow devices (floppies and old drives). Writing big files
out to floppy is one of the ways you /might/ hang linux currently, but
it depends on a lot of factors. 0.13 will definitely have these bugs
corrected, I just hope there aren't other ones... Other than that 0.13
will be a relatively simple release: not very much new features, mostly
bug-fixes and kernel enhancements.
Re: system call overlapping - yes some of the system calls overlap, and
could be removed, but it's a real pain to recompile everything: I did
that when I implemented sigactions, and removed the old signal() system
call, and it wasn't fun. Not for the faint-of-hearted.
Linus
Original post in KCLUG archives
From: entropy@ee.WPI.EDU (Lawrence C. Foard) Subject: finally works :) Date: Mon, 24 Feb 1992 21:58:47 GMT
I finally had a free day to finish IPC. I've got tinymush working with it
so I'm pretty confident it will work for any demons. The only thing I'm not
sure about at this point is how to make it into a patch, I've got the old
virtual console patch, floppy patch and this all in the same kernel. If I do
a diff of the present kernel with the old (floppy+vc patch) kernel will this
work right?
Original post in KCLUG archives
From: anthony@csd4.csd.uwm.edu (Anthony J Stieber) Subject: Re: Networking 2 release, BSDI, etc Date: Sun, 1 Mar 1992 07:50:51 GMT
In article <1992Feb29.204246.11566@sunb10.cs.uiuc.edu> cs318a52@ibmb5.cs.uiuc.edu (Mark Lanett) writes:
>jim@ferkel.ucsb.edu (Jim Lick) writes:
>>The other future development is the Gnu OS based on their 'Hurd'
>>kernel. No telling when this will be out though.
>Actually, the "GNU OS" will be a gnu filesystem (HURD) running on Mach
>(the unix successor being developed by CMU).
Actually, the GNU Hurd is neither a kernel, nor just a filesystem. It
is a Hird of Unix Replacing Daemons (among other things) that include a
filesystem, ttys, and exec, proc, and authorization servers that the
Mach kernel does not provide itself. Mach is by itself just a nifty
little kernel and doesn't provide much of the functionality needed for
modern unix operating systems.
See ftp.gnu.ai.mit.edu for the GNU Hurd sources.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Linux 0.13? Date: 2 Mar 1992 01:31:47 GMT
In article <68076@netnews.upenn.edu> dsimon@eniac.seas.upenn.edu (Derron Simon) writes:
>When is version 0.13 scheduled to be released? I don't want to hassle with
>all the patches and updates to 0.12 so I'd like to wait until 0.13 if it is
>not going to be long from now.
I'm putting in the finishing touches this week: 0.13 should be out next
weekend at the latest (unless some new bug shows up), and I hope to get
it ready by Thursday. I'll definitely call it 0.95, making clear that
version 1.0 isn't that far away.
0.95 will have these features:
- faster floppy (based on cdiffs by entropy (Lawrence Foard), but I
didn't patch in the formatting code). Untaring from a floppy is no
longer a pain.
- VFS-stubs (based on cdiffs by proven (Chris Provenzo), but again my
version does not contain all of his code, and I added some changes of
my own too.)
- Better VC handling (works on other cards that EGA/VGA), thanks to
pmacdona (Peter McDonald). I think 0.13 finally contains most of the
VC code things: screen blanking, corrected vt100-codes etc.
- Swapon system call (swapping from files as well as block devices),
based on patches by Simmule Turner. This one needs some additional
work still.
- poe-IGL-1.2 (or close to it).
- ptrace (by Ross Biro) - not guaranteed, but I think we'll get gdb
working in 0.95.
- bugfixes and minor enhancements: file protections, nonblocking IO,
UK and Danish keyboards, rename etc.
Most of the patches have been heavily edited by me (indeed, very few of
them are patched in automatically with 'patch'), and not all of the
functionality of all the patches will be there. I've mostly written in
the patches by hand, so the author of the code will not necessarily even
recognize his own work. As with the VC patches, some of these patches
will probably evolve for a few releases before they get their final form
(especially VFS which was easily the biggest patch to date).
Changes that haven't been seen as patches that will be in 0.95:
- many minor corrections (rename corrected, ^S/^Q corrected, better (?)
buffer-cache handling, some corrected error-returns).
- lockup bugs (two of them) removed: I hope that was the last of them
(yeah, sure..).
- minor race-conditions with swapping removed (still not 100%, but
better, and I hope the "block already free'd" error should go away)
- TIOCxWINSZ works now.
- Harddisk changes: the second harddisk will be on minor numbers 64-127
instead of 5-9 as now. I also have some code there that hopefully
gets extended partitions right, but as I haven't been able to test it
I somehow doubt it works 100% ... The default harddisk names have
changed: here's a simple listing
new minor old minor
hda 0 hd0 0
hda1 1 hd1 1
hda2 2 hd2 2
hda3 3 hd3 3
hda4 4 hd4 4
hda5 5 (extended) - -
hdaX X -- "" -- - -
hdb 64 hd5 5
hdb1 65 hd6 6
etc
I'm guessing this will get some people confused, but the old naming
and numbering conventions were so bad as to be pretty unusable with
extended partitions. Fdisk currently doesn't understand extended
partitions: I'll try to get that corrected too.
Patches available now, but NOT in 0.95:
- printer port patch. I still haven't gotten around to this one, as I
haven't got a printer. So sue me.
- SCSI driver: didn't make it in time. I don't expect too many problems
applying the 0.12-patch to 0.95.
- mmap patch: not in time, and so specialized I felt there wasn't that
much of a hurry. Again, this patch should probably patch into 0.95
without undue problems.
So: I hope 0.13 should prove to be more stable, and more easily
extensible, but it will look mostly like 0.12 with a init/login. No
/major/ new features like in eariler releases: I hope that means linux
is getting more mature rather than stagnating :)
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Linux-0.95 Date: 8 Mar 1992 14:43:12 GMT
All right: it's three days late, but finally 0.95 has been sent to
nic.funet.fi. As usual, it will probably take a few days to find it's
way into a readable directory, so don't start ftp'ing right now. I'm
sure arl will inform people when it's available.
I'm also pretty sure there will be problems setting things up again:
some things have changed, and the docs are up to their usual wonderful
standard. For people that have used 0.12, there shouldn't be too many
surprises, although the new harddisk names/numbers can be confusing.
Many bugs have been corrected, but there are probably new ones that have
taken their place.
One bad thing with the new setup (which will confuse new users) is that
the rootdisk finally got too small for everything, and compress+tar
aren't on the disk any more. Talk about confusing, but if you have 0.12
installed on your system, everything should be mostly a case of "boot
from floppy, drop in the new things, and reboot with the harddisk".
Re: patches. There were 5 major patches (VC's, VFS, swapon, ptrace and
faster floppies) that were installed, and of these only ptrace and VC's
got installed without any major changes (pmacdona has had three releases
to learn my coding style, and it seems to have paid off :). The other
patches are so heavily edited as to be totally unrecognizeable, and I
expect my changes weren't always for the better: but I'd rather be
over-conservative than use a patch even if it's great. I expect they
will still have to be edited, and hope none of the authors mind me
changing their code heavily (sorry also to all those that have used the
VFS routines: they'll have to wait for the next release before getting
all the functionality in the alpha-VFS patches.)
Re: recompiling the kernel. I've used most of the last week to make the
kernel compileable by gcc-2, as that is what I use now. The bootimage
I've made available is compiled totally with 2.0, and the source-files
are set up for that compiler. For people without gcc-2, the kernel can
still be compiled with 1.40, but you'll have to add the flag
-fcombine-regs to some makefiles (without it gcc-1.40 runs out of
registers, and aborts).
I'm including the file RELNOTES-0.95, which is just the old 0.12
RELNOTES edited for a new release. I'm lazy.
Linus
==============================
RELEASE NOTES FOR LINUX v0.95
Linus Torvalds, March 7, 1992
This is file mostly contains info on changed features of Linux, and
using old versions as a help-reference might be a good idea.
COPYRIGHT
Linux-0.95 is NOT public domain software, but is copyrighted by me. The
copyright conditions are the same as those imposed by the GNU copyleft:
get a copy of the GNU copyleft at any major ftp-site (if it carries
linux, it probably carries a lot of GNU software anyway, and they all
contain the copyright).
The copyleft is pretty detailed, but it mostly just means that you may
freely copy linux for your own use, and redistribute all/parts of it, as
long as you make source available (not necessarily in the same
distribution, but you make it clear how people can get it for nothing
more than copying costs). Any changes you make that you distribute will
also automatically fall under the GNU copyleft.
NOTE! The linux unistd library-functions (the low-level interface to
linux: system calls etc) are excempt from the copyright - you may use
them as you wish, and using those in your binary files won't mean that
your files are automatically under the GNU copyleft. This concerns
/only/ the unistd-library and those (few) other library functions I have
written: most of the rest of the library has it's own copyrights (or is
public domain). See the library sources for details of those.
INSTALLATION
This is a SHORT install-note. The installation is very similar to 0.11
and 0.12, so you should read INSTALL-0.11 too. There are a couple of
programs you will need to install linux: something that writes disk
images (rawrite.exe or NU or...) and something that can create harddisk
partitions (fdisk under xenix or older versions of dos, edpart.exe or
something like that).
NOTE! Repartitioning your harddisk will destroy all data on it (well,
not exactly, but if you know enough to get back the data you probably
didn't need this warning). So be careful.
READ THIS THROUGH, THEN READ INSTALL-0.11, AND IF YOU ARE SURE YOU KNOW
WHAT YOU ARE DOING, CONTINUE. OTHERWISE, PANIC. OR WRITE ME FOR
EXPLANATIONS. OR DO ANYTHING BUT INSTALL LINUX - IT'S VERY SIMPLE, BUT
IF YOU DON'T KNOW WHAT YOU ARE DOING YOU'LL PROBABLY BE SORRY. I'D
RATHER ANSWER A FEW UNNECESSARY MAILS THAN GET MAIL SAYING "YOU KILLED
MY HARDDISK, BASTARD. I'M GOING TO FIND YOU, AND YOU'LL BE SORRY WHEN I
DO".
Minumum files needed:
RELNOTES-0.95 (this file)
INSTALL-0.11 (+ any other docs you might find: the FAQ etc)
bootimage-0.96.Z
rootimage-0.95.Z
rootimage-0.12.Z (for tar+compress)
rawrite.exe
some disk partitioner
1) back up everything you have on your harddisk - linux-0.95 is still in
beta and might do weird things. The only thing I guarantee is that
it has worked fine on /my/ machine - for all I know it might eat your
harddisk and spit it out in small pieces on any other hardware.
2) Test out the linux boot-disk with the root file system. If it
doesn't work, check the hardware requirements, and mail me if you
still think it should work. I might not be able to help you, but
your bug-report would still be appreciated.
Linux-0.95 now has an init/login: there should be 4 logins started on
the first 4 virtual consoles. Log in as root (no password), and test
it out. Change to the other logins by pressing left-alt + FN[1-4].
Note that booting up with a floppy as root is S..L..O..W.. - the
floppy driver has been optimized for sequential access (backups etc),
and trashes somewhat with demand-loading.
Test that linux can read your harddisk at least partly: run the fdisk
program on the root-disk, and see if it barfs. If it tells you about
any partitions at all, linux can successfully read at least part of
your harddisk.
NOTE! Harddisk device names and numbers have changed between versions
0.12 and 0.95: the new numbering system was needed for the extended
partitions, and a new naming scheme was in order so that people
wouldn't cunfuse the old devices with the new ones.
The new harddisk device names are: /dev/hd followed by an 'a' for the
first drive, or a 'b' for the second one. After that comes the
partition number, 1-4 for the primary partitions, 5- for possible
extended partitions. No number means the complete disk. Like this:
/dev/hda the whole first harddisk (old: /dev/hd0)
/dev/hdb3 partition nr 3 on the second disk (old: /dev/hd8)
3) Make sure that you have a free /primary/ partition. There can be 4
primary partitions per drive: newer DOS fdisks seem to be able to
create only 2 (one primary and one extended). In that case use some
other partitioning software: edpart.exe etc. Linux fdisk currently
only tells you the partition info - it doesn't write to the disk.
Remember to check how big your partition was, as that can be used to
tell which device Linux thinks it is.
NOTE! Linux-0.95 /might/ recognize extended partitions: but the code
for this is utterly untested, as I don't have any of those. Do NOT
use the extended partitions unless you can verify that they are
indeed correctly set up - if my routines are wrong, writing to the
extended partitions might just overwrite some other partition
instead. Not nice.
4) Boot up linux again, fdisk to make sure you now have the new
partition, and use mkfs to make a filesystem on one of the partitions
fdisk reports. Write "mkfs -c /dev/hdX nnn" where X is the device
number reported by linux fdisk, and nnn is the size - also reported
by fdisk. nnn is the size in /blocks/, ie kilobytes. You should be
able to use the size info to determine which partition is represented
by which device name.
5) Mount the new disk partition: "mount /dev/hdX /mnt". Copy over the
root filesystem to the harddisk, eg like this:
# for i in bin dev etc usr tmp
# do
# cp +recursive /$i /mnt
# done
You caanot use just "cp +recursive / /mnt", as that will result in a
loop.
6) Sync the filesystem after you have played around enough, and reboot.
# sync
# lo
(none) login: sync
<wait for it to sync>
ctrl-alt-del
THIS IS IMPORTANT! NEVER EVER FORGET TO SYNC BEFORE KILLING THE MACHINE.
7) Change the bootdisk to understand which partition it should use as a
root filesystem. See INSTALL-0.11: it's still the word at offset
508 into the image. You should be up and running.
8) When you've successfully started up with your harddisk as root, you
can mount the older rootimage (rootimage-0.12) from a floppy, and
copy over any files you find there that weren't on the newer
root-image.
Mounting a floppy is easy: make the directory /floppy, and write:
# mount /dev/PS0 /floppy (if you have a 3.5" drive)
or
# mount /dev/at0 /floppy (for 5.25" floppies)
After that the files can be copied to your harddisk, eg:
# cp /floppy/usr/bin/compress /usr/bin
# ln -s /usr/bin/compress /usr/bin/compress
# cp /floppy/usr/bin/tar.Z /usr/bin
# uncompress /usr/bin/tar.Z
That's it. Now go back and read the INSTALL-0.11, until you are sure you
know what you are doing.
New features of 0.95, in order of appearance
(ie in the order you see them)
Init/login
Yeah, thanks to poe (Peter Orbaeck (sp?)), linux now boots up like a
real unix with a login-prompt. Login as root (no passwd), and change
your /etc/passwd to your hearts delight (and add other logins in
/etc/inittab etc).
Bash is even bigger
It's really a bummer to boot up from floppies: bash takes a long time to
load. Bash is also now so big that I couldn't fit compress and tar onto
the root-floppy: You'll probably want the old rootimage-0.12 just in
order to get tar+compress onto your harddisk. If anybody has pointers
to a simple shell that is freely distributable, it might be a good idea
to use that for the root-diskette.
Especially with a small buffer-cache, things aren't fun. Don't worry:
linux runs much better on a harddisk.
Virtual consoles on any (?) hardware.
You can select one of several consoles by pressing the left alt-key and
a function key at the same time. Linux should report the number of
virtual consoles available upon bootup. /dev/tty0 is now "the current"
screen, /dev/tty1 is the main console, and /dev/tty2-8 can exist
depending on your text-mode or card.
The virtual consoles also have some new screen-handling commands: they
confirm better to vt200 control codes. Special graphic characters, and
the PF1-4 keys work somewhat in the application-key mode.
Symbolic links.
0.95 now allows symlinks to point to other symlinks etc (the maximum
depth is a rather arbitrary 5 links). 0.12 didn't like more than one
level of indirection.
Virtual memory.
VM under 0.95 should be better than under 0.12: no more lockups (as far
as I have seen), and you can now swap to the filesystem as well as to a
special partition. There are two programs to handle this: mkswap to set
up a swap-file/partition and swapon to start up swapping.
mkswap needs either a partition or a file that already exists to make a
swap-area. To make a swap-file, do this:
# dd bs=1024 count=NN if=/dev/hda of=swapfile
# mkswap swapfile NN
The first command just makes a file that is NN blocks long (initializing
it from /dev/hda, but that could be anything). The second command then
writes the necessary setup-info into the file. To start swapping, write
# swapon swapfile
NOTE! 'dd' isn't on the rootdisk: you have to install some things onto
the harddisk before you can get up and running.
NOTE2! When linux runs totally out of virtual memory, things slow down
dramatically. It tries to keep on running as long as it can, but at
least it shouldn't lock up any more. ^C should work, although you might
have to wait a while for it..
Faster floppies
Ok, you don't notice this much when booting up from a floppy: bash has
grown, so it takes longer to load, and the optimizations work mostly
with sequential accesses. When you start un-taring floppies to get the
programs onto your harddisk, you'll notice that it's much faster now.
That should be about the only use for floppies under a unix: nobody in
their right mind uses floppies as filesystems.
Better FS-independence
Hopefully you'll never even notice this, but the filesystem has been
partly rewritten to make it less minix-fs-specific. I haven't
implemented all the VFS-patches I got, so it's still not ready, but it's
getting there, slowly.
And that's it, I think.
Happy hacking.
Linus (torvalds@kruuna.helsinki.fi)
Original post in KCLUG archives
From: abc@banjo.concert.net (Alan B Clegg) Subject: Linux File System Document Revision 1.0 Date: 9 Mar 1992 14:33:45 GMT
Before I get a flamefull response, let me tell everyone that this document has
been through several revisions, and is currently at a point that has pleased
most people. Please note that it is a *GUIDELINE* and is not *REQUIRED*, but
if most people follow the guidelines, we all get along a lot better.
If you have comments/questions about this document, and you are not on the
linux-standards mailing list, I would ask that you join the list. The request
address is: linux-standards-request@banjo.concert.net. Please try to keep
debate off the news group, and on the mailing list.
For those of you on the linux-standards list, the verticle bars in column one
represent the only changes from draft 2.
==== SNIP HERE ====
The following is being submitted by Alan Clegg [abc@concert.net] on behalf
of the Linux-Standards list as the standard for directory file structure
under Linux.
Revision 1.0
Complete implementation of this file structure is completely voluntary,
and will not be enforced, but will be recommended. This specification
is released as guidelines for people porting and writing software for
the Linux Operating System to allow easy software installation, upgrade, and
tailoring on already installed systems.
Root Directory:
Files:
{none defined by spec}
Directories:
bin dev etc home lib mnt usr
Rationale:
The root directory should not be cluttered with files or
directories, and should contain no user programs.
/bin Directory:
Files:
sh init mount umount dd cat ls fsck {and as needed}
Directories:
{none defined by spec}
Rationale:
The /bin directory should contain programs that are vital
to the restoration of other file systems in the case of
a corrupting crash. No executable in /bin should require
any other file system to be mounted to execute correctly.
/dev Directory:
Files:
{device files}
Directories:
{none define by spec}
Rationale:
Standard UNIX device files. This directory should contain
device entries for all devices that are supported in the
standard kernel, even if the hardware device does not exist
on the system.
/etc Directory:
Files:
mtab passwd rc ttytab {and as needed}
Directories:
{none defined by spec}
Rationale:
Standard location of files required during system boot. Files
in this directory are usually system specific. Most will
| require human intervention during system upgrade. /etc will
| also contain administrative binaries that should not be in
| the normal users PATH.
/home Directory:
Files:
NONE
Directories:
{one per user excepting root}
Rationale:
Standard location of users home directories. Will most likely
be a mounted file system once the system is up. root's home
directory should be /.
/lib Directory:
Files:
{libraries required for system initialization}
Directories:
{none defined by spec}
Rationale:
To keep the size of the root partition small (if separate from
/usr), the files in this directory should only be ones required
by files in the root partition.
/mnt Directory:
Files:
NONE
Directories:
NONE
Rationale:
Standard mount point for external (transient) file systems.
Must be available for sub-system installation. Should remain
as an empty directory.
/tmp Directory:
Files:
NONE
Directories:
NONE
Rationale:
Temporary file space available for general program use. May
become a mounted partition upon system boot.
/usr Directory:
Files:
{none defined by spec}
Directories:
adm bin spool local lib etc man include src tmp
Rationale:
/usr is the mount point for the second major (after root)
hierarchy of file structure and is discussed in the next
section.
/usr/adm Directory:
Files:
{none defined in spec}
Directories:
{none defined in spec}
Rationale:
Location of log files and accounting information.
/usr/bin Directory:
Files:
{all executable files from standard distribution not contined
in /bin}
Directories:
{none defined in spec}
Rationale:
contains 'drop-in' executables that are considered to be
standard to the UNIX system. These files should NOT be
Linux specific, but should have the same function as their
UNIX equivalents.
/usr/etc Directory:
Files:
{none defined in spec}
Directories:
{none defined in spec}
Rationale:
contains configuration files for any files in /usr/bin. helps
to keep /etc clean and small.
/usr/spool Directory:
Files:
{none defined in spec}
Directories:
uucp mail
Rationale:
containes spool files for mail, printing, uucp transfer, etc.
May be a mount point for another volume.
/usr/local Directory:
Files:
NONE
Directories:
bin lib etc man src
Rationale:
contains files local to the specific system. will not be
modified by upgrade process.
/usr/lib Directory:
Files:
libc.a crt0.s {and as needed}
Directories:
{none defined in spec}
Rationale:
location for library files required for multi-user system
operation. This is the directory where program libraries
| should reside. /usr/lib will also contain binaries required
| to support programs residing in /usr/bin.
/usr/man Directory:
Files:
NONE
Directories:
man1 man2 man3 man4 man5 man6 man7 man8
Rationale:
Contains manual pages for programs that are standard with
Linux.
/usr/include Directory:
Files:
{programmers include files}
Directories:
{as needed}
Rationale:
Standard place for system include files.
/usr/src Directory:
Files:
NONE
Directories:
bin lib linux usr.bin usr.lib
Rationale:
Contains source code for all applications in the release.
/usr/src/linux contains directories required for kernel builds.
/usr/tmp Directory:
Files:
NONE
Directories:
NONE
Rationale:
Used as additional scratch space for programs. If /tmp is
a mounted file system, /usr/tmp may be a symbolic link to
/tmp.
-- abc@concert.net Alan Clegg - Network Programmer KD4JML (just my luck!) MCNC -- Center for Communications
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: 386 BSD (FREE!!!! - Jolitz version), ethernet, etc drivers Date: 10 Mar 1992 15:59:25 GMT
William Jolitz's 386 BSD port is out "for experimenters only"
However, this does have ethernet drivers for a number of boards,
TCP / IP, and other goodies that are freely redistributable, etc.
We should probably look at this.
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Problems with 0.95 Date: 10 Mar 1992 00:03:59 GMT
While I hoped 0.95 would solve all major problems people had with linux,
I was wrong (surprise, surprise). I've had reports of three different
driver-related problems already, even on machines that ran 0.12. So I'm
running a little gallup to see how 0.95 works...
If you have tested out 0.95, I'd appreciate it if you'd reply to me by
mail (just a simple 'R' in most unix-newsreaders), and answer these
questions (even if you've had no problems). Also, if there seems to be
any special circumstances that make the problems worse, I'd be
interested to hear about them.
1) Unable to run 0.95 from a floppy-root: get "reset-floppy called", and
finally a "unable to mount root" panic. (yes/no).
2) Harddisk gives "unexpected interrupt", and/or some of the data read
seem corrupted. (yes/no)
3) Serial lines act weird/hang/etc when under heavy use.
4) Anything else that seems weird..
I think I've found the problem with (1) - it seems to be a missing
recalibration after read/write errors (add a "recalibrate = 1;" to
floppy.c: bad_flp_intr()), but the reason(s) for the others are still
shrouded in mystery.
Sorry for the inconvenience,
Linus
Original post in KCLUG archives
From: hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP) Subject: Re: 0.95 problems Date: Tue, 10 Mar 1992 20:03:31 GMT
In article <1992Mar10.151526.17137@athena.mit.edu> of alt.os.linux,
EINSTEIN@plh.af.mil (DAVE EINSTEIN) writes:
>
> Another question. Is the device numbering the same as in 0.12,
> i.e. is /dev/hdb2 -> 0x307 ?
>
No. That is also why the naming scheme changed.
Form an earlier post:
/dev/hda0 -> 0x0301
/dev/hda1 -> 0x0302
/dev/hda2 -> 0x0303
/dev/hda3 -> 0x0304
/dev/hda4 -> 0x0305 (Extended partitions...)
/dev/hdb0 -> 0x0341
/dev/hdb1 -> 0x0342
/dev/hdb2 -> 0x0343
/dev/hdb3 -> 0x0344
/dev/hdb4 -> 0x0345 (Extended partitions...)
Someone please flame me if I remembered it wrong...
/hpa
-- INTERNET: hpa@nwu.edu TALK: hpa@casbah.acns.nwu.edu BITNET: HPA@NUACC HAM RADIO: N9ITP, SM4TKN FIDONET: 1:115/989.4 NeXTMAIL: hpa@lenny.acns.nwu.edu "Northwestern: our labs have tube transistor-curve tracers."
Original post in KCLUG archives
From: hpa@casbah.acns.nwu.edu (H. Peter Anvin N9ITP) Subject: Installable filesystems in linux Date: Wed, 11 Mar 1992 02:36:59 GMT
Excuse me for asking this question before RTFM... I don't yet have a
machine that I can run linux (or LINUX?) on for another month or so, but
does linux support installable filesystems, or is the Minix file system
hardcoded in? If so, is anyone working on an DOS filesystems driver? I
know the DOS filesystem sucks majorly and I am not intending to use it for
anything serious, but I can see it being quite useful to allow shuttling
data between DOS and linux. I presume most linuxers also are running DOS
on their machines, and if your machine is not directly connected to the
Internet one may wish to bring home new files on DOS floppies from another
machine.
Or am I completely looney?
/hpa
-- INTERNET: hpa@nwu.edu TALK: hpa@casbah.acns.nwu.edu BITNET: HPA@NUACC HAM RADIO: N9ITP, SM4TKN FIDONET: 1:115/989.4 NeXTMAIL: hpa@lenny.acns.nwu.edu "Northwestern: our labs have tube transistor-curve tracers."
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: BSD 386 "press release" Date: 11 Mar 1992 08:54:38 GMT
Ok, alt.os.linux isn't necessarily the place - but I did
get an overwhelming response to my post. I hope too many
people don't jump ship because of this.
1. Linux is easier to hack.
As a college student, I have access to the full BSD source,
toxic and non-toxic parts. From what I took the time to look at,
it was fairly cluttered. BSD has gotten quite kludged up. Be warned.
Supposedly, they will fix this in 4.4... but that's another story.
2. Linux is easier on resources. The kernel itself is smaller,
the shared libraries (They did make .95? There were
stubs and pieces back in .12) will keep things even
smaller after things have been recompiled,
etc.
3. Right now, Linux works. For most people.
I can't really say much else.. but this is the anouncement
several friends sent me, one with the comment we may be able
to borrow code for Linux.
ANNOUNCING PUBLIC RELEASE of 386BSD,
(the FREE 386 Berkeley UNIX work-alike)!
(Notes from various sources, edited by David Harris, 3-7-92)
William F. Jolitz, the author of the 386 port of BSD UNIX (now free of
AT&T code) has begun releasing "386BSD" to the public. This is the result of
the work described in the DR. DOBB'S JOURNAL series on 386 BSD.
This version of 386 BSD is release 0.0, and is recommended for
skilled experimenters only. You want "kernel experience" for your
resume? This is your chance. While the source and binaries are
copyrighted by Bill Jolitz, he authorizes redistribution without required
charge (donations needed, but voluntary) for this and future releases.
This version is said to run on 386/486 SX/DX ISA (AT bus), with
traditional hard and floppy controller (IDE, ESDI, MFM types), and common
displays (MDA/CGA/VGA/Hercules). Ethernet controllers supported include
Western Digital 8003EB, 8003EBT, 8003S, WD8003SBT, 8013EBT and Novell
NE2000. Clones also appear to work quite well. Tape drive support is
available for QIC-02 controllers as well, allowing use of 3M cartridges of
QIC-60 through QIC-150 format.
As configured on the binary distribution, the system REQUIRES a floating
point coprocessor (387 or compatible), 2 MB of memory (will run on 1 MB
using paging). 4 MB of memory and a 200 MB hard disk is comfortable.
This early version is not reliable, and has trouble booting on some
systems. In testing the software on various 386 machines, John Sokol
found "about a 40% compatibility rate". There are known serious bugs,
and missing utilities. But this is the Berkeley UNIX that vast numbers of
students learned and used --- now available FREE. One would expect this
software to be widely used for education and as an introduction to UNIX.
Copies of the software are available from John Sokol at 415-364-8387
or e-mail to John at sokol@reyes.stanford.edu .
***********************************************************************
* BUT for convenience John made this DISTRIBUTION PLAN:
*
* At the SVNet meeting of March 11, 7:30 at the Apple Auditorium at 10500
* Mariani (corner of De Anza), Cupertino, a few copies of 386BSD will be
* distributed. If you want to be SURE to get a copy, bring a machine capable
* of doing a DOS copy to your high density disks. If needed, we will
* organize "trees" of people to copy for each other, if people can't make
* copies at the meeting due to limited time and few machines.
*
* People who want a copy of the 386BSD system should bring either:
* (A) for 3-1/4 1.44 Meg disks bring
* Source = 8 Disks
* Binaries = 6 Disks + 1 Boot disk = 7 Disks total
* For everything = 7 + 8 = 15 Disks Total !!!!
* or (B) for 5-1/2 1.2 Meg disks bring
* Sources = 10 Disks
* Binaries = 8 Disks + 1 Boot Disk = 9 Disks Total
* For Everything = 10 + 9 = 19 Disks Total !!!!!
*
* NOTE: The disks must be error free DOS formatted ahead of time! We
* don't want to wait while a computer formats floppies at the meeting.
***********************************************************************
There's about 23 Meg worth of stuff on all those floppys and there are
2 Sets of files, one for each medium.
The total release on tape was 44.7 Megs and Includes are just the Differences
from the Networking 2 release on the BSD386 Unix on the archive servers as
well as both sets of disk images....
If you want a copy via Internet contact John via e-mail at
sokol@reyes.stanford.edu
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Linux 0.95 - booting problems. Date: 10 Mar 1992 13:21:03 GMT
It seems 0.95 has enough problems with some hardware that it may not be
a good idea to upgrade right now: I'll have to find the bugs first. The
problems include things like not reading/writing the harddisk correctly,
which can result in protection errors (the executables get read in
incorrectly) and in the worst case in file-system damage. This is not
universal: on some machines linus-0.95 seems to work without problems,
others see partial problems, while still others are virtually unable to
run 0.95.
If someone will use 0.95 just to find out all the problems, I'd be
happy, but otherwise I'll try to get a new version out the door in a
week or so, which hopefully works better on more machines..
Linus "eggface" Torvalds
Original post in KCLUG archives
From: wolff@neuron.et.tudelft.nl (Rogier Wolff) Subject: Device driver organization -> loadable device drivers. Date: 13 Mar 1992 10:33:27 GMT
Hi everyone,
( Source code from Linux is written with > in front, source code which
I propose as new code is written with # in front. Note that I've not
yet tried to compile this code, so it may contain syntax errors, but
it is the intention that counts in this case.)
To read and write to devices, there are routines like:
(taken from char_dev.c at the bottom, already patched by me.)
> int char_rw(int rw,struct inode * inode, struct file * filp, char * buf,
> int count)
> {
> unsigned int major,minor;
> crw_ptr call_addr;
>
> major = MAJOR(inode->i_rdev);
> minor = MINOR(inode->i_rdev);
> if (major >= NRDEVS)
> return -ENODEV;
> if (!(call_addr = crw_table[major]))
> return -ENODEV;
> return call_addr(rw,minor,buf,count,&filp->f_pos,filp->f_flags);
> }
that use a table which holds the addresses of the routines to call.
However there are also places in the kernel that do not use such a
nice structure:
(From init/main.c:)
> tty_init();
> time_init();
> hd_init();
> floppy_init();
This should also be solved with a table like above.
Using the table will allow compiling into the kernel a few empty
device drivers which can be loaded at runtime!
For instance
# struct Devices {
# int (*init)();
# int (*readwrite)();
# int (*ioctl)();
# int numberofminors;
# } devicelist = {
# /* initroutine, read/write , ioctrl ,numberofminors */
# {fd_init ,fd_rw ,fd_ioctl ,32},
# {hd_init ,hd_rw ,NULL /*?*/ ,10},
# {tty_init ,tty_rw ,tty_ioctl ,256},
# {NULL ,NULLi ,NULL ,0}
# };
This would allow modifying the readwrite routine to the following:
# int char_rw(int rw,struct inode * inode, struct file * filp, char * buf,
# int count)
# {
# unsigned int major,minor;
# crw_ptr call_addr;
#
# major = MAJOR(inode->i_rdev);
# minor = MINOR(inode->i_rdev);
# if (major >= NRDEVS)
# return -ENODEV;
# if (minor >= devicelist[major].numberofminors)
# return -ENODEV; /* Linus writes EIO, I think ENODEV is better */
# if (!(call_addr = devicelist[major].readwrite))
# return -ENODEV;
# return call_addr(rw,minor,buf,count,&filp->f_pos,filp->f_flags);
# }
and on similar grounds, the init routine can be tidied up:
#initdevices ()
#{
#int i;
#
#for (i=0;i<NRDEVS;i++)
# {
# if (devicelist[i].init != NULL)
# devicelist[i].numberofminors =
# devicelist[i].init (devicelist[i].numberofminors);
# /* The init routines can detect the hardware that they need,
# and adjust the number of minors that they will support on
# the running configuration. For instance hd_init detects wether
# there is a second harddisk installed, and adjusts the # minors,
# They should return 0 for no hardware. */
# }
#}
And loading a device driver would be something like:
# doloaddevice (char * fname)
# {
# char *start;
#
# if (!suser ()) return -EACCES;
#
# if (curnumerofdevices >= maxnumberofdevices)
# return -EIO;
#
# if (mapintokernelmemory (fname,&start) < 0)
# return -Esomthing;
#
# devicelist[curnumberofdevices].init = start;
# devicelist[curnumberofdevices].nrofminors = (int (*)())start (0);
# if (devicelist[curnumberofdevices].nrofminors == 0) return -EIO;
# /* Code to initialize devicelist[].rw and .ioctrl */
# curnumberofdevices++;
# return OK;
# }
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kadokev@iitvax ==? technews@iitmax.iit.edu)
EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
Original post in KCLUG archives
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Re: Linux source code reductions necessary or not? Date: Sat, 14 Mar 1992 00:15:09 GMT
From: db1@ukc.ac.uk (D.Bolla)
Date: 13 Mar 92 15:17:03 GMT
Reply-To: db1@ukc.ac.uk (Damiano Bolla)
1) Organize the ftp sites such there are different subtrees for different
releases of linux.
The problem with this suggestion is that there are many things which
will work for multiple releases, and it's painful to have to do figure
out what should be considered Linux 0.12, or 0.13, or 0.11..... for
example, the gcc which I have been using up until very recently was the
original GCC compiler that was released for 0.10.
It doesn't make sense to ask each FTP site maintainer to make their own
judgements about what binary works for which version of Linux. I (at
the very least) do not have that kind of time on my hands.
I do recognize the need for what you are requesting, and I have been
pinning my hopes on the "ABC Release" of Linux, which will hopefully
have everything bundled up for people to use. There will still be a
place for the more chaotic and concontrolled method of FTP distribution,
for people who are willing to live on the bleeding edge of technology.
But for most people, the "ABC Release" should make it much easier to put
together a release.
Of course, I suspect that the "ABC Release" will lag a bit when compared
to Linus's release of the sources, but if you're really impatient, you
can either do it yourself or pay someone enough money that they feel
like doing it for you on your schedule. Keep in mind, Linux is free
software, and that means is that while suggesting that someone might