Files
2024-02-19 00:23:35 -05:00

570 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: Wed, 22 Jan 92 04:15:16 EST
Subject: Linux-Activists Digest #6
Linux-Activists Digest #6, Volume #1 Wed, 22 Jan 92 04:15:16 EST
Contents:
Re: Buggy omit-frame-pointer? (Linus Benedict Torvalds)
No VI, sorry ... (Pietro Caselli)
Linux on Intel Inboard 386. (Sean Eckton)
Re: Linix: where is /usr/bin/mvdir (Linus Benedict Torvalds)
Re: No VI, sorry ... (Guess who?)
Re: No VI, sorry ... (Chris Boyd)
Re: Installation. (Steven L. Johnson)
Re: Installing GCC (Bob Smith)
Re: aha-1542 driver (Tommy Thorn)
Re: No VI, sorry ... (Pietro Caselli)
Re: /proc, anyone? (Ari Lemmke)
Re: No VI, sorry ... (Yaser Doleh)
Yes, but how *big* is it? (Brian Bartholomew)
Yes there is a VI (was Re: No VI, sorry ...) (Steven T. Ansell)
Re: Buggy omit-frame-pointer? (Theodore Y. Ts'o)
cron (vixie-cron) & postings (Thomas David Rivers)
Re: Buggy omit-frame-pointer? (Douglas Graham)
Re: Installing GCC (Theodore Y. Ts'o)
----------------------------------------------------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: Buggy omit-frame-pointer?
Date: 21 Jan 92 21:32:07 GMT
In article <1992Jan21.172326.15406@bmerh2.bnr.ca> dgraham@bmers30.bnr.ca (Douglas Graham) writes:
>Hello. First, I'd like to express my gratitude to Linus and the rest
>of the Linux contributors. It's a nice piece of work.
>
>With that out of the way, let's move on to the bitching :-)
Tssk. Be /very/ careful when assuming bugs in gcc: I find it very
satisfactory, and most bugs aren't in gcc but in the person who thinks
they are. (Well, there is one known bug in the linux-gcc, but that's
due to my porting, and doesn't actually make incorrect code).
> _printf:
> pushl %ebx
> leal 12(%esp),%eax
> pushl %eax
> pushl 12(%esp) !!!! THIS SHOULD BE 8(%esp) !!!!
> pushl $_printbuf
> call _vsprintf
No, 12(%esp) is correct. You are forgetting the return address: there
are three longs on the stack before the push: %eax, %ebx and the return
address. Thus the offset 12 is correct. The fact that the resulting
code actually works should have made you cautious. Not using the frame
pointer makes for code that is a bit harder to follow, but on a 386
where the registers are few anyway, I hate to leave one register
practically unused for no good reason.
Linus
------------------------------
From: pietro@deis35.cineca.it (Pietro Caselli)
Subject: No VI, sorry ...
Date: 21 Jan 92 22:52:32 GMT
Ok, berkeley told me that ... other people told me that ... everybody told
me that ... I CAN'T POST VI NEITHER IN BINARY NOR IN SOURCE.
I didn`t noticed any copyright on sources but, well people told
me so ...
Sorry to all the Vi lovers, I`ll devote myself to Emacs.
--
Pietro Caselli |
Internet: pietro@deis35.cineca.it | IF YOU MEET THE BUDDHA
zaphod@petruz.sublink.org | ON THE ROAD,KILL HIM.
------------------------------
From: ecktons@sirius.byu.edu (Sean Eckton)
Subject: Linux on Intel Inboard 386.
Date: 21 Jan 92 22:09:12 GMT
I am working at University Network Support at Brigham Young University and I
have only one PC that I work with and it is only an XT with an Intel Inboard
386 installed. I can get by with it because my other machines are NeXTs.
Has anyone tried or does anyone have any idea whether it would work or not in
my machine? I am really interested, but I only have one machine that I could
possibly run it on and it seems to be partly capable, but will that be
enough?
Sean Eckton
ecktons@sirius.byu.edu
------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: Linix: where is /usr/bin/mvdir
Date: 20 Jan 92 23:01:49 GMT
In article <1992Jan20.041714.25208@keps.kodak.com> bob@snuffy.dracut.ma.us writes:
>Has anyone the source or binary for /usr/bin/mvdir ...
mvdir needs kernel resources that aren't there yet - it would have been
my next project after the linked lists, but once again I'm hoping for
VFS, and I don't want to touch the fs too much before that arrives. The
reason the rename system call isn't implemented yet is that there are a
couple of problems with it: it isn't as straightforward as you'd
imagine. Race conditions, inclusion checking etc..
It will befinitely be in 0.13 or 14 - if you remind me. It's not /that/
difficult, just needs a little thought. In the meantime, you might fake
it with "cp +recursive" and "rm -rf". Be careful with that though..
Linus
------------------------------
From: anlhille@cochiti.ucs.indiana.edu (Guess who?)
Subject: Re: No VI, sorry ...
Reply-To: anlhille@arapahoe.ucs.indiana.edu
Date: 21 Jan 92 18:51:45
In article <1992Jan21.225232.27374@deis35.cineca.it> pietro@deis35.cineca.it (Pietro Caselli) writes:
Ok, berkeley told me that ... other people told me that ... everybody told
me that ... I CAN'T POST VI NEITHER IN BINARY NOR IN SOURCE.
I didn`t noticed any copyright on sources but, well people told
me so ...
Sorry to all the Vi lovers, I`ll devote myself to Emacs.
What about elVIs or steVIe? elVIs can imitate ex and vi, but I dunno
about steVIe. elVIs is available SOMEWHERE on wuarchive.wustl.edu.
--
============== Why does it happen? Because it happens. =============
============================================== == RUSH =============
====================================================================
------------------------------
From: clb@hp835.mitek.com (Chris Boyd)
Subject: Re: No VI, sorry ...
Date: 21 Jan 92 23:51:00 GMT
In article <1992Jan21.225232.27374@deis35.cineca.it> pietro@deis35.cineca.it (Pietro Caselli) writes:
>Ok, berkeley told me that ... other people told me that ... everybody told
>me that ... I CAN'T POST VI NEITHER IN BINARY NOR IN SOURCE.
How about elvis, a vi clone? Here's an excerpt from the man page
for my MS-DOS verision:
AUTHOR
Steve Kirkendall
kirkenda@cs.pdx.edu
...uunet!tektronix!psueea!eecs!kirkenda
Many other people have worked to port elvis to various
operating systems. To see who deserves credit, run the
:version command from within elvis, or look in the system-
specific section of the complete documentation.
I don't have the skills to port this, but I KNOW that someone out
there does.
--
(* Chris Boyd OpenConnect Systems, Inc. clb@oc.com *)
(* 2033 Chennault, Carrollton TX 75006, USA. Real close to Dallas *)
------------------------------
From: johnson@jvnc.net (Steven L. Johnson)
Subject: Re: Installation.
Date: Wed, 22 Jan 1992 00:31:54 GMT
gmartin@mcs213d.cs.umr.edu (Greg Martin ) writes:
>We still couldn't find a way to make Linux use
>anything bigger than a 32M partition, but oh, well.
The limitation in Linux is 64M (actually 65535 1K blocks) not 32M.
I used edpart to create multiple 64M partitions (64,999 blocks).
The version I used was: edpart.exe 23833 12-12-90 11:06
Are you saying that you can't create a 64M partition with edpart,
that mkfs refuses to use it, or that Linux has problems when using
it?
-Steve
------------------------------
From: rls@dracut.keps.kodak.com (Bob Smith)
Subject: Re: Installing GCC
Date: 22 Jan 92 00:03:21 GMT
In article <3856@umriscc.isc.umr.edu> bolsen@mcs213h.cs.umr.edu (Brian Olsen) writes:
> I've recently pulled down the gcc and tried installing it. Unfortunately I've
> been getting errors about it not being able to find its binaries. I tried
> creating soft links to the files with the gcc- prefix and that helped some,
> but now I'm getting similar errors regarding as and ld.
Put gcc in /usr/bin or some other easily ascessible place, put all the
gcc- prefixed stuff in /usr/lib ... Should work just fine...
--
\ Bob Smith \ mx: bob@snuffy.dracut.ma.us
\ 835 Mammoth Rd. \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
\ Dracut, MA. 01826 \ office && voice mail: +1 508 670-6712
------------------------------
From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: Re: aha-1542 driver
Date: 21 Jan 92 01:02:17 GMT
[Actually To: abc@concert.net, but is bounced and it might have
general interrest.]
drew@hazelrah.cs.colorado is writing a highlevel SCSI driver
and inviting others
to write the coresponding lowlevel driver. I'm writing a
lowlevel driver for aha-1542, first as a fast patch to
make me use my own computer instead of my friends,
later as a better and more general driver.
Depending on the state of the moon, the first attempt could
be finished tomorrow or a week later, anyway I'll post to
alt.os.linux.
/Tommy
--
Tommy Thorn email: tthorn@daimi.aau.dk
Computer Science Department "People shouldn't work because they love it,
Aarhus University they should work because it hurts."
DENMARK -- Bob Sparacino, former Xerox executive
------------------------------
From: pietro@deis35.cineca.it (Pietro Caselli)
Subject: Re: No VI, sorry ...
Date: 22 Jan 92 01:31:44 GMT
In <ANLHILLE.92Jan21185145@cochiti.ucs.indiana.edu> anlhille@cochiti.ucs.indiana.edu (Guess who?) writes:
> Sorry to all the Vi lovers, I`ll devote myself to Emacs.
>What about elVIs or steVIe? elVIs can imitate ex and vi, but I dunno
>about steVIe. elVIs is available SOMEWHERE on wuarchive.wustl.edu.
Well, once you have tasted the feeling of the real Vi, there's no clone
that can sitasfy you. Anyway, maybe I'l test myself on It.
P.S Is there anyone working on a porting on zterm ?
I managed to make it work on Linux, but due to latest things, and since
Andy Tanenbaum wrote ( at least the original term ) for Minix I want to
rewrite it from scratch.
--
Pietro Caselli |
Internet: pietro@deis35.cineca.it | IF YOU MEET THE BUDDHA
zaphod@petruz.sublink.org | ON THE ROAD,KILL HIM.
------------------------------
From: arl@cs.hut.fi (Ari Lemmke)
Subject: Re: /proc, anyone?
Date: 21 Jan 92 16:37:29 GMT
In article <aldavi01.695964381@starbase.spd.louisville.edu> aldavi01@starbase.spd.louisville.edu (Arlie Davis) writes:
> A few seconds ago I read in my mail that Ari was working on pseudo-devices.
> For some reason, that reminded me of /proc.
Not me ;-) I send mail to the mailing list but didn't
mention 'forwarded' I thought it was too obvious because
the mail had part of the original header (send to request).
entropy@ee.wpi.edu is the right one ...
> Well, is anyone eager for /proc? If we have it from the start, then we can
> learn to love it, and eventually perhaps even cherish it...
I have always wanted un*x to have one part of the FS
dynamic (only in memory, it's run-time) where all process etc.
stuff is like:
/system/proc
You might want to send something to one process with
cat foofile > /system/proc/1123
Which could cause signal (and the data) to the process 1123.
But I don't like over crowding / (root) with stuff like
/proc etc. Don't make yet another MessDos with flat
file systems ;-)
arl
------------------------------
From: doleh@Tiger.mcs.kent.edu (Yaser Doleh)
Subject: Re: No VI, sorry ...
Date: 22 Jan 92 03:28:49 GMT
You might be able to compile elivs. elivs is a vi like editor
that is freely available. Try ftp to prep.ai.mit.edu in /pub/gnu
--
===================================================
Yaser Doleh <doleh@mcs.kent.edu>
Department Of Mathematics & Computer Science
Kent State University
------------------------------
From: bb@math.ufl.edu (Brian Bartholomew)
Subject: Yes, but how *big* is it?
Date: 22 Jan 92 03:44:51 GMT
A couple of disk-size related questions, which are all the rage at our
site:
How much disk space does it take to create a working system
consisting of only the compiled binaries?
How much disk space does it take to create a system containing
every bit of source that's available, plus all the binaries,
plus enough free space to remake a second copy of the system
from scratch?
--
"The reasonable man adapts himself to the world: the unreasonable
one persists in trying to adapt the world to himself. Therefore
all progress depends on the unreasonable man." -- George Bernard Shaw
===============================================================================
Brian Bartholomew -- University of Florida Internet: bb@math.ufl.edu
------------------------------
From: cccstevn@elroy.ucdavis.edu (Steven T. Ansell)
Subject: Yes there is a VI (was Re: No VI, sorry ...)
Date: 22 Jan 92 04:32:34 GMT
First of all, I have vi (actually elvis) running under Linux
right now. It is on tsx-11.mit.edu with the rest of the
programs. I haven't given it a real harsh test, but it seems
just fine to me. Second, Elvis is about as close to vi as
you can get. I have been using it under DOS for about a
year hand have seen very few significant differences (and this
is coming from someone who has written some very nasty vi
macros ;-)).
--
-Steven T. Ansell
Unix Consultant
Computing Services U.C.D.
------------------------------
From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Subject: Re: Buggy omit-frame-pointer?
Date: Wed, 22 Jan 1992 05:33:36 GMT
In article <1992Jan21.172326.15406@bmerh2.bnr.ca> dgraham@bmers30.bnr.ca (Douglas Graham) writes:
>For now, I'm cross-compiling Linux from Minix using GCC 1.40. There
>seems to be a problem with variadic routines compiled with
>"-fomit-frame-pointer". At first I though that my version of GCC was
>screwed, but then I noticed that a similar problem shows up in the
>distributed init/main.s.
No, init/main.s is being compiled correctly. I think you're forgetting
about the return address. (If it wasn't being compiled correctly, my
kernel wouldn't be able to boot; and I *know* printf works in
init/main.c :-)
This is what the stack looks like just before the call to vsprintf:
The stack here is growing downwards:
argn |
... | These arguments pushed onto the
arg0 | stack by the caller
fmt |
return addr | pushed on the stack by the call to printk
%ebx | push %ebx
&arg0 | push of leal 12(%esp)
fmt | push of 12(%esp)
_printbuf | push $_printbuf
At this point a call of vsprintf(printbuf, fmt, args) happens.
>Strangely enough, my version of GCC uses an offset of 16 in both places
>where 12 is used above. This is even more wrong. Is this a known bug
>in GCC? If so, why do all the distributed makefiles use -fomit-frame-pointer?
>I couldn't get anything to work until I deleted this from the makefiles.
Is it using an offset of 16 with no other push calls? Is the assembler
code otherwise identical? Or is some other register being saved, like
%ebp? (Not that it should be mucking with the frame pointer anyway,
since it should be able to use a register to save the variable i instead
of needing to allocate space on the stack for it.)
Perhaps your Minix GCC doesn't handle omit-frame-pointer; the GCC 1.40
distributed with Linux certainly works correctly with it. It should be
fine to remove it; -fomit-frame-pointer just makes the resulting
assembler a little bit more tighter and efficient, at the cost of making
the code less debugable. But we don't have a kernel debugger right now
anyway, so we might as well make the code fast. :-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o bloom-beacon!mit-athena!tytso
308 High St., Medford, MA 02155 tytso@athena.mit.edu
Everybody's playing the game, but nobody's rules are the same!
------------------------------
From: rivers@ponds.uucp (Thomas David Rivers)
Subject: cron (vixie-cron) & postings
Date: 22 Jan 92 02:24:03 GMT
Well, since I haven't heard anything about it yet; I've begun working
on a usable cron(1). [You really need one to get decent mail going.]
I grabbed the vixie-cron from comp.sources and after wrestling some
poor memory references (referencing free'd memory) almost have it
working.
The problem I'm having is with sleep() returning too soon. It looks
like the child is dieing, causing a SIG_CHLD; which I should either
catch or ignore - neither of which do much - the sleep is then
terminated, causing the children to be run over and over, more than
once a second!
Ideas???
- Dave Rivers -
p.s. I have the uuencode and uudecode from the BSD source tree ported
(no big deal) - are we going to post small binaries/shar files here,
or should items like this go directly to some/all FTP archives?
------------------------------
From: dgraham@bmers30.bnr.ca (Douglas Graham)
Subject: Re: Buggy omit-frame-pointer?
Date: 22 Jan 92 04:57:25 GMT
In article <1992Jan21.213207.18979@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>Tssk. Be /very/ careful when assuming bugs in gcc: I find it very
>satisfactory, and most bugs aren't in gcc but in the person who thinks
>they are. (Well, there is one known bug in the linux-gcc, but that's
>due to my porting, and doesn't actually make incorrect code).
Blush. I'm usually very cautious when I think I've found a bug in a
compiler. It seems that in this case, I wasn't quite cautious enough.
But for good reason ...
>> _printf:
>> pushl %ebx
>> leal 12(%esp),%eax
>> pushl %eax
>> pushl 12(%esp) !!!! THIS SHOULD BE 8(%esp) !!!!
>> pushl $_printbuf
>> call _vsprintf
>
>No, 12(%esp) is correct. You are forgetting the return address: there
>are three longs on the stack before the push: %eax, %ebx and the return
>address. Thus the offset 12 is correct.
Actually, what I was overlooking was that the "pushl %eax" decremented
the stack pointer. This comes, as you mention, from not being accustumed
to examining code which doesn't use the frame pointer.
>The fact that the resulting
>code actually works should have made you cautious.
Except that, in my case, the resulting code did not actually work.
(The makefile generates main.o from main.c not main.s -- why was main.s
included?) As I mentioned, my version of GCC 1.40 was using an offset of
16 instead of 12, and not only in this file/function. Anyway, I guess
what this means is that I need to take a close look at what I've done
to my GCC, rather than sending off mail to Stallman (or here).
>Not using the frame
>pointer makes for code that is a bit harder to follow, but on a 386
>where the registers are few anyway, I hate to leave one register
>practically unused for no good reason.
One good reason I can think of, is that it allows debuggers to work.
Has GDB been ported to Linux yet?
--
Doug Graham dgraham@bnr.ca My opinions are my own.
------------------------------
From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Subject: Re: Installing GCC
Date: Wed, 22 Jan 1992 06:17:35 GMT
In article <3856@umriscc.isc.umr.edu> bolsen@mcs213h.cs.umr.edu (Brian Olsen) writes:
>I've recently pulled down the gcc and tried installing it.
>Unfortunately I've been getting errors about it not being able to find
>its binaries. I tried creating soft links to the files with the gcc-
>prefix and that helped some, but now I'm getting similar errors
>regarding as and ld.
I've been seeing this question a lot, so I'll pull in something from the
soon to be released (I hope!) FAQ list: (People are working hard on it,
behind the scenes....)
- Ted
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; ggcbin.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.
system.tar.Z contains the latest sources of the system files (mkswap,
mkfs, fsck and fdisk). utils.tar.Z contains a new tar to handle the
symbolic links, make, uemacs and minor programs (sed,...).
------------------------------
** FOR YOUR REFERENCE **
The service addresse, 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
******************************