Files
2024-02-19 00:25:02 -05:00

556 lines
21 KiB
Plaintext

From: Digestifier <Linux-Activists-Request@news-digests.mit.edu>
To: Linux-Activists@news-digests.mit.edu
Reply-To: Linux-Activists@news-digests.mit.edu
Date: Fri, 7 Feb 92 11:00:12 EST
Subject: Linux-Activists Digest #41
Linux-Activists Digest #41, Volume #1 Fri, 7 Feb 92 11:00:12 EST
Contents:
Re: Linux installation (Jeff Hollingsworth)
Re: user space tcp/ip (and Taylor UUCP) (Charles Hedrick)
Re: Perl 4.019 on Linux 0.12, problems with $&... (Drew Eckhardt)
Re: Deadline for 0.13 (Drew Eckhardt)
overflowing maximum link counts (Douglas E. Quale)
uname(1) written (one more step closer to UUCP) (Thomas David Rivers)
Re: References for info on 386 and AT architecture. (Linus Benedict Torvalds)
Linux INFO SHEET (monthly post) (Robert Blum)
SWI-Prolog (Pieter)
Re: Aww, do I hafta? (Wayne Davison)
----------------------------------------------------------------------------
From: hollings@poona.cs.wisc.edu (Jeff Hollingsworth)
Subject: Re: Linux installation
Date: 6 Feb 92 03:59:30 GMT
In article <1992Jan27.161940.5491@athena.mit.edu> tytso@athena.mit.edu writes:
>
> Date: Mon, 27 Jan 1992 09:12:05 +0200
> From: wulfk@deuteron.tp2.ruhr-uni-bochum.de
>
> A few days ago there was a question to rename the com-ports. Some said, that
> they would prefer /dev/com1 or /dev/ttycom1. I think, that we should use
> the standard-UNIX-Nmaes /dev/tty01, because we are using unix and NOT DOS.
> perhaps a link to /dev/com1 could be made.
>
>The problem is that /dev/tty01 conflicts with the names used by the
>virtual consoles. That's why I suggested /dev/ttys1, which is used in
>at least some BSD systems.
>
Why not just change the virtual consoles to /dev/ttyc?. This is more
consistant with the naming pseudo-ttys as /dev/ttyp?. I have done this
with virtual consoles under Minix and it works great. I think the serial
lines should stay the way they have been.
--
===============================================================================
Jeff Hollingsworth Work: (608) 262-6617
Internet: hollings@cs.wisc.edu Home: (608) 256-4839
X.400: <pn=Jeff.Hollingsworth;ou=cs;o=uw-madison;prmd=xnren;c=US>
Home: hollings@warthog.madison.wi.us
------------------------------
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Subject: Re: user space tcp/ip (and Taylor UUCP)
Date: 6 Feb 92 05:50:41 GMT
> I had no problems building KA9Q on linux; I even set up a simple
> SL/IP network between Linux and my other machines.
I'd like KA9Q. Which version did you use, and what changes did you
have to make? As far as I can tell, there are three ports to Unix:
- an old one (pre-NOS), that runs in a single process, and
has both BSD and SYSV support. This will probably work
as is, or with minor changes. (I may even be the last
person to have touched this code, as I did a port to
Microport SV/AT.)
- a variant that uses a single process as protocol engine,
talking to separate application programs.
Supports only SunOS and SYSV. This would be
hard to port to Linux because it uses SYSV semaphors and
shared memory. This also appears to be a pre-NOS version.
- Unix patches for the NOS version. They implement a Unix
version of the "lightweight processes" used by NOS.
They use setjmp/longjmp for process switching. This looks
like it could be ported, but will need some tweaking here
and there.
The first version is pretty clearly the easiest to port. However it's
now about 3 years old. Thus it supports SLIP but not header
compression, which I believe is an important omission. The second is
the nicest design, but I don't think it's practical to do at the
moment. The third is probably the best compromise. Because it's a
set of patches that are tacked onto the current NOS release, it would
let us track the current release.
If you haven't already done so, I plan to take a look at the third
version to see how hard it would be. If it looks too bad, I'm going
to look into retrofitting compressed SLIP into the old version. That
should be fairly easy to do. It's likely to take me a few weeks to
get this done (again, assuming you haven't already done it).
------------------------------
Crossposted-To: comp.lang.perl
From: drew@anchor.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Perl 4.019 on Linux 0.12, problems with $&...
Date: Thu, 6 Feb 1992 06:48:28 GMT
In article <1992Feb4.160024.15061@daimi.aau.dk> poe@daimi.aau.dk (Peter Orbaek) writes:
>I'm attempting to get perl up and running on my 386/33 running linux 0.12,
>using gcc 1.40 (the compiler that comes with linux).
>
>After getting through configure, and doing various small hacks in the
>makefile, I have got it to compile cleanly, except for minor warnings about
>return-types of getgrgid() and such.
>
>But problems arise when I run the test-suite. First I must say that floating
>point support on linux is fairly bad, so I get several failed tests because
>sprintf prints - for instance - 12 as 11.99999999997.
>
>This can be remedied by compiling with these options, in effect making an
>"integer-perl":
>
> -Ddouble=int -Datof=atoi -DINT_PERL
>
>and then doing some minor hacks in str.c and dolist.c to get proper conversions
>from ints to strings, and removing packing of floats and doubles.
>
>With these hacks I get fewer failed tests than with the original floatin-point
>perl.
>
>BUT , in both cases the produced perl fails on tests: op/pat 28,29,30
>
>I seems that $& doesn't get set correctly. Why can this happen??
>This problem also affects several other tests.
>At least in op/pat test #28 $& is set to the empty string or null...
>
>Another failure that seems to occur only with "integer-perl" is that the
>test: comp/<something...> fails, due to length('\\\\') not returning 2
>or, more accurately:
>
>(length('\\\\') == 2) ==> false
>
>but
>
>$x = length('\\\\'); print $x; ==> prints 2
>
>and
>
>print length('\\\\'); ==> prints 2
>
>I have tried these things both with and without the perl-malloc if that
>matters.
>
>
>Suggestions anyone?
>
>
>Thanks in advance.
>
You don't want integer perl. Yucky. You DON'T port things to
linux, you port linux to things so future other things work
off the shelf :)
As I said, the _f_cvt.c functions are broken because of some backwards
#define's in lib/stdio/site.h and stdiolib.h.
1. In site.h :
change
#define LDBL_DIG 15
to
#define LDBL_DIG 17
2. In stdiolib.h change
# define MAXFLTDIGITS (LDBL_DIG+2)
to
# define MAXFLTDIGITS (LDBL_DIG - 2)
Before, it was printing more digits than it thought it had, and were
accurate. This prints 15 / 17 digits maximum (requesting more precision
will result in trailing zeros) - and works well with the rounding error.
------------------------------
From: drew@anchor.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Deadline for 0.13
Date: 6 Feb 92 06:58:35 GMT
In article <Feb.4.23.07.37.1992.28814@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>I agree with keeping the kernel small. I've ported several things,
>and had little trouble with missing kernel facilities. I'd just as
>soon not have things like System V semaphores, shared memory, etc.
Implementing SYSV shared memory on top of what we have would be
incidental. It is definately the trend - even BSD4.4 will implement
the sunos / sysV like shared memory, using sun syntax.
Semaphore and shared memory ARE also neat to play with :)
>Non-blocking tty I/O is essential to several kinds of applications,
>and there will probably be a few other features like that, but I agree
>that it's a mistake to put much more in the kernel.
>
>The challenge is going to be to provide some basis for networking
>without doubling the size of the kernel. Is there any chance you can
>come up with a way to write TCP outside the kernel without losing
>performance badly? There's a version of KA9Q that is designed to run
>as a set of programs outside the kernel. There's a single server that
>acts as a protocol engine. Applications talk to it rather than making
>system calls. It uses System V shared memory and semaphores to talk
>between the processes. If you could come up with a way to keep the
>performance penalty of this down, it might be worth looking at.
I think that networking DEFINATELY belongs in the kernel.
However, we also need GOOD isolation of code (I was complaining earlier
about having to put scsi / hard drive / floppy drive / console code
in the scheduler because of a lack of support for the kind of
timer - interrupt driven timeouts we needed elsewhere, and
a configuration file so that uneccessary stuff is not compiled in -
like on our HP's, we don't have the imp support on.
>I'd like to see priority in 0.13 (and maybe 0.14) put on completing
>libc. In the ports I've done, the main area I've found lacking is in
>that area: floating point support in the library (gcc compiles calls
>to helper routines that don't exist), and various other random things
>like alloca, bcopy/bcmp/bzero, regex, etc. I suspect we've identified
>most of the missing stuff by now, and people have come up with them as
>part of the source to various programs they've ported.
bcopy, etc : these can simply be memcpy, etc renamed. No problem there.
The math : that's missing in the KERNEL. The 387 emulation is only
half way there, and our version of gcc doesn't support soft float.
------------------------------
From: quale@saavik.cs.wisc.edu (Douglas E. Quale)
Subject: overflowing maximum link counts
Date: Thu, 6 Feb 1992 10:08:04 GMT
I've been looking over the error numbers that Linux returns for certain
error conditions and I noticed that in some places link counts are
incremented without check for overflow. This happens at least twice
in fs/namei.c (in handling the link and mkdir calls). In fact, I can't
find anywhere in Linux where an EMLINK error is returned.
--
Doug Quale
quale@saavik.cs.wisc.edu
------------------------------
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: uname(1) written (one more step closer to UUCP)
Date: Thu, 6 Feb 1992 03:15:25 GMT
I've got the Sys V uname command written, and I've forwarded it to
Linus for inclusion in the 0.13 release (if you need it ahead of time,
I can mail it to you; it's teeny.)
Anyway, uname lets you correctly name your machine so that uucp
can pick up the host name for the Shere=.... message, etc... and should
be executed by some /etc/rc script when the machine is booted.
To make sure this works, and to get Taylor UUCP polished off, I'd
like to gauge the net to find out which init/login setup seems to
be the one people prefer. If you're working on one, and have it
in reasonable shape; I'd like to try it out... toss me some mail...
- Dave Rivers -
(rivers@ponds.uucp)
------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: References for info on 386 and AT architecture.
Date: 6 Feb 92 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
------------------------------
From: blum@rama.informatik.rwth-aachen.de (Robert Blum)
Subject: Linux INFO SHEET (monthly post)
Date: 7 Feb 92 07:58:06 GMT
Hi Linuxers!
Following is the Linux information sheet, which will be posted monthly.
If you have any additions, corrections, suggestions, flames....
Feel free to mail me.
(And sorry for the delay with this)
Robert Blum
LINUX INFORMATION SHEET
(last updated 5 Feb 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
- Kernel features:
- Currently 4 national keyboards: Finnish/US/German/French
- 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
- virtual consoles
- pty's
- some 387 emulation (add, sub, mul, div, compares and loads/stores:
enough for gcc 2.0, I hope)
- shared library stubs (not used yet)
- POSIX job control
- Many parts of it adhere to the POSIX standard, e.g:
- System call compatible with a subset of System V and POSIX
- POSIX job control
- Full multiprogramming (multiple programs can run at once)
- A MINIX-compatible filesystem with hard/symblic links
- Sophisticated memory management, e.g:
- Memory paging with copy-on-write
- Demand loading of executables
- Page sharing of executables
- Virtual Memory
- Many development tools
- ANSI compliant C compiler (gcc)
- A complete set of compiler writing tools
(bison as yacc-replacement, flex as lex replacement)
- most utilities you need for development
(cat, cp, kermit, ls, make, etc.)
- Many of the gnu tools
- The GNU 'Bourne again' shell (bash)
- The GNU C compiler 1.40
- GNU emacs 18.57
- GNU filetools
- Several good editors
- Emacs 18.57
- Micro emacs
- Origami
- Lots of source code:
- Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.)
- 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.)
3. HARDWARE REQUIRED
- A 386 or 486 machine with an AT-bus. (EISA will probably work, also,
but you will need an AT-bus hard disk controller.)
Both DX and SX processors will work.
- A hard disk implementing the standard AT hard disk interface--
for example, an IDE drive. SCSI drives are not supported yet.
- A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB).
- At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use
gcc at least 4 MB are required.)
- Any video card of the following: Hercules,CGA,EGA,VGA
In addition, LINUX supports
- Up to two serial lines
- A real time clock
4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.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
- emacs 18.57
- less
- mkfs
- fsck
- mount/umount
Check your nearest archive for more, since this list is steadily
growing
5. LINUX BINARIES
The LINUX binaries and sources are available at three
anonymous FTP sites. These are:
nic.funet.fi:/pub/OS/Linux
tsx-11.mit.edu:/pub/linux
tupac-amaru.informatik.rwth-aachen.de:/pub/msdos/replace
6. LEGAL STATUS OF LINUX
Although LINUX is supplied with the complete source code, it is
copyrighted software. Unlike MINIX, however, it is available for free,
provided you obey to the rules specified in the LINUX copyright.
7. NEWS ABOUT LINUX
Since LINUX's introduction to the public there has been a rapidly
growing mailing list, "linux-activists@niksula.hut.fi". To subscribe to
this list, mail to "linux-activists-requests@niksula.hut.fi". If the
traffic in this lists increases further, there are plans to swap ( at
least partially ) over to comp.os.misc, so watch out for any LINUX
articles in this group. For the current status of LINUX, do "finger
torvalds@kruuna.helsinki.fi".
There also is a newsgroup for Linux, alt.os.linux.
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:
- Further math support/fp emulation in the kernel
- A virtual filesystem layer
- STREAMS
- init/getty/login
- Interprocess communication
- IEEE POSIX P1003.1 / P1003.2 compatibility
- SCSI support
- rename system call
- named pipes
If you want to help, join the mailing list.
--
UNIX should not be able to be crashed from user space.
Crashes belong in the kernel! (paul@actrix.gen.nz)
------------------------------
From: olivierp@fwi.uva.nl (Pieter)
Subject: SWI-Prolog
Date: 7 Feb 92 08:21:15 GMT
I've uploaded the complete SWI-prolog package (including my port for linux)
to tsx-11.mit.edu. It resides in the directory pub/linux/sources/usr.bin.
Have fun.
--
==============================================================================
Pieter Olivier | Room for a great .sig
olivierp@fwi.uva.nl |
==============================================================================
------------------------------
From: davison@borland.com (Wayne Davison)
Subject: Re: Aww, do I hafta?
Date: 7 Feb 92 08:26:08 GMT
nmurrayr@cc.curtin.edu.au wrote:
> I wonder, however, just how useful very long filenames actually are
Actually, they're very useful -- note all the long file names on your local
ftp server (including the linux packages). It takes 6 characters to just
put the ".tar.Z" on the thing, another 4 or more to add a version number,
and then try to fit the package name into 4 or less characters -- most
useful ftp names are at least 20 characters long. Then consider an average
software package that attempts to include readable file names in it. They
usually come really close to 14 characters. You've always got to leave
room for a ",v" if you plan to use rcs on it, and having patch use "~"
and "#" instead of the more readable ".orig" and ".rej" as its file name
extensions is rather annoying also. 14 characters just doesn't cut it
in my book.
> one thing that does annoy me when I do encounter a Unix system is having
> to type in 20 or 30 characters when I need to access a file.
Files names aren't for typing -- that's what the <tab> key is for in a
modern shell (like bash, tcsh, or whatever). I don't even type 8+3 char
files names under DOS thanks to cmdedit (a TSR command-line enhancer that
comes complete with _source_). Just type a few letters, hit <tab> and let
the shell figure out what you want. Long file names are for identifying
the files without trying to figure out contrived abbreviations.
--
\ /| / /|\/ /| /(_) Wayne Davison
(_)/ |/ /\|/ / |/ \ davison@borland.com
(W A Y N e)
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and alt.os.linux) via:
Internet: Linux-Activsts@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace
The current version of Linux is 0.12, released on Jan 14, 1992
End of Linux-Activsts Digest
******************************