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
want to do *X* can be productive, demanding that people to do things
just because it makes things more convenient for *you*, at possibly
great time and effort for *them*, doesn't necessarily go over very well.
:-)
- Ted
Original post in KCLUG archives
From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: Re: Linux-0.95 Date: 14 Mar 1992 10:00:40 GMT
dj1l+@andrew.cmu.edu (Demian A. Johnston) writes:
>Is ka9q a networking package? Obvious it supports slip, how about Token
>Ring?
KA9Q is a TCP/IP implementation. It's a port of software written for
MS/DOS. Under MS/DOS, it uses the packet drivers. There is a packet
driver for TR that emulates an Ethernet. Unfortunately it's harder to
do Ethernet or TR under Unix. Under Unix, user programs (which KA9Q
is) don't normally use hardware like Ethernet or TR cards at the low
level that KA9Q expects. However that's just tradition. There's no
good reason you couldn't implement a device driver that supports a
/dev/ethernet or /dev/token, with read and write system calls to read
and write packets, and a couple of ioctl's. That would be enough to
let KA9Q do its thing. There'd need to be some low-level coode in
KA9Q as well, but it would be easy to write. The hard part of the
Ethernet or TR encapsulation is ARP, and that code is already present.
This might be a reasonable intermediate step in progress towards full
network support. The main disadvantage would be that the version of
KA9Q I ported is really a single-user program. That's probably OK for
SLIP, but maybe not so good for Ethernet. There's another Unix port
of KA9Q that reorganizes it into a single server talking to multiple
clients in a way that would probably work with "tubes". That would be
more appropriate for Ethernet or TR (and it's even possible that it's
got some support for Ethernet -- though you'd still need a device
driver). Sorry, I don't recall where that port is. If you look for
KA9Q in archie you should turn it up. I didn't use that version
(1) because there was nothign like tubes when I first did the
port, and (2) because that version looked more difficult to port.
Original post in KCLUG archives
From: Irwin.Shapiro@f302.n2603.z1.fidonet.org (Irwin Shapiro) Subject: can the rest of the world get in on this Date: Sat, 14 Mar 1992 21:31:52 GMT
hello linux activists!
we here in the outside world would like to make linux pubicly accessable
but most of us cant ftp. Would anybody happen to be able to make avail a v32 uucp connection so we could start our linux distribution network.. so us non internet users can get the sources to the binarys of linux...
p.s. the disk images [for .12] are moving like hot cakes around the world.. and the other uilitys binarys are following slowly...
but i still cant print cause i cant find kernel.tar.z or system.tar.z anywhere
to patch lith lp.tar.z (which i have :) )
thanks
irwin
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!2603!302!Irwin.Shapiro
Internet: Irwin.Shapiro@f302.n2603.z1.fidonet.org
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Need help creating a boot disk Date: 15 Mar 1992 10:40:24 GMT
In article <1992Mar15.064233.15653@athena.mit.edu> alsaggaf@ERL.MIT.EDU (Muhammad Saggaf) writes:
>In article <1992Mar15.042200.16669@ccu.umanitoba.ca>
>rahard@ee.umanitoba.ca (Budi Rahardjo) writes:
>>I've decided to try linux am having a problem creating a boot disk.
>>- downloaded rawrite.exe and bootimage (0.12 and 0.95)
>>- use rawrite to create boot disk, it say disk has 9 sectors
>> (I am using 360K disk on my XT to do this)
The problem here is that the linux boot-sequence asks the BIOS what kind
of drive you are running on, gets the answer "1.2M drive" and tries to
read 15 sectors/track. This obviously won't work. Use a high-denstity
diskette, and live with the fact that the kernel uses only 15% of the
capacity.
>I did the same. In my case, when I booted up with the bootimage
>diskette in my 360K drive a, I got the mesaage: "Loading ..... ". The
>dots went on for a while and then nothing happened, I didn't even get
>the above CX ... etc. message. I have a 386sx-25 (AMD) with 2MB of
>RAM. Any help is greatly appreciated.
Ok: this one is a totally unrelated problem. Now the bios reports the
correct kind of disk, so the system loading goes all right. After that
the bootup sequence tries to determine the root-disk type, and finds out
it's not a gigh-density floppy, and dies. It should really print out an
error-message, but there was no space left in the boot-sector, so it
doesn't, it just goes into a loop waiting for a reboot.
If you have only a 360kB drive, I don't see how to install linux. The
root-disk simply won't fit on 360kB - even 1.2M is a bit tight. If you
have a bigger B: drive, you might swap cables, and use that as A:
Linus
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: gdb: "Bad things happen" Date: 15 Mar 1992 21:03:10 GMT
In article <Mar.15.12.47.54.1992.3590@dartagnan.rutgers.edu> hedrick@dartagnan.rutgers.edu (Charles Hedrick) writes:
>I've been trying out gdb, from tsx-11. It's not entirely easy to
>install it, as I had to figure out what libg.a is supposed to be,
>and I had to remember to use cc1-g from the 1.40 distribution.
>But I've got something that mostly works. However when I try
>to step through a call to localtime, I get
>
> Bad things happen: nonexistent page error in do_no_page
> Segmentation fault
>
>This is the version of localtime from the BSD ctime.c, which is
>in the libc I put out on athos.rutgers.edu a couple of weeks ago.
The "bad things" error is a message that happens when the memory manager
gets a request for a page not in the users process-space, which
shouldn't be possible (as those errors should be trapped by the
segmentation handler). However, ptrace() does some mucking around with
the memory, and it had a bug (now fixed, I hope) that is probably the
reason for this. I'm happy most of it seems to work, though.
Linus
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: Re: 'pklite' for Linux. Date: 16 Mar 1992 02:16:52 GMT
In article <1992Mar16.003027.2064@athena.mit.edu> jyelon@cs.uiuc.edu writes:
>I considering writing binary file compressor for Linux, much like
>pklite for msdos. The salient characteristic will be that you
>can compress a program, and you won't have to decompress it
>in order to run it. (It would decompress itself automatically
>into RAM). I need ideas.
>
>First of all, how do I pull it off?
>
>Here is plan 1:
>
> 1. start the to-be-compressed executable using ptrace.
> 2. read out all of its memory into a file.
> 3. compress the file.
> 4. prepend a tiny in-memory decompression routine to the file,
> 5. prepend the proper headers for an executable program, and presto!
>
>The disadvantages:
>
> 1. I like shared pages. However, a text segment that gets
> decompressed at runtime isn't 'read-only', so that does
> it in for shared pages.
Disk is cheap, memory is expensive. If you can't share
pages, you're going to loose memory, and start swapping to disk
much sooner. I sometimes look at the memory allocation, and
see 100+ shared pages when I'm heavily loaded - that's
400K.
Puting the decompression code in the kernel eliminates this problem :
the pages can still be read / execute only, and clean, and still
be shared.
> 2. Shared libraries would probably get linked in as soon as
> ptrace ran the thing, so the libraries would become a part
> of the compressed file. Yuck!
Why use ptrace? You probably want to set up a new magic number,
and prepend that to a compressed a.out file.
> 3. Thousands of copies of this decompression routine, one in
> every executable, like a virus. Gross. Plus, the kernel
> is constantly loading the same decompression routine from
> disk. Wasteful.
If its in the kernel, there aren't "thousands of copies of this routine"
>The advantages:
>
> 1. Edit the kernel code for exec, to look for a new 'compressed
> executable' magic number.
> 2. Have it then decompress/load the file into ram, and
> 3. Have it then proceed as if it had just loaded a non-demand-paged
> executable.
Much better. You still have shared pages, etc. The only real problem
you still have is not being able to page from the file, and text gets
swapped like data.
>The advantages.
>
> 1. Its very clean.
> 2. The decompression routine is in the kernel, so it only
> needs to be loaded once.
> 3. It sounds more reliable than the above approach.
>
>The disadvantages.
>
> 1. The kernel is getting bigger (although not much,
> assuming that the decompression routine is small).
> 2. You have to have the decompressing-kernel to run
> compressed programs.
> 3. Again, compressed files are not demand-paged. (I, personally,
> could care less - I tend to think that demand-paging slows
> things down as much as it speeds things up).
>
Demand paging speeds things up in several ways :
1, Exec is faster because fewer pages are loaded at once.
2. Real memory use is lower, as the whole thing hasn't
been loaded. Less real memory used = less
swapping. Remember, disk is 1000 times slower
than real memory.
You might look at what happens to compression, etc if the file
is compressed in Xk hunks, X some small multiple of page size
(4K). This way you could seek to that part of
the compressed image (using a directory at the begining),
and still demmand page / not swap text.
>Also, about compression algorithms:
>
Kludge alert :
Why not, atleast for prototyping purposes, do a
pipe(2), fork(2), and exec /<standard location>/uncomrpess?
The code isn't in the kernel.
>PS: this might help alleviate some of the root-disk woes!
PPS : root disk woes :
1. Put a scaled down shell on.
2. Loose init, etc. I'd much rather have compress, tar on my root floppy than
init, login, getty, and their ilk.
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: SCSI drivers for .95 available, configuration Date: Mon, 16 Mar 1992 02:51:39 GMT
This weekend, I sat down and patched the SCSI drivers into .95.
They pretty much drop right in - trivial changes are made to
ll_rw_blk.c (3 lines), fs.h (1 macro + a few comments),
a line in main.c, and copy the SCSI files in.
There are a few larger changes made - namely to config.h, keyboard.S,
main.c, and kernel/blk_drv/Makefile. I decided that the current configuration
scheme (Well, lack of real configuration, and #defining KBD whatever
in keyboard.S, which really should be done in config.h) needed changing
in a drastic sort of way.
config.h changed - so that there are a number of CONFIG options supported.
KEYBOARD - set this equal to KBD_US, KBD_FINNISH, whatever,
CONFIG_BLK_DEV_xxx
where xxx is a device name
This "enables" the choosen block device, so that it is compiled into
the kernel code.
CONFIG_CHR_DEV_xxx
Enables the character device xxx
Etc. There is also a CONFIG_DISTRIBUTION option, which
basically enables all devices, US keyboard, and whatever will be
the "most common" settings.
The SCSI devices are setup to respect this configuration information -
so when SCSI makes the distribution kernel, non-SCSI people can
simply leave CONFIG_BLK_DEV_SD and CONFIG_BLK_DEV_ST undefined.
None of the SCSI code will be compiled, or linked into the kernel.
Compiled or linked : You heard it. I've come up with some heinous
looking Makefile entries involving cpp, sed, etc, and have set it
up so the Makefiles share the same configuration file as
the C and assembly source.
Take a look at the source if you're interested,
it's all in scsi-.95.tar.Z.
Original post in KCLUG archives
From: hedrick@dartagnan.rutgers.edu (Charles Hedrick) Subject: new ka9q on tsx-11 Date: 16 Mar 1992 05:00:45 GMT
I've uploaded a new copy of ka9q to tsx-11 in /incoming. I trust the
staff there will put it in the right place. (If it gets lost, you can
ftp it from athos.rutgers.edu, /pub/linux, ka9qbin.tar.Z and
ka9qsrc.tar.Z) The main changes are:
- a new configuration command "wait", to allow you to adjust the
wait time in the main select. "wait 100" gives 100 millisec,
and is the default. "wait 0" disables the select, causing
the program to continuously check for input, using nonblocking
reads. In theory wait 100 should work fine, and cause ka9q
not to interfere with other things going on, but if you're
trying to do TCP transfers while other things are going on,
you may get better results from wait 0. This is because of
bugs in select. 0.95a fixes some of the bugs, but I don't
yet know whether it's going to be a complete fix or not.
- "ip stat" now shows statistics of various sorts for SLIP,
including the number of compressed and uncompressed packets
if you're using compressed SLIP.
I've built ka9q successfully with gcc 2.0, but this version was done
with 1.40. If you want to compile with 2.0, you'll have to define
_NFILE in daemon.c (presumably as 20), and remove the toupper and
tolower definitions in sys5unix.c, since they conflict with the
builtin ones.
Original post in KCLUG archives
From: rivers@ponds.uucp (Thomas David Rivers) Subject: Re: UUCP for linux? Date: 16 Mar 1992 12:38:05 GMT
I've been working on getting Taylor UUCP going; but haven't had
time to try version 0.95.
Now, with the advent of 386BSD; I'm probably going to (at least
temporarily) trash my linux machine. Would someone like to take
over from what I've got so far? I could send you diffs or my entire
current source tree.
(I've gotten everything to work, except for the actual transfer,
i.e. uucp, chat, etc... the machines exchange shere=?; send
a couple of control packets, then linux locks up...)
- Dave Rivers -
Original post in KCLUG archives
From: joer@inca.law.csuohio.edu (Joe Rosenfeld) Subject: Re: 386 BSD (FREE!!!! - Jolitz version), ethernet, etc drivers Date: Tue, 17 Mar 1992 22:37:43 GMT
In article <1992Mar10.185650.17666@sdd.hp.com> dan@hpsanaeo.nsr.hp.com (Dan Lake) writes:
>In article <1992Mar10.155925.4691@colorado.edu>, drew@cs.colorado.edu
>(Drew Eckhardt) writes:
>|>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.
>is this ftp'able? if so, what are the host(s)?
>
Yes, it is ftp'able at this site:
agate.berkeley.edu
[128.32.136.1]
in this directory: pub/386BSD
this is very interesting stuff. I like the ethernet board inclusion. May
take some playing and tweaking, but good things usually take time.
Regards-
Joe
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joe Rosenfeld
joer@inca.law.csuohio.edu loki@asgard.csuohio.edu
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: 0.95a uploaded - soon available Date: 18 Mar 1992 00:32:46 GMT
I just uploaded the new kernel source and image to nic.funet.fi into the
incoming-directory under linux. As usual, they won't show up for a day
or two: wait for arl to announce that it's available.
The new version called 0.95a has no major new features, and is just a
bug-fix release for 0.95 - it hopefully fixes all known bugs, but that's
what I thought about plain 0.95 :(. There are even less installation
documents than before: (a) they haven't changed since 0.95 and (b) the
rootdisk is no longer made by me (which means that 0.95a will probably
be the first release that actually has all the needed device special
files there.)
Everyone's favourite bug is also fixed: 0.95a actually returns the
correct version number from uname(). (Boy did I get bug reports on this
one :^)
I'm including the release-note at the end of the post.
Linus
PS: Whoever made the GNU-emacs binary available for linux - the
inability to use the "meta-X shell" command is a bit disturbing. I
looked into it a bit, and my guess is that the linux config file doesn't
define HAVE_SETSID. Could somebody with more diskspace than I have try
to recompile gemacs with HAVE_SETSID defined, and tell me if this fixes
the problem?
==========
RELEASE NOTES FOR LINUX v0.95a
Linus Torvalds, March 17, 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.95a 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.
NEW FEATURES OF 0.95a
0.95a is mainly a bug-fix release: it didn't even get it's own version
number. Plain 0.95 fixed a lot of bugs in 0.12, but also introduced
totally new bugs: 0.95a tries to correct these. The bugs corrected
(knock wood) are:
- floppy and harddisk drivers should now once more work with most
hardware: I'd be interested in reports of "unexpected HD interrupt"
and "reset-floppy called" with the new kernel.
- A rather serious tty-bug corrected: this one messed up the screen
under 0.95, and switched characters over the serial lines. Under
extreme circumstances it could even crash the machine.
- ptrace had a bug: hopefully it works now.
- The extended partitions didn't work under 0.95, although most of the
code was there. Please somebody tell me it works under 0.95a.
- the 0.95 fdisk was broken: a new one with the new root-floppy should
clear up the confusion.
- select() and the sleep-wakeup code had fundamental (but relatively
benign) problems under 0.95 (and all earlier versions). The sleeping
code is totally redesigned, and select should work better even under
load.
One actual new feature, not just a bug-fix:
- ser3-4 support is there, although I've been unable to test it (as I
haven't got more than ser2). NOTE! Due to AT hardware limitations,
ser1 cannot be active at the same time as ser3, and likewise ser2 and
ser4 are mutually exclusive. The interrupt-handlers should have no
problems with shared interrupts, but the actual hardware probably has,
so the kernel disables interrupts from one serial line when the other
one is opened.
- faster default keyrepeat rate: this is going to need some getting used
to, but is extremely practical especially with bigger screen sizes.
- VGA cards that aren't recognized at bootup are put into the 80x50
character mode if <enter> was pressed when asking about SVGA modes.
NEW FEATURES OF 0.95
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).
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 even better to vt200 control codes than 0.11. Special graphic
characters etc: you can well use them as terminals to VMS (although
that's a shameful waste of resources), and the PF1-4 keys work somewhat
in the application-key mode.
Extended vt200 emulation
0.95 contains code to handle a vt200 application keymap mode: the cursor
keys send slightly different codes when in application mode, and the
numeric keyboard tries to emulate the vt200 application keys. This
probably isn't complete yet.
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: jwinstea@jarthur.claremont.edu (Jim Winstead Jr.) Subject: Linux v0.95a rootimage uploaded Date: 18 Mar 1992 05:42:03 GMT
I have uploaded the root image for Linux v0.95a to nic.funet.fi. As
with the bootimage, you will have to wait for it to be moved to an
accesible directory. (I assume it will be moved over at the same time
as the bootimage.)
A summary of the changes has been included in the file CHANGES-0.95a,
also uploaded, and is also included below. There is also an
INSTALL-0.95a, which I have not posted below since it is largely a
rehash of INSTALL-0.11 and RELNOTES-0.95.
As Linus has said, these files will available in a day or two from
nic.funet.fi, and an announcement will be made when that happens.
They will be available on the other sites shortly after that.
=======================================================================
CHANGES IN THE LINUX v0.95a ROOT DISKETTE
Jim Winstead Jr. - March 17, 1992
This file mostly contains info about the changes in the root diskette
from Linux v0.95/0.12 to Linux v0.95a.
CHANGES
With the release of Linux v0.95a, the maintenance of the root diskette
has been assumed by Jim Winstead Jr. (jwinstea@jarthur.Claremont.EDU).
This means there are a few large changes between the Linux 0.95 and
0.12 root floppies and the Linux 0.95a root floppy. These are
detailed (as much as I remember them) below:
- 'bash' has been replaced with 'ash', the BSD 4.3 /bin/sh. This
freed up nearly 200k on the root floppy. However, there are
some problems with 'ash' that haven't been resolved:
- sometimes the backspace key will not work on a virtual
console. I've found that it usually works on all _but_ one
console, so this is only a minor hinderance.
- 'ash 'supports BSD-style job control, and this has not yet been
adapted to Linux's more POSIXish job control. This means
that 'ash' does not yet support job control, but it's being
worked upon.
- 'tar' and 'compress' are back on the root floppy. 'tar' is
compressed, and both utilities are in /bin.
- 'pfdisk', a disk partitioner, was added to the root floppy.
This makes it (almost) possible to install Linux on a machine
without looking at another OS.
- the file pager 'more' has been added to the floppy. This was
added because of the addition of some documentation files on
the root floppy.
- 'cat' has been added to /bin.
- many utilities have been moved from /usr/bin to /bin, to
conform to the Linux Directory Structure Standard (v1.0).
These utilities are ones that are 'vital to the restoration of
other file systems in the case of a corrupting crash.'
- 'init' and 'update' have been moved to /etc from /bin. This
was done because neither program should be executed from the
command line by any user, including root. (That means don't
put /etc in your PATH!) This has been a matter of some
controversy, but this is how it will stand until the Linux
Standards mailing list/committee decides otherwise.
- tty64, tty65, etc, have been renamed to ttys1, ttys2, etc.
- the directory /INSTALL was added, which contains some
documentation, and three simple shell scripts to make
installing Linux on a hard drive partition easier. These are:
- 'mktree', which makes a directory tree on the specified
mounted device.
- 'mkdev' which creates the standard devices in the dev
directory of the specified mounted device
- 'install' which installs the programs on the root diskette
to the specified mounted device
These programs will normally be called with '<name> /mnt'.
- rootdev is different than the one on v0.95. A couple of days
after the release of 0.95, a program called 'rdev' was posted
to alt.os.linux that duplicated and extended the functionality
of rootdev. This was renamed to rootdev and replaces the old
rootdev.
- agetty was renamed to getty, to be consistent with common Unix
practice.
- an improved fdisk was added that correctly reports extended
partitions, (Thanks to Linus!)
- /dev is complete, or at least more complete than the last few
releases of the root diskette, which always seemed to be a
major complaint. :)
- /etc/issue and /etc/motd have been expanded to be a little
more informative. (Yeah, I know, big deal! :)
- chgrp was removed. You can use chown to get the same effect,
but you just have to specify an owner, too.
Many of these changes were discussed on alt.os.linux, or the Linux
Standards group, so they may look familiar.
If you have questions, problems, or complaints about the root
diskette, either post to alt.os.linux, or send mail to me at
jwinstea@jarthur.Claremont.EDU.
If you have questions, problems, or complaints about the boot diskette
or the kernel itself, post to alt.os.linux or send mail to Linus
Torvalds at torvalds@cc.helsinki.fi.
Remember, the only stupid questions are the ones you don't ask.
FUTURE CHANGES
I'm already anticipating some changes for the next release, so here's
a sneak preview:
- shared libraries. These are currently in alpha testing, and
will hopefully free up some more room on the root floppy for
more goodies.
- a generic mtools might be added to the root floppy.
- a better fdisk to replace the current fdisk/pfdisk pair. You
won't need to know your drive's geometry for this, and it will
know about Linux extended partitions.
- an improved sh. I'm working on the backspace problem, and
adding job control. I'm also going to look at using the GNU
readline library for input, as long as it doesn't add
substantially to the size of sh.
- init/getty/login may be removed from the root floppy. The
main reason they'll still on there is the backspace problem
with ash.
- improved installation documentation. People have started work
on this already - read alt.os.linux for previews.
- more robust installation scripts. The current ones are quick
and dirty, and work well, but I'd like to add better ones.
- miscellaneous utilities added. I'd really like to add an
editor to the root disk, but I haven't found one small enough.
Any suggestions?
- various other things that I can't remember right now.
Again, mail your questions, comments and suggestions about the root
diskette to me at jwinstea@jarthur.Claremont.EDU.
-- Jim Winstead Jr. (CSci '95) | "Catch a fish!" Harvey Mudd College | -Geddy Lee, jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena Disclaimer: Mine, not theirs! | January 20, 1992
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: Re: SCSI support in 0.95a? Date: Wed, 18 Mar 1992 06:01:41 GMT
In article <1992Mar18.015952.22324@cs.uoregon.edu> toman@comix.cs.uoregon.edu (joseph toman) writes:
>I have an Adapatec 1542B SCSI controller and was wondering whether it would
>be possible to include SCSI support in 0.95a. I am quite a UNIX fan and would
>love to be able to run LINUX but without SCSI support (I'm not really much of
>a hacker) (;-( I guess, no luck!
>
> = Johannes =
>
>===============================================================================
Unfortunately, SCSI support did not make it into .95a. However, there are
clean diffs against .95. The code autodetects too, and can run in non-scsi
systems so it will be possible to include SCSI support in the standard
distribution.
Currently, the only finished low-level driver is for the seagate
SCSI hosts. Dave Gentzel is currently testing his Ultrastor driver -
so it should become part of the SCSI distribution soon.
I don't know the status of the Adaptec driver, and the DTC / future
domain drivers are student projects and therefore subject to spring
break.
Original post in KCLUG archives
From: entropy@ee.WPI.EDU (Lawrence C. Foard) Subject: VFS,tubes etc. Date: Wed, 18 Mar 1992 20:57:11 GMT
Sorry for taking so long moving IPC over to .95. I'm having to add a
few more features to VFS before I can get it to support pseudo directories.
It may take a while longer but it should save a lot of future work since
the kernel will be much more modular, and will make it possible to
have things like
/proc
/inet
etc.
I really think we should try to be innovative rather than just being
compatible. I think this is one of the biggest things Linux has going
for it.
Original post in KCLUG archives
From: pjangli@afterlife.ncsc.mil (Philip Anglin) Subject: Re: 386 BSD (FREE!!!! - Jolitz version), ethernet, etc drivers Date: 18 Mar 1992 11:55:03 GMT
In article <joer.20@inca.law.csuohio.edu> joer@inca.law.csuohio.edu (Joe Rosenfeld) writes:
>In article <1992Mar10.185650.17666@sdd.hp.com> dan@hpsanaeo.nsr.hp.com (Dan Lake) writes:
>
>>In article <1992Mar10.155925.4691@colorado.edu>, drew@cs.colorado.edu
>>(Drew Eckhardt) writes:
>>|>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.
>
>>is this ftp'able? if so, what are the host(s)?
>>
>
>Yes, it is ftp'able at this site:
>
>agate.berkeley.edu
>[128.32.136.1]
>
>in this directory: pub/386BSD
>
>this is very interesting stuff. I like the ethernet board inclusion. May
>take some playing and tweaking, but good things usually take time.
>
>Regards-
>Joe
>
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Joe Rosenfeld
>joer@inca.law.csuohio.edu loki@asgard.csuohio.edu
Also at gatekeeper.dec.com
in the directory: pub/micro/386BSD
--
Name: Philip J. Anglin
Mail address: pjangli@afterlife.ncsc.mil
Disclaimer: Opinions stated are those of the author alone,
not the Department of Defense or the U.S. Government.
Original post in KCLUG archives
From: corsini@numero6.greco-prog.fr (Marc CORSINI) Subject: FAQ part1 of 2 Date: Wed, 18 Mar 1992 23:57:34 GMT
Hi Linuxers!
This is the first part of the FAQ, it contains part I. to IV. of the
FAQ. I will post them to the main sites in a while.
=======================
The originall FAQ 1st version was posted in Dec. 19, by Robert Blum,
Most credits of this work to Linus, Robert and Ted, the rest was
either on the list posted by many (real) activists, not me ;-), either
in some other news groups, or else by direct posting to me (thanks
Humberto). I haven't copyrighted them, so thanks to every one who
participated even indirectly to this FAQ.
[To find what has changed, view the `Cdiff-faq' in my previous posting.
The last-change-date of this posting is always "two minutes ago". :-)]
This is the introduction to a list of frequently asked questions (FAQ
for short) about Linux with answers (Yeap!). This article contains a
listing of the sections, followed by the question/answer part.
This FAQ is supposed to reduce the noise level ;-) in the alt.os.linux
newsgroup (and also the 'linux-activists' mailing list), and spare the
time of many activists. I will post it twice a month, since there are
more and more new incomers, and new features.
BTW I think this FAQ should be available at the main Linux sites in
the doc directory (have you read this Ary, Robert, Ted ?). So I will
send a copy to the main sites.
Please suggest any change, rephrasing, deletions, new questions,
answers ...
Please include "FAQ" in the subject of messages sent to me about FAQ.
Please use corsini@labri.greco-prog.fr whatever will be the From part
of this message.
Thanks in advance,
Marc <corsini@labri.greco-prog.fr>
Remind the vote for comp.os.linux;
post the YES vote to linux-yes@bloom.beacon.mit.edu
The voting period will last through 00:00 UTC (7:00pm EST), 19 March
1992.
Future Plan:
- verification/location/organization for files available
via FTP (I've tried what a mess!!)
- cross posting this to news.answers as soon as comp.os.linux
is created.
- reorganization of the FAQ. I don't know how, but I feel it's
needed, any help appreciated.
================================8<=====8<==============================
CONTENTS
I. LINUX GENERAL INFORMATION
II. LINUX USEFUL ADRESSES
III. INSTALLATION and SECURITY
IV. LINUX and DOS
V. SOME CLASSICAL PROBLEMS
VI. INSTALLATION HINTS
VII. FEATURES
VIII. MORE HINTS
I. LINUX GENERAL INFORMATION
=============================
QUESTION: What is linux?
ANSWER: Linux is a small unix for 386-AT computers, that has the added
advantage of being free. It is still in beta-testing, but is slowly
getting useful even for somewhat real developement. The current
version is 0.95a, date: March 17th 1992. The previous version v0.95
(March 7th) had some bugs, please do not use it anymore.
Linux 0.95(a) 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.
QUESTION: What is the current state of Linux?
ANSWER: do "finger torvalds@kruuna.helsinki.fi", or read the
alt.os.linux newsgroup.
QUESTION: I've just heard about linux, what should I do to get it?
ANSWER: First read all this FAQ, and the INFO-SHEET monthly post, then
go to the nearest ftp site (see below), download the Images there are
two a rootimage and a bootimage (in general in the images directory),
download the INSTALL and RELNOTES files. Find the rawrite utility
(for example at tsx-11 it's in /pub/linux/INSTALL), then rawrite the
images on high density floppies (5.25 or 3.5), finally boot on the
root diskette and that's it.
QUESTION: Does it run on my computer?
ANSWER: Linux has been written on a clone-386, with IDE drives and a
VGA screen. It should work on most similar setups. The harddisk should
be AT-standard, and the system must be ISA. A high density floppy
drive -- either 5".25 or 3".5
Otherwise the requirements seem relatively small: a 386 (SX, DX or any
486). Any video card of the following: Hercules, CGA, EGA, (S)VGA.
It needs at least 2M to run, and 4M is definitely a plus. It can
happily use up to 16M (and more if you change some things). People
are working on a SCSI-driver.
BTW it works for some ESDI drive (Joincom controller with Magtron
drive after you have commented out the "unexpected hd interrupt"-message
from hd.c). And quite recently for some SCSI adapter.
QUESTION: How would this operate in an OS/2 environment?
ANSWER: Fine.
QUESTION: Will linux run on a PC or 286-AT? If not, why?
ANSWER: Linux uses the 386 chip protected mode functions extensively,
and is a true 32-bit operating system. Thus x86 chips, x<3, will
simply not run it.
QUESTION: How big is the 'complete' Linux package?
ANSWER: Well, the boot and root image diskettes are about 750k
compressed. The kernel sources are about 200k compressed, and the
libc sources are another 170k compressed. The GNU C compiler is 670k,
and the other miscellaneous unix utilities are probably a bit over a
megabyte.
Now add sources to whatever you want to port and compile yourself.
The sources to GNU emacs are about 3 megabytes, compressed. Groff (a
troff replacement) is just over 1 megabyte.
If you think this is big, remember that the OS/2 2.0 Limited
Availability release is 20 1.44 megabyte diskettes.
QUESTION: Since how long does linux exist?
ANSWER (partial): Few months, v0.10 went out in Nov. 91, v0.11 in Dec.
and the current version 0.95a is available since March 17th 92. But even
it is pretty recent it is quite reliable. There are very few and small
bugs and in its current state it is mostly useful for people who are
willing to port code and write new code.
QUESTION: What's about the copywright of linux.
ANSWER: This is an except of the RELEASE Notes v.095a: Linux-0.95a is
NOT public domain software, but is copyrighted by Linus Torvalds. 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).
QUESTION: Should I be a UNIX and/or a DOS wizard to install/use Linux?
ANSWER: Not at all, just follow the install rules, of course it will be
easier for you if you know things about Unix. Right now Linux is used
by more than 400 persons, very few of them enhance the kernel, some
adds/ports new soft and most of us are only (but USEFUL) beta testers.
So join us and choose your "caste"
QUESTION: What are the differences, pros and cons compared to Minix ?
ANSWER (partial):
Cons:
- Linux is not as mature as Minix, there is less working software right now.
- Linux only works on 386 and 486 processors.
- Linux needs 2M of memory just to run, 4M to be useful.
- Linux is a more traditional unix kernel, it doesn't use message passing.
Pros:
- Linux is free, and freely distributable, BUT copyrighted.
- Linux has some advanced features such as:
- Memory paging with copy-on-write
- Demand loading of executables
- Page sharing of executables
- Multi-threaded file system
- job control and virtual memory, virtual consoles and pseudo-ttys.
- Linux is a more traditional unix kernel, it doesn't use message
passing.
QUESTION: Does Linux use TSS segments to provide multitasking?
ANSWER: Yes!
QUESTION: If my PC runs under Linux, is it possible to ftp, rlogin,
rsh etc.. to other Unix boxes?
ANSWER: Not yet, but kermit has been ported to Linux, and the ka9q too.
QUESTION: Does linux do paging? Can I have virtual memory on my small
machine?
ANSWER: Linux0.95(a) does do paging in a better way than Linux0.12.
QUESTION: Can I have tasks spanning the full 4GB of addressable 386
memory? No more 64kB limits like in coherent or standard minix?
ANSWER: Linux does limit the task-size, but at a much more reasonable
64MB (MEGA-byte, not kilos), so bigger programs are no problem.
QUESTION: Does the bigger program sizes mean I can run X?
ANSWER: X is not ported to linux, and I hope it will be some day,
people are working hard on it but it's big, and wants a lot from
the system.
II. LINUX USEFUL ADRESSES
=========================
QUESTION: Where can I get linux?
ANSWER: Linux can be gotten by anonymous ftp from
nic.funet.fi (128.214.6.100):
directory /pub/OS/Linux
Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31):
directory /pub/msdos/replace
tsx-11.mit.edu (18.172.1.2):
directory /pub/linux
ftp.eecs.umich.edu (141.212.99.7):
directory linux
src.doc.ic.ac.uk (146.169.3.7):
directory /pub/os/Linux
hpb.mcc.ac.uk (130.88.200.7):
directory pub/linux
ustsun.s.u-tokyo.ac.jp (133.11.11.11):
directory misc/linux
You might want to check out which of these is the most up-to-date.
If you don't have ftp-capability, you are in trouble. See next Q/A. If
you have no uncompress utility, there are a lot even for DOS, have a
look on SIMTEL, or else use facilities provided by some sites to
uncompress for you. Don't do that if you can, because it's lengthy,
expensive and causes troubles to other users on ftp sites.
QUESTION: I do not have FTP access, what can I do to get linux?
ANSWER: Try to contact a friend on the net with those access, or try
mailserver/ftpmail server otherwise contact tytso@ATHENA.MIT.EDU. You
might try mailing "mailserver@nic.funet.fi" with "help" in the body of
the mail. If you choose ftpmail server (example: ftpmail@decwrl.dec.com),
with "help" in the body, the server will send back instructions and
command list. As an exemple to get the list of files available at tsx-11
in /pub/linux send:
mail ftpmail@decwrl.dec.com
subject: anything
reply <your e-mail>
connect tsx-11.mit.edu
chdir /pub/linux
dir -R
quit
QUESTION: Is there a newsgroup or mailing-list about linux? Where can
I get my questions answered? How about bug-reports?
ANSWER: alt.os.linux is formed, and comp.os.linux is on the way, for
those who can't access to the news you can ask for digest to:
Linux-Activists-request@NEWS-DIGESTS.MIT.EDU. On the other hand, mail
sent to Linux-Activists@NEWS-DIGESTS.MIT.EDU are posted to
alt.os.linux
DO NOT mail "I want to [un]subscribe" to the newsgroup, use
the request-address. IF not your mail-box will be over-crowded by
activists.
Questions and bug-reports can be sent either to the newsgroup or to
"torvalds@kruuna.helsinki.fi", depending on which you find more
appropriate.
BTW People are working on the organization of Linux, this is done on
a separate mailing-list.
linux-standards: Discussion of distribution and directory standards
for the Linux operating system, including directory structure, file
location, and release disk format.
Requests to be added to this list must be sent to:
linux-standards-request@banjo.concert.net
QUESTION: Does there exist a place where the traffic of the newsgroup
is kept?
ANSWER: Yes, on nic and tsx-11 (see the ftp adresses above)
III. INSTALLATION and SECURITY
==============================
QUESTION: How can I be sure I won't be writing over anything
important? I have to use DOS on my machine, and I don't want to
lose any files.
ANSWER: Back up everything. Just in case. Then, write some easily
recognizable pattern to the partition you have reserved for linux,
using some DOS tool. You can then use "cat /dev/hdX" under linux to
examine which of the partitions you used.
QUESTION: Linux mkfs doesn't accept the size I give the device,
although I double-checked with fdisk, and it's correct.
ANSWER: Be sure you give the size in BLOCKS, ie 1024 bytes, not
sectors. The mkfs doesn't work for very big partition (over than 64
Megs). Also, make doubly certain that you have the correct partition.
There are a few rules about this: /dev/hda (under linux0.95a) corresponds
to /dev/hd0 (under minix) and /dev/hdb (linux0.95a) to /dev/hd5
(minix). DO NOT USE THEM, they are the whole raw
disk, not partitions. Also if a partition is on drive 1 under minix
(ie /dev/hd1-4), it is drive 1 under linux as well. Moreover, there
is no real consensus on whether partition #1 is the first partition on
the disk, or is the first entry in the partition table. Some parition
programs sort this information on the screen only, some will write the
sorted information back to the hard disk. Linux assumes that the
first entry is hda1, and so if some utility starts sorting/reordering
the table these things can change. Moreover, do not use extended
partition (this is in the installation notes).
REMARK Minix does some reordering.
A useful hack is to make each of your partitions a different size.
Then after any editting or possible change to the partition table you
can boot a floppy system and run fdisk (linux's, not DOS) to see if
the assignments still hold.
QUESTION: I have a one partitionned 40Mb disk. If I run mkfs, what
happens?
ANSWER: If you do that, you will have an empty 40Mb Linux file system
(currently the same fs as Minix). You should, at least, make on your
hard disk, one partition per operating system you want to use.
QUESTION: I mounted the linux filesystem, and copied the files from
the root-disk to the harddisk. Now I cannot find them any more, and
somethimes linux dies with a "panic: trying to free unused inode".
ANSWER: You have probably forgot to sync before rebooting. Linux, like
all unices, use a "buffer cache" to speed up reads and writes to disk.
On a machine that has enough memory, this buffer-cache is 1.5MB, and
if you forget to sync before exiting, it may not be fully written out
to disk. Re-mkfs and re-install (or try to use the preliminary fsck,
but remember that although fsck tries to correct the faults it finds,
it may fail.)
IV. LINUX and DOS
=================
QUESTION: Is it possible to access to DOS world from Linux
ANSWER: Yes, there is the mtools package (with patches for devices.c)
The original sources of mtools can be found at any places not only at
nic, tupac and tsx-11, and the patches for Linux (with fix for big DOS
partitions are in the directory patches or ports). Moreover you should
download the file patch.Z to apply patches :)
It is possible to find the compiled mtools stuff at mcc (see above for
the adress)
QUESTION: the mtools package won't work. I get an ENOENT error message
for all devices.
ANSWER: mtools needs to be told which device to look for. Use 'ln' or
'mknod' to create a special file called "/dev/dosX", where X is A, B,
C, X or Y. A and B are for floppies (12 bits), C is for hard disk and
X, Y for any. This file should point to the device you want to read.
About the minor/major pair have a look in section INSTALLATION HINTS.
QUESTION: What is as86.tar.Z ?
ANSWER: It's the port of Bruce Evans' minix assembler, you need it to
be able to recompile Linux at your convenience.
QUESTION: Turbo (Microsoft) Assembler won't compile the Linux boot
code. In fact, some of the opcodes in these files look completely
unfamiliar. Why?
ANSWER: The Linux boot codes are written in Bruce Evans' minix
assembler, which has the same opcodes as the original minix assembler
ported to linux get as86.tar.Z Anyway there are a few differences
between these and normal DOS assemblers:
- No segments - everything is in the same segment (at least in the
bootsectors and setup, as they don't use the .data segments)
- mov[b|w|l] are shorter versions of mov ax,[byte|word|long] ptr
[XXX].
This is how unix assemblers normally give the size (byte, word or
long).
Gas has similar constructs.
- There is no "jmp short", the opcodes are "j" for a short jump and
"jmp" for a long one.
- "jmpi" is a jump with a segment:offset pair. I don't know how this
is
written in DOS assembly.
==================================8<==========>8=================
Marc <corsini@labri.greco-prog.fr>
Original post in KCLUG archives
From: corsini@numero6.greco-prog.fr (Marc CORSINI) Subject: FAQ, part 2 of 2 Date: Wed, 18 Mar 1992 23:59:37 GMT
Hi (again)
This is the second part of the FAQ.
========
V. SOME CLASSICAL PROBLEMS
==========================
QUESTION: While running du I get "Kernel panic: free_inode: bit
already cleared". Also, du produces a ENOENT error for all the files
in certain of my directories. What's going on?
ANSWER: These are both consistent with a bad file-system. That's
relatively easy to produce by not syncing before rebooting, as linux
usually has 1.5MB of buffer space held in memory (unless you have <=4M
RAM, in which case the buffers are only about 0.5MB). Also linux
doesn't do anything special about the bit-map blocks, and as they are
used often, those are the thing most likely to be in memory. If you
reboot, and they haven't been written to disk ...
Just do an fsck on the device, the -a flag might repair it otherwise,
the only thing to do is to reinstall the filesystem from the Images.
A sync is done only every 30 seconds normally (standard unix
practice), so do one by hand (some people think you should do 3 syncs
after each other, but that's superstition), or by logging out from the
startup-shell, which automatically syncs the system. Unmounting a
filesystem also syncs it (but of course you can never unmount root).
Another (sad) possibility is that you have bad blocks on your disk.
Not very probable, as they would have to be in the inode-tables, just
a couple of blocks in size. Again there aren't programs available to
read a disk for bad sectors and put them in some kind of
"bad-sector-file". On IDE drives this is no problem (bad sectors are
automatically mapped away).
QUESTION: How can I partition my hard-drive to use Linux?
ANSWER: There are (at least) two ways to answer this. The easy way is
probably to use a program which will do it for you, such as the MS-DOS
fdisk, Minix fdisk, Xenix/Unix fdisk, or programs such as edpart.exe
or part.exe.
On the other hand, you can use a disk editor and modify the contents
of the partition table directly. This has been already done, and an
extensive explanatory note can be found in the mailing-list archives
(25th Jan. 92).
BTW It might be useful to set three (3) separated partitions for
Linux, one for the root, another one for the usr and a third one for
swap, as an illustration, my root partition is 10Meg, the usr is 22Meg
and the swap partition is 8Meg (twice the size of RAM on my box). As
an experience I have used MS-DOS fdisk to partition my two hd and got
no peculiar difficulties.
QUESTION: What must I do to mkfs a floppy?
ANSWER: blocks are of size 1K so 1.44 floppy is 1440 blocks. The
floppy has to be formatted before this will work.
QUESTION: When I run kermit under Linux, I get "Warning, Read access
to lock directory denied". What am I doing wrong?
ANSWER: Nothing, you just need to create /usr/spool/uucp, which is
where kermit like to lock files.
QUESTION: du seems buggy when i used it the number of disk occupation
is wrong.
ANSWER: Take care, if you want size in kbytes use the -k flags.
QUESTION: du works just fine on directories, except on / and /dev,
moreover "ls -l" returns either big or negative number on /dev. Why?
ANSWER: This is a "feature" added in Linux 0.12; it was originally
present in Minix; more specifically, when you stat a device file
belong to a block device, it will return the maximum size of the block
device in the st_size member of the stat structure. If you don't like
it, it's very simple to patch it out. Look in the fs/inode.c, in the
subroutine read_inode().
BTW I have not tested it under 0.95a
QUESTION: When I try to (un)compress many files in one command, the
command partially fails?
ANSWER: This is a bug, many partial fixes are floating around but ..
You can solve it by a bash command "for i in whateverfiles;do
compress $i; done". Another possibility is to download the
compress-fixed.tar file.
QUESTION Sometimes, I get "mount can't open lock file"; what does this
means?
ANSWER: This can happened for two reason:
A) You try to mount something as non-root. In that case you can either
retry as root, or set the setuid bit to mount.
B) You are root. mount wants to open /etc/mtab and /etc/mtab~ - the
first one for reading, the second as lock file. If there is already a
mtab~ remove it. This can happen if you used once gnuemacs on mtab.
VI. INSTALLATION HINTS
======================
QUESTION: Where can I find the basic starting help?
ANSWER: You have to download the INSTALL notes, and more specially
the 0.11, 0.12 and the current one 0.95(a). Pretty soon, a special
help for beginners will be available on the net.
QUESTION: I've got all the things on site ??? but I don't know what
goes where.
ANSWER: include.tar.Z goes to /usr/include; system.tar.Z contains
the latest sources of the
system files (mkswap, mkfs, fsck and fdisk). In version 0.12
utilbin.tar.Z has been replaced by fileutil.tar.Z and utils.tar.Z
which contains a new tar to handle the symbolic links, make, uemacs
kermit and minor programs (sed,...). Other utilities have been ported
separately.
QUESTION: I don't know how to install gcc stuff, is there special places?
ANSWER: It depends on the release of gcc you are using. Right now
there are 3 packages : the original one gccbin.tar.Z contains all
the gcc-1.37 binary distrib; recently the gcc-1.40 has been ported,
it's in newgcc.tar.Z and a few days ago the BETA version of gcc-2.0
Choose yours
A) gccbin.tar.Z goes in /usr/local/lib except gcc which goes in
/usr/local/bin. Moreover each gcc-xxx of /usr/local/lib should be
linked with gxxx and xxx in /usr/local/bin.
B) newgcc.tar.Z goes in /usr, then uncompress and untar it. Files are
directed to /usr/lib, /usr/include and /usr/bin. You have to link ar,
as, ld with gar, gas and gld, this will prevent some error while using
make (especially whilst re-compiling Linux kernel). More information can
be found in section VIII.
C) gcc-2.0 is splitted in 2 files 2lib.tar.Z and 2misc.tar.Z, to
install them do the following:
cd /usr
tar xvofvz 2misc.tar.Z
read the FAQ in /usr/gcc2/install. Then
cd /usr
tar xvovfz 2lib.tar.Z
QUESTION: When I use the images, and i type "tar xvf ..." I got
"command not found". What did I wrong?
ANSWER: Nothing, in the distribution of 0.95 there is no tar (due to
lack of place); you should get the 0.12 images where the tar is in
compressed form (lack of place). You have first to copy tar.Z on
another disk/diskette and uncompress it, this command is available
on your diskettes.
QUESTION: It seems that $#@! ported on linux don't run correctly
ANSWER: Possible, but check first if the size of your file corresponds
to the one on the ftp sites, if it is then check the BUGLIST available
on the main linux sites. If the bug is not reported, do a complete
report of the error, try to correct it and send your result to
johnsonm@stolaf.edu.
QUESTION: Does anyone port this to linux?, if not i'll compile it
ANSWER: First check on the sites, have a look to the info-sheet
monthly post and also available on sites. Have a look in the "old"
digest files and mail-archives of linux-activists, these are kept at
least at tsx-11 and nic possibly at tupac. Look also at the GNU(*)
utilities to see if someone has already written a freely distribuable
version. Ask then on the list/news.
(*) GNU stands for GNU's Not Unix, which (besides being a recursive
acronym) is a project started by the Free Software Foundation (the FSF)
to write a freely distributable version of Unix. The GNU kernel is
named HURD, and is based on Mach. It is currently being written, and is
not yet done. Many of the GNU utilities, however, are completed and are
much more functional than the original Unix utilities. Since they are
freely available, Linux is using them as well.
QUESTION: I've ported *** to Linux, what should i do to add it in the
standard distribution?
ANSWER: Read first the previous Q/A, then to make something available to
others you have to post it (with cdiffs of the source, a short README if
needed) in the incoming directory of one of nic,tupac,tsx-11, then drop
a short note to the list/group and to the site advisor.
On nic it's arl@sauna.cs.hut.fi (Ari Lemmke)
On tupac it's blum@cip-s01.informatik.rwth-aachen.de (Robert Blum)
On tsx-11 it's tytso@athena.mit.edu (Ted Ts'o)
QUESTION: I want to port *** to Linux, what are the flags?
ANSWER: Recall that Linux implements subset of SYSV and POSIX, so
-DUSG and -DPOSIX work in general. Moreover throw away most of the ld
flags such as -ltermcap, -lg, since the libg.a and libtermcap.a are
missing.
QUESTION: Linux lacks on ****/ Linux has a bug in ***, what are the
rules to enhance/correct the kernel?
ANSWER: Before anything check if some one else is working on that
subject, contact those people, since end february a buglist (thanks to
Michael Johnson) is kept on the major sites. Test your improvment (it
should work is NOT enough), then send the patches in cdiffs form to
Linus and/or the list, moreover the localization must be clear. This
does NOT mean that bug-reports and patches are not accepted. Moreover,
you should sent a brief note to Michael: johnsonm@stolaf.edu
QUESTION: I seem to be unable to compile anything with gcc. Why?
ANSWER: If you have only 2 MB RAM, gcc will die silently without
compiling anything. You must have at least 4 MB to do compilations
BTW Since swapping is possible, I have heard that compilation is
possible with only 2Meg and a lot disk traffic :) Isn't it great?
QUESTION: I'm using a program that uses signal handlers which are
installed using sigaction() with the SA_NOMASK, and they get a general
protection error right after the signal handler tries to return.
What's going wrong?
ANSWER: You are using a libc.a that has an out-of-date signal.o and
sig_restore.o file, and they don't know how to deal with SA_NOMASK.
(The one in gccbin.tar.Z is out-of-date). Get the new libc.a and put
it in /usr/lib or /usr/local/lib. Again check your compiler version
QUESTION: gcc complains about not finding crt0.o and the system
include files What am I doing wrong ?
ANSWER: The include files normal place is in /usr/include. lib*.a and
*.o should be in /usr/lib or /usr/local/lib
QUESTION: While compiling some GNU packages gcc chokes on regex.c with
an insn code, what can I do?
ANSWER: There is a little bug in the port of gcc-1.37, this will be
corrected on the port of v2.0 (with g++). Right now throw away the -O
flag (to compile regex) and every thing will be alright.
BTW there are some minor bugs with this release of gcc because it was
compiled under linux-0.10, whith odd libraries. These problems have
disappeared with the new gcc-1.40 package.
QUESTION: I tried to port a /new/ version of gnu stuff. But in the
linking phase, gcc complains about the missing libg.a.
ANSWER: Yes this is well known, throw away the flag -g that's all,
anyway libg.a is /only/ for debugging purpose.
QUESTION: What are the device minor/major numbers?
ANSWER: (early Linus mail Nov. 6th 91, last update Jan. 19th 92)
Memory devices: Major = 1 (characted devices) minor
0 /dev/ram
1 /dev/mem
2 /dev/kmem - not implemented (easy, but I haven't done it)
3 /dev/null
4 /dev/port (implemented, but untested - don't play with it)
example: "mknod /dev/null c 1 3"
Floppy disks: Major = 2 (block devices)
minor = drive + 4*type, drive = 0,1,2,3 for A,B,C or D-diskette
type 1: 360kB floppy in 360kB drive (5.25")
2: 1.2M floppy in 1.2M drive (5.25")
3: 360kB floppy in 720kB/1.44Mb drive (3.5")
4: 720kB floppy in 720kB/1.44Mb drive (3.5")
5: 360kB floppy in 1.2M drive (5.25")
6: 720kB floppy in 1.2M drive (5.25")
7: 1.44M floppy in 1.44M drive (3.5")
Thus minor nr for a 1.44Mb floppy in B is: 1 + 4*7 = 29, and to read
an old 360kB floppy in a 1.2M A-drive you need to use minor= 0 + 4*5
= 20.
Example: "mknod /dev/PS0 b 2 28" (b for block: 2 for floppy, 28 for
1.44 in A)
Hard disks: Major = 3 (block devices) minor
0 /dev/hda - The whole hd0, including partition table sectors
etc.
1 /dev/hda1 - first partition on hd0
...
4 /dev/hda4 - fourth partition on hd0
5 /dev/hda5 - Extended partition
65 /dev/hdb - The whole hd1, again including partition table info
66 /dev/hdb1 - first partition on hd1
...
69 /dev/hdb4 - fourth partition on hd1
70 /dev/hdb5 - extended partition on hd1
NOTE! Be /very/ careful with /dev/hda and /dev/hdb - you seldom need
them, and if you write to them you can destroy the partition tables:
something you probably don't want. The only things that use /dev/hda
are things like "fdisk" etc.
NOTE 2!! The names for hd's are no longer the same as under minix,
there is a straightforward correspondance, but I think
minix orders the partitions in some way (so that the partition numbers
will be in the same order as the partitions are physically on the
disk). Linux doesn't order anything: it has the partitions in the
same order as in the partition table (ie /dev/hd?1 might be physically
after /dev/hd?2).
NOTE 3!! Extended partitions are recently detected, use them VERY VERY
carefully.
Tty's: Major = 4 (character devices) minor
0 /dev/tty0 - general console 1 -
63 - reserved for virtual console
64-127 - reserved for serial io
128- - reserved for pty's
And more particularly we have:
64 /dev/tty64 - com1
65 /dev/tty65 - com2
QUESTION: How to start Linux from drive B?
ANSWER: There is a DOS utility called boot_b.exe (look at DOS ftp).
Another simple way is to open the box and invert the cables.
QUESTION: The program boot_b works fine /but/ once the first disk is
read the system go back to the first drive, any hints?
ANSWER: Yes, change the bootimage in just the same way that you change
it to boot on the hard drive, execept that the major/minor pair is
different. All these information are in the file INSTALL-0.10.
Remember that if you use a sun or other endian machine, you will need
to reverse the byte order when you run the filter program (also in the
same file).
VII. FEATURES
=============
QUESTION: I've read that linux has virtual consoles, what must I do to
get them?
ANSWER: Yes there are, you can access them with the left <alt>-key
together with <Fn>-key. With the Linux 0.95a Images distribution, 4
consoles are available, agetty runs on them.
BTW: the serial ports are now /dev/tty64 and /dev/tty65. tty0 is the
general console. tty128- are reserved to pty's
QUESTION: What kind of shell is /bin/sh ?
ANSWER: Until v0.95 it's the Bourne Again Shell, bash-1.11 and
compilation was straightforward (Linus dixit), just "make"
that's all or nearly. But as the shell comes bigger and bigger the
v0.95a /bin/sh is ash the BSD 4.3 sh.
QUESTION: Does there exist a man page for **** ?
ANSWER: Download man.tar.Z from your favorite linux ftp site, there is
most of the fileutils man page -- either **** or g****, example there
is nothing on ld, but there is for gld :) --, check the whatis
database provided. The files in the cat1 dir are pre-formatted man
pages that the man program can use.
BTW there is no roff,troff nor nroff for Linux. Cawf 2.0 works just
fine for simple man pages, and a partial ms support too.
QUESTION: What are the editors available in linux?
ANSWER: Right now there are uemacs, elvis-1.4, some one (R. Blum)
is working on some other vi clone. The port of emacs 18.57 has been
done by John T Kohl, files can be found at the different sites
at nic it's in the directory xtra
at tsx-11 it's in the directory ports/emacs-18.57.
Also the port of mg (micro gnu) has been done and can be found at
least at athos.rutgers.edu (128.6.4.4) in pub/linux, mg is the binary
and mg.tar.Z is the sources file.
QUESTION: Does there exist a printer package for Linux?
ANSWER: There are lp patches for linux.0.12, which implement a
parallel printer interface and feature a greatly improved driver
design. the patches are in lp.12.tar.Z As I have no printer (yet), I
don't know how good it is. There is nothing yet for 0.95(a).
QUESTION: Does there exist a ps for Linux?
ANSWER: Yes in ps095.tar.Z I have not tested it yet.
QUESTION: It's nice to have the df utility, but it would be nicer if
it would give statistics of the root file system. Would it be
difficult to do?
ANSWER: surely not, in your file /etc/rc, instead of the line
> etc/mtab
put the following
echo "/dev/hdX (root)" > /etc/mtab
where the X is the hard drive you use as root partition.
QUESTION: How do I make swapping work?, when I boot I get the
following message: "Unable to get size of swap device"
ANSWER: There are two ways (as far as I know). Recompile the kernel
and makes the swap device available (have a look in the main
Makefile). Or else you can modify the bootimage, in that case you have
to put a full device number in the word reserved for the swap device:
the logic is the same as for the root device. Thus, if you want
/dev/hda2 to be your swap-device, you'll have to write a 2 (minor nr)
into byte 506, and a 3 (= harddisk) into byte 507. You can use
virtually the same program as for the root-device (look in INSTALL
files).
QUESTION: When I boot I get one of the following messages:
"Unable to find swap signature" or "Bad swap-space bitmap"
ANSWER: You probably forgot to make your swap-device, use the mkswap
command.
QUESTION: How do I know if it is swapping?
ANSWER: You will notice it :)) First of all, Linux tells you at boot
time, "Adding swap: XXX pages of swap space", and if you start running
out of memory, you will notice that the disk will work overtime, and
things slow down. Generally a 2Meg RAM will make the system swap
constantly while running gcc, 4 Meg will swap occasionnaly when
optimizing big files (and having other things active, such as make).
QUESTION: Is there only the %$#@ keyboard ?
ANSWER: There are Dannish, Finnish, French, German, Uk and US
keyboards. Set it in linux/kernel/chr_drv/keyboard.S, then
compile the kernel again.
QUESTION: Does there exist shared libs ?
ANSWER: They seem to work. The kernel features are in Linux 0.12
already.
QUESTION: Does Linux permit/support bitmapped graphics on vga/svga
cards?
ANSWER: No, there is no interface for graphics operations on Linux
(yet). Some work has been done by Orest Zborowski (mmap/munmap, and
vga demonstration). The (un)mmap was patches for 0.12 kernel, but I've
been told that new versions (for 0.95a) will be out in a short while.
QUESTION: There are a lot of patches available (fd patch, lp patch
login patch ...) can I be fairly confident the subsequent patches will
work?
ANSWER: This is not true yet for the current version; but it will be
so I kept it :)
No you can't, patching is a real beta tester art :)). People are not
working on the same patched release, so you have to check if the
patches you already applied works on the same kernel part, if not,
/great/, just apply them. If yes, check if there is an order, patch
creator knows that, and (should) try to warn patch user (in other
words: beta tester) otherwise you should edit the patch files (and
possibly make a brief note to others on this list/newsgroup or even a
cdiff) before applying them, another solution is to keep cool and wait
for the next version of Linux where, in general, the modifications
have been done but this behavior is /not/ Linux helpful.
QUESTION: I got the patches on some ftp sites, and applied them to the
kernel and tried to compile. It didn't !!. Are the patches buggy?
ANSWER: Before remake, just do a make clean in the directories
involved by the patches. This will force a rebuild of the .o and .a
files.
If you have a RCS running on your source tree, did you checked a
patched version of the files changed before /any/ CO either by you or
make
VIII. MORE HINTS
================
This part is recent and try to keep track of the different information
that appeared in alt.os.linux and on the list since beginning of
February. I tried to update it for v0.95(a), so there might be some
mistakes. Moreover take care to use the correct library and include
stuff for linux-0.12 and the ad-hoc gcc you use !!!
QUESTION: How can I backup my Hd under Linux ?
ANSWER: I know at least two ways. One possibility is tar and mtools,
another possibility is the diskbackup/diskrestore of Diamano Bolla
(digest44 vol. #1) which saves big hd to floppies using the
stdin/stdout. These utilities have been uploaded to the major sites in
file disksplit.tar.Z.
An example usage (Roger Binns) is:
tar cvf - bin dev usr etc .. | compress | diskbackup
and to restore:
diskrestore | uncompress | tar xvf -
QUESTION: How to use setterm: for the novice?
ANSWER:The setterm utility provides access to most of Virtual Consoles
(VCs) functionality. You can set your screen up to blank at 10
minutes using:
setterm -blank 10
You can set colors, and clear the screen. For a full list of commands,
just type "setterm" with no arguments.
There are a few tricks with the screen dumper can really make VCs go a
long way. Here are a few of the common ones that I use:
setterm dump
Dumps the contents of the current VC to screen.dump (in the current dir).
setterm dump 4
Dumps the contents of VC 4 to screen.dump
setterm -file mydumpfile -dump 4
Dump the contents of VC 4 to the file mydumpfile
setterm -file /dev/tty0 -dump 4
Dumps the contents of VC 4 to the current VC.
setterm -file /dev/tty4 -dump
Dumps the contents of the current VC to VC 4.
setterm -file /dev/tty64 -dump
Dumps the contents of the current VC to the serial port.
Handy if you are logged on and want to paste a screen full without
having to resort to doing a file transfer.
setterm -file mydumpfile -append 4
Appends to instead of overwriting the dump file. Useful if you
have several screens you wish to concatenate.
QUESTION: I know there are VC, but where is the setterm stuff?
ANSWER: It's in the current distribution (i.e. on the images)
QUESTION: While using emacs in 80x25 mode, the mode line is constantly
moving around, why?
ANSWER: This appear to be a bug in the scroll region handling of the
console. Some one has suggested to simply remove the last entry in the
vt100 termcap that refers to the scroll region escape. Namely remove
the cs entry.
QUESTION: When I use make as non root, it doesn't work, why?
ANSWER: ?????, the message is either (null) setuid ..., or (null)
setgid... I don't know how to fix it.
BTW This problem does not exist with the pmake (make for BSD 4.3 Reno
and BSD 4.4) package.
QUESTION: How can I get Linux to boot directly from the harddisk?
ANSWER: Right now, this can be done via the shoelace stuff or the
bootany package.
QUESTION: Sometimes, when I want to remove a directory, I get an error
message, is it a (known) bug?
ANSWER: No, There is no bug at all, you probaly have another shell
on another VC whose working directory is either the one you try to
remove, either a subdirectory of it.
QUESTION: can anyone give me a sample /etc/inittab entry for login
from a pc attached to serial line /dev/tty65?
ANSWER: "Humberto speaking :)"
First step up the modem to turn off echo and enable auto answer, I do
this in kermit by connecting to the modem and typing "ate0s0=1"
followed by enter (w/o quotes). Then setup inittab to spawn getty on
the modem
tty65:console:/etc/agetty -m 1200 tty65
Then it should work. Some modems can be permanently set to disable
echo and set auto answer, see your manual.
QUESTION: When compiling some code, cc1 complains about some insn
code, what's that?
ANSWER: An insn is an internal representation that gcc uses when
compiling. The main part of gcc is to take ordinary c (or c++) code,
and compile it, while ding optimizations in insn part, which is
soft/hard independant. Then another part which is hard/Os dependant
takes the insns and translate it in assembly language. The fix is only
to turn off the optimization flag (-O) or download the new gcc release
(1.4) which has been made available at tsx-11 (newgcc.tar.Z and the
ad-hoc libraries newlibc.tar.Z).
QUESTION: While compiling some stuff, I'm getting the following
error message:
Undefined symbol ___addsf3 referenced from text segment
as well as ___mulsf3 and __cmpsf2.
These symbols are not in the program or in it's header files.
ANSWER: These are math helper functions, and you can usually compile
these programs to use the kernel floating point routines by adding
'-m80387' to the compiler switches. If the program does any wierd
fp math (exp(), sin()) it'll die when you run it though.
QUESTION: What are the enhancement of the newgcc.tar.Z ?
ANSWER: There were some bugs in the old port that have been corrected,
moreover this package contains 387 support
there is libm.a (for those with 387)
libsoft.a (for those without, I for example)
libtermcap.a (from tput 1.10)
The -mstring-insns option is no longer needed nor supported :( [As
an example to recompile (successfully) linux0.12 you have to throw away
this flag in all the Makefile]
gcc-1.40 has some registers problem, you should had -fcombine-regs
flag while compiling (the linux kernel for example)
BTW Notice also that include files have changed (stdio.h which is no
more ansi compliant).
QUESTION What's about gcc2.0 ?
ANSWER: It has been ported to linux, but remember that gcc2.0 is an
ALPHA, it is not stable at all (have a look in gnu.gcc.bug or
gnu.gcc.help). Anyway the files are 2lib.tar.Z and 2misc.tar.Z
Uncompress and untar 2misc, read the FAQ and play with it.
QUESTION: I've been trying to get Linux to run on my [3/4]86 box. It
can't even boot. Any suggestions?
ANSWER: The most common error/problem is writing the bootimage to a
low density disk. It fits, but the bootstrap code will only recognize
high density disk. So try to format explicitely disk as high density:
- for 3.5", 'format a: /n:18 /t:80 '
- for 5.25", 'format a: /n:15 /t:80 '
QUESTION: Does there exist games, languages (other than C), and
anything which make the system more friendly?
ANSWER: Yes, among other things there are rogue and yatzee; TeX;
Prolog.. but in general, if you want some extra tool port it to Linux
this is also a good beta-testing exercice.
QUESTION: Does emacs handle the arrows-key
ANSWER: Yes it does, one simple way is to put some elisp code in your
.emacs, this is an except of mine:
(global-unset-key "\e[")
(setq esc-c-map(make-keymap))
(fset 'esc-c-prefix esc-c-map)
(define-key global-map "\e[" 'esc-c-prefix)
(define-key global-map "\e[B" 'next-line)
(define-key global-map "\e[A" 'previous-line)
(define-key global-map "\e[C" 'forward-char)
(define-key global-map "\e[D" 'backward-char)
The keycode was obtained by ^Q followed by the key
QUESTION: Whenever I use uemacs 3.1X on a symlink, the symlink does
not exist anymore, why?
ANSWER: (Tristram Mabbs) Since ue3.10, uemacs uses 'safe save' mode,
writing the file to a temporary and moving it OVER the original. In
the process, this deletes the original. To prevent this just add the
following in your emacs '.rc' file: set $ssave FALSE
===================8<==========>8================
Original post in KCLUG archives
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Re: 0.95a went out today: expect to see it soon Date: Thu, 19 Mar 1992 01:49:10 GMT
TSX-11 has grabbed the latest 0.95a images and sources. My apologies
for the delay. I am currently out of town, and am working from San
Diego at the IETF meeting, which will be slowing down my response time
as far as processing uploaded programs, questions and requests, etc.
until next week.
- Ted
Original post in KCLUG archives
From: jwinstea@jarthur.claremont.edu (Jim Winstead Jr.) Subject: rootimage-0.95a.Z corrupt Date: Thu, 19 Mar 1992 03:55:58 GMT
By some evil twist of fate, the rootimage-0.95a.Z uploaded to
nic.funet.fi was corrupted in transit, and as a result, was also
corrupt on tsx-11.mit.edu. I have uploaded a fresh copy to tsx-11,
and this will be available momentarily (the last five minutes have
been a flurry of email for me :).
I will also be uploading a new copy to nic.funet.fi momentarily, but
I'm not sure when this will become available. Watch this space for
details.... (For US users, you're better off waiting for tsx-11 to
get it to reduce the transatlantic net.load - especially since the
root image is more than 600k....)
I apologize profusely for the problems this has caused.
-- Jim Winstead Jr. (CSci '95) | "Catch a fish!" Harvey Mudd College | -Geddy Lee, jwinstea@jarthur.Claremont.EDU | San Diego Sports Arena Disclaimer: Mine, not theirs! | January 20, 1992
Original post in KCLUG archives
From: meggin@epas.utoronto.ca (David Megginson) Subject: Free BSD release: future of Minix/Linux? Date: Wed, 18 Mar 1992 03:01:52 GMT
Now that a fully bootable, free BSD Unix for '386 and '486 boxes is
available from agate.berkeley.edu (pub/386BSD), how will Minix and
Linux fare? I am stuck with Minix, because I use a 68000-based
machine, but I wonder whether many Intel users will stay with Minix or
Linux?
David
Original post in KCLUG archives
From: jnelson@plains.NoDak.edu (Jim Nelson) Subject: Re: Free BSD release: future of Minix/Linux? Date: 19 Mar 1992 07:15:18 GMT
In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>machine, but I wonder whether many Intel users will stay with Minix or
>Linux?
I'll probaly stay with Linux since it doesn't need a coprocessor like 386BSD
does. Now I just have to get Linux to sit nicely on my harddisk.
--
Jim, in the Land of the Lost. |Disclaimer: These are probably
ObQuote: Do Not Meddle in the Affairs of | opinions. I'm probably not
Wizards, For You are Crunchy, | supposed to have any.
and Good with Ketchup. |
Original post in KCLUG archives
From: chamil@mcs213i.cs.umr.edu (Charles M. Hamilton) Subject: Re: Free BSD release: future of Minix/Linux? Date: 19 Mar 1992 07:36:11 GMT
In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>Now that a fully bootable, free BSD Unix for '386 and '486 boxes is
>available from agate.berkeley.edu (pub/386BSD), how will Minix and
>Linux fare? I am stuck with Minix, because I use a 68000-based
>machine, but I wonder whether many Intel users will stay with Minix or
>Linux?
>
>
>David
I personally plan on sticking with linux and NOT going to the
free release of 386BSD. Why? Well, my machine now only
has 4 megs of RAM, which seems to be fine for linux, but I
suspect would crowd BSD. I also currently only have 80 megs
of disk space, 40 of which I devote to linux and 40 to DOS.
(I would throw DOS out completely, but I have too much invested
in software for it to disregard it completely). 40 megs
should be sufficient, approaching comfortable, for linux.
If you tell 386BSD unix you only have 40 megs available for
it, it will just laugh at you. Also, DOS and 386BSD cannot
co-exist on the same machine (yet).
Just wanted to get my $0.02 worth in. Keep up the good work
Linus, I'll stay with you!
-- Charles M. Hamilton
-- University of Missouri - Rolla
-- Computer Science
-- chamil@cs.umr.edu
-- (lifesucks@umr.everyday)
Original post in KCLUG archives
From: drew@cs.colorado.edu (Drew Eckhardt) Subject: Re: Free BSD release: future of Minix/Linux? Date: Thu, 19 Mar 1992 08:18:00 GMT
In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>Now that a fully bootable, free BSD Unix for '386 and '486 boxes is
>available from agate.berkeley.edu (pub/386BSD), how will Minix and
It boots on many machines. It doesn't boot on a lot. With Linux,
you still have the option of running DOS on only one hard disk,
with BSD you do a mklabel etc, and that IS your hard disk. DOS and
BSD will not coexist. BSD has neither virtual consoles nor X,
so you want something there's no way to hangup, and you need a
spare dumb terminal. No ptrace, no shared libraries, heavy resource
usage. BSD 386 is where linux was last year in terms of stability.
BSD has name recognition, FFS, networking, and tape support. It will
take more to rectify the 386 BSD problems, and add Linux standards like
shared libraries, virtual consoles, etc. than it will to add the
missing features to Linux.
I do however see a cross pollination of code between BSD and Linux,
with people from both groups borrowing code from eachother.
>Linux fare? I am stuck with Minix, because I use a 68000-based
>machine, but I wonder whether many Intel users will stay with Minix or
>Linux?
Minix : Linux and BSD will definately hit Minix's non-educational
users. As far as educational users, the operating systems professor
here at CU was practically salavating over BSD 386, and having a
"real operating system" that he can teach with.
I plan on staying with Linux. At this point, BSD 386 just has a
long way to go.
Original post in KCLUG archives
From: entropy@wintermute.WPI.EDU (Lawrence C. Foard) Subject: Re: Free BSD release: future of Minix/Linux? Date: Thu, 19 Mar 1992 09:45:29 GMT
In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>
>Now that a fully bootable, free BSD Unix for '386 and '486 boxes is
>available from agate.berkeley.edu (pub/386BSD), how will Minix and
>Linux fare? I am stuck with Minix, because I use a 68000-based
>machine, but I wonder whether many Intel users will stay with Minix or
>Linux?
At this point I'm staying with Linux because its more fun. It will soon
have things that BSD doesn't.
-- Disclaimer: Opinions are based on logic rather than biblical "fact". ------ This is a mutated signature virus, if you don't put it in your .sig \ / file you may lose your job, your dog may be run over, and you may die. \ / If you repent and add the .sig you may win the lottery and get laid. \/
Original post in KCLUG archives
From: snowden@cray.com (Jim Snowden) Subject: Re: Linux on 386 Laptop - Possible? Date: 19 Mar 1992 06:23:54 CST
In article <1992Mar18.201935.8476@udel.edu> boutell@tuttifrutti.udel.edu (Nefaratu the Boutellian) writes:
>I am planning to purchase a 386 - based laptop PC, with a hard drive of
>course, immediately after graduation. I would like to install Linux on
>this machine. Has anyone been able to install Linux on a laptop, and
>if so, what brand, model, et cetera? I don't want to buy a machine that
>can't run the ultimate hacker's OS. (-:
>
I have just got Linux 0.95a working on my laptop with no problems (once
I understood what was needed to be done!). The latest version seems to work
much better on my system (before, I occasionally got unexpect HD interrupt
messages and other funnies) - thanks to all who put it together!
The laptop is an Acer 1100LX 386SX/16Mhz, 5Mb RAM and with coprocessor.
Linux is in a 25Mbyte partition on the hard disk (I have also partitions
for DR DOS 6.0 and OS/2.
Jim Snowden
snowden@hemlock.cray.com
Original post in KCLUG archives
From: wolff@duteca2.et.tudelft.nl (Rogier Wolff) Subject: 386BSD unix versus Linux Date: 19 Mar 1992 11:45:25 GMT
I just read the BUGS section of the 386BSD release, and it seems to
have less features and more bugs than Linux! Tty things are not yet
finished, the thing crashes while paging, does not yet have a
init/getty/login (or at least doesn't use it by default), missing/
extra interrupts cause system to hang....
Bugs that Linux doesn't have (anymore), and features already added.
Maybe not so much need to switch anyway!
I will have a look at the tapestreamer support when I get a chance:
This looks promising.
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: Josh Yelon <jyelon@suna0.cs.uiuc.edu> Subject: Pklite for Linux, end of project. Date: Thu, 19 Mar 1992 15:01:09 GMT
About the PKLITE project that I had undertaken: I am no longer
interested, here are my notes, for anyone who wishes to take over.
Implementation would be trivial if only we had this one
system call:
execv_in_core(data, len, argv)
char *data;
int len;
char *argv[];
It acts exactly like execv, except that rather than exec'ing
a file, it exec's a block of memory. In other words, these two
pieces of code should have basically the same effect:
1. execv("/usr/josh/bin/foo",argv)
2. progfile = open("/usr/josh/bin/foo",O_RDONLY);
progsize = read(progfile, progbuffer, 9999999);
execv_in_core(progbuffer, progsize, argv);
That's the only kernel modification you would need - the rest
would be user-level code. Pklite would work like this:
1. It compresses the executable.
2. It concatenates a decompression routing to the compressed data,
and tacks on the appropriate ZMAGIC header.
3. When the new binary runs, it decompresses the data in memory,
and then runs the data, using execv_in_core.
That's all there is to it! At least, in theory.
The problem is "execv_in_core". It looks trivial. In fact, it's
hopeless. Linux is absolutely infested with the assumption that
every process has an associated executable from which it can page.
execv_in_core would break that assumption, and everything
would fall to pieces. Even if we did somehow manage to patch things
up, we'd need to completely redo the implementation of shared pages in
order to get two execv_in_core programs to share pages.
I do hope that somebody tries: It seems very much worthwhile,
regardless of whether or not stacker exists. I don't disagree that
stacker is useful. However, a 'stacker' just can't get the same
level of compression that a program like pklite could achieve:
- pklite can take all night to compress your files. Just
start a batch file, and it'll be done in the morning.
Stacker, instead, has to do a half-hearted job, since it's
in a hurry not to slow down your filesystem.
- pklite can make a useful assumption about your files:
namely, that they contain mostly 386 instructions. That
assumption should enable it to increase compression
significantly.
- pklite doesn't need to allow random access: there is
no reason for pklite to chunk things into 1k, 2k, 3k,
and 4k pages, thereby causing internal fragmentation,
and reducing compression.
These factors add up to one thing: significantly better
compression ratios for pklite.
Call me if you get the system call implemented, but need a hand
on the data compression part.
- Josh
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Extended partitions in 0.95a Date: 19 Mar 1992 16:40:23 GMT
WARNING! Linux 0.95a correctly identifies extended partitions, and seems
to set them up /partly/ right: but it also seems as if the actual new
partitions aren't correct. I don't know the exact layout of the
partition information in the extended partitions, and I just assumed it
was identical to the normal partitions. It seems I was wrong.
If your fdisk reports partitions within the extended partition, DO NOT
USE THEM! They seem to get the correct size, but not the correct
starting sector. Thus read/write to one of the extended partitions
(/dev/hdaX and /dev/hdbX , X >= 5) will access the incorrect sector, and
possibly corrupt data on one of the other partitions.
If someone could send me the data on the partition information within an
extended partition, I'd be grateful.
Linus
Original post in KCLUG archives
From: sph1@cbnewse.cb.att.com (stephen.p.hill) Subject: Re: Free BSD release: future of Minix/Linux? Date: 19 Mar 1992 21:22:17 GMT
Some of us out there will vastly prefer LINUX over BSD/386
just because LINUX isn't BSD! I want a SYS V'ish *NIX
to run on my PC and if LINUX wasn't available I would
be paying $99 for Coherent instead of using BSD.
I realize that LINUX is not just a SYS V clone, but
a mixture of SYS V, BSD, and POSIX. I havn't used it
yet ( my new 386/40 should be here next week ), but
from what I have read on this newsgroup it is just
what I want.
Stephen Hill
sph@ihlpe.att.com
sph1@cbnewse.att.com
Original post in KCLUG archives
From: tree@midget.towson.edu (Denise Tree) Subject: 0.95a changes (beginnerly mode) Date: Fri, 20 Mar 1992 04:57:58 GMT
Hello Linuxers,
I have changed over to .95a from .12 and like the improvements but
a few changes have me confused. In ver.12 I set a prompt with:
PS1='[\u] \w>'
PS2='[\u] \w|'
export PS1 PS2
in rc in /etc and also in .profile which was in two dirs in ver .12. This does
not work in .95a and I can't find a .profile (naturally I wrote one and it had
no effect. What am I missing?
Also: has anyone had any problems with uemacs-linux in .95a? It worked fine in
.12 but refuses to save a file now.
And: I have never used the Gnu compiler (Linux is my first experience with
unix) .....where are the docs located? I tried to find a site that had the
docs by themselves, to no avail...I can't ftp a 3meg file to my school account.
I'm crazy about Linux and can't wait to put it on my big scsi drive and use my
little mfm drive for dos....boot from a floppy!!
========================
Denise Tree
Towson state univ.
BIO major... not BIOS major!
Original post in KCLUG archives
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) Subject: Re: Problem with 0.95a and 0.12 "mount" Date: 20 Mar 1992 12:16:08 GMT
In article <1992Mar20.054144.15483@utdallas.edu> ramesh@utdallas.edu (R. Ramesh) writes:
>
> As the subject line says, I upgraded to 0.95a kernel but kept everything
>else as it was with 0.12. Generally things are ok except for the following.
>Whenever I mount or umount any partition mtab becomes empty. Somehow mtab is
>always empty. This is quite annoying as I don't know what file systems are
>mounted and where. Also df doesn't work (as mtab is empty). Can anyone help?
Upgrade mount and umount to the 0.95(a) versions: the 0.12 version opens
/etc/mtab~ with O_CREAT | O_EXCL, but no O_WROLNY, so writing to the
file will fail (and mount doesn't check for it). The 0.12 kernel didn't
check for the open-mode when writing, so it worked for that, but 0.95a
does.
Linus
Original post in KCLUG archives
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Subject: Re: please make comp.os.linux! Date: Fri, 20 Mar 1992 19:55:13 GMT
From: entropy@ee.WPI.EDU (Lawrence C. Foard)
Reply-To: entropy@ee.WPI.EDU (Lawrence C. Foard)
Date: Fri, 20 Mar 1992 13:03:56 GMT
I thought the voting was over a long time ago but this group still
hasn't appeared.
No, actually the voting just ended yesterday at 7:00 EST (0:00 UTC). (I
suspect you were confusing the 1 month discussion period with the 1
month voting period.)
I'm currently in San Deigo attending a conference, so is rather
inconvenient for me to make sure all of the votes are correct and to
eliminate duplicates, etc. I plan to do that Tuesday or Wednesday,
after I return to Boston. After the voting results are posted, there
must be a five day waiting period while people can verify the votes and
complainin about any voting anamolies. After the waiting period, *then*
the newsgroup can be created.
Although I have not double checked all of the addresses of people who
have voted to eliminate duplicates, I have done a first pass over the
votes, and the unofficial results is roughly 850 yes votes and 5 no
votes. So it is extremely likely that the comp.os.linux newsgroup
*will* be created. Just please be patient while we work through the
formalities in the next week or two.
- Ted
Original post in KCLUG archives
From: entropy@wintermute.WPI.EDU (Lawrence C. Foard) Subject: Re: Free BSD release: future of Minix/Linux? Date: Fri, 20 Mar 1992 22:25:19 GMT
In article <1992Mar21.073048.1673@nntp.hut.fi> s32974l@kaira.hut.fi (Jussi Markus V{h{passi) writes:
>In article <1992Mar18.030152.14554@epas.toronto.edu> meggin@epas.utoronto.ca (David Megginson) writes:
>>
>>... I am stuck with Minix, because I use a 68000-based
>>machine, ...
>
>Users of PS/2 70/80 etc. with MICROCHANNEL are stuck with Minix, too, like it
>or not.
>I'd propably use Linux if only MCA were OK. I'm still working on 386Minix-
>patches, hope to get it working some day.
If you could afford a PS/2 you can certainly afford the money for a real 386
or 486. There are many 486's under $2000 now and they will blow the PS/2
away. You might even be able to sell your PS/2 to some gullible person for
enough to buy a real machine :-)
-- Disclaimer: Opinions are based on logic rather than biblical "fact". ------ This is a mutated signature virus, if you don't put it in your .sig \ / file you may lose your job, your dog may be run over, and you may die. \ / If you repent and add the .sig you may win the lottery and get laid. \/
Original post in KCLUG archives