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

532 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: Tue, 4 Feb 92 16:00:34 EST
Subject: Linux-Activists Digest #37
Linux-Activists Digest #37, Volume #1 Tue, 4 Feb 92 16:00:34 EST
Contents:
Re: Serial support (Charles Hedrick)
lp patch 0.12 (jim wiegand)
new mg (micrognu) (Charles Hedrick)
Re: Assembler info (Drew Eckhardt)
Anomalies with vixie-cron (kleinow@engin.umich.edu)
cannot open lock file? (mounting a new drive) (Morgan Schweers)
Re: more and icon ports available (Pietro Caselli)
Re: TODO List (Is there such a beast?) (Robert Blum)
tubes (Lawrence C. Foard)
Re: Q: What is POSIX limit on filename length? (Tommy Thorn)
hang again (Mika Matti Jalava)
could you distribute the sources? (Mika Matti Jalava)
Re: Serial support (Peter Galbavy)
Re: Serial support (Linus Benedict Torvalds)
Re: Help: bug in ld(?) and where I can find its source code (Derek Lieber)
Deadline for 0.13 (Linus Benedict Torvalds)
----------------------------------------------------------------------------
From: hedrick@dumas.rutgers.edu (Charles Hedrick)
Subject: Re: Serial support
Date: 4 Feb 92 04:55:23 GMT
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. What you want it to do is to put the
character into a buffer and dismiss the interrupt. Then the actual
processing would be done at a higher level that does not lock out the
tty interrupts. Microport SV/AT used this strategy, and could handle
9600 bps on a 286, though it was sort of marginal. Since the minimum
system that can run Linux is a 386sx, that ought to be enough CPU to
handle 9600 bps reliably if things are coded correctly.
------------------------------
From: jim wiegand <V5068U%TEMPLEVM.BITNET@mitvma.mit.edu>
Subject: lp patch 0.12
Reply-To: V5068U%TEMPLEVM.BITNET@mitvma.mit.edu
Date: Tue, 4 Feb 1992 06:33:34 GMT
hi all;
sorry to hear about the problems you are encountering.
what i think is happening here is that there are port
addresses that are weird. i used only the PC port
numbers & since DOS is an OEM product, the ports can
take on ANY unused port number(!).
in order to make the patch work for everybody,
I NEED YOUR HELP.
Please provide the following info:
1. Computer model
2. Name of parallel/serial card if add-in
3. Any messages that begin with "lp:"
4. All printer port addresses
what i can suggest immediately is to get a hold
of something like Norton SI or Check-It! to find out
exactly where your ports are at. Then you can patch the
addresses into lp_table & get on with it.
If it turns out there is a more pathological problem
with the driver i can provide a debugging version.
jim wiegand *** v5068u at vm.temple.edu *** v5068u at templevm.bitnet
* Please send all bug reports directly to v5068u at vm.temple.edu
*
* "When you have elinimated the impossible, whatever remains, however
* improbable, must be the truth." -The Sign of Four, Arthur Conan Doyle
------------------------------
From: hedrick@dumas.rutgers.edu (Charles Hedrick)
Subject: new mg (micrognu)
Date: 4 Feb 92 07:22:54 GMT
I just put a new mg on athos.rutgers.edu:/pub/linux. mg is the
binary, mg.tar.Z the source (include TeX source for the manual).
Changes from last time:
- ^Z suspends it
- changed several fields from short to int
The second change was necessary to fix problems caused when editing
files with very long "lines", e.g. the linux binary Image file.
If there were more than 32K characters between successive newlines,
the line length field would become negative.
Again, mg requires a patch to the kernel to implement nonblocking
I/O. It's nonblock.tar.Z (unchanged from last time).
I would recommend using mg as the editor in the distribution, rather
than em. It's both smaller and better (in my view). It's certainly
closer in style to Gnu Emacs. (I'm assuming that Gnu Emacs is large
enough that we won't want it in the basic utilities distribution.)
I've also put my .mg (startup file for mg) in /pub/linux. It defines
the keypad arrow keys and other things, and it sets up automatic paren
and brace matching.
I'm assuming that the masters of the archives are tracking my
postings, and putting stuff onto the archive machines. I don't
want to keep it on athos forever.
------------------------------
From: drew@anchor.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Assembler info
Date: Tue, 4 Feb 1992 07:55:08 GMT
In article <1992Feb4.013752.23676@athena.mit.edu> satishc@microsoft.com writes:
>The assembler syntax used by GCC is markedly different from the Intel
>assembler syntax. Where can I find a ps or nroff document that describes
>the syntax used by GCC? Could someone give me a pointer?
>
>Thanks.
>
Find some one with TeX installed to change the GNU texinfo to postscript
for you - most gnu software has TeX manuals, available from the usual
places (ie prep.ai.mit.edu, etc.)
------------------------------
From: kleinow@engin.umich.edu
Subject: Anomalies with vixie-cron
Date: 2 Feb 92 19:51:46 GMT
I'm having difficulties with the cron program that's on tsx-11.mit.edu,
Paul Vixie's cron ported by Dave Rivers. It never executes any commands,
but it does fork off a new process periodically, and after an hour, the
results of the "ps" command show about 50 copies of /etc/crond running.
The system is Linux-0.12 with floppy driver, lp driver, "ps" patches,
and the crond and crontab programs are those on tsx-11. Can anyone diagnose
this error? Anyone got this cron working correctly?
Thanks,
Leonard Kleinow
kleinow@warhol.art.umich.edu
------------------------------
From: mrs@netcom.COM (Morgan Schweers)
Subject: cannot open lock file? (mounting a new drive)
Date: 4 Feb 92 09:18:24 GMT
Greetings,
I just did a 'mkfs -c /dev/hd3', and attempted a 'mount /dev/hd3 /u1'
and it returned 'mount: unable to open lock file'. Any suggestions? (As
I recall, this is the standard patched mount.)
Any help would be mucho appreciato!
-- Morgan Schweers
--
Hacker, Furry, SF reader, gamer, art collector, writer. 24 hours isn't enough.
mrs@netcom.com | I'm a practicing furry! Some day I hope all the practice
Freela @ Furry | will pay off, and I'll grow fur! -- me
K_Balore @ Furry |___________________ CLEAN C:\USR\SPOOL\*.* [SigVir] /SUB
Hi! I'm a .signature virus! Add me to your .signature and join in the fun!
------------------------------
From: pietro@deis35.cineca.it (Pietro Caselli)
Subject: Re: more and icon ports available
Date: 4 Feb 92 11:26:53 GMT
In <Feb.3.23.15.23.1992.9519@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
> doesn't seem to be in libc. I had to hack on regex
> slightly, since it uses bcmp and bzero, which also aren't
> in the library, and alloca. I tried using alloca from
> the Gnu Emacs source, but it ran me out of memory. It
> turns out to be easier (and I think results in better
> code) to remove the use of alloca.
Why did you removed alloca ?
alloca is builtin with gcc, so ... are you using a different
compiler ?
Perhaps we could
> add this regex to libc, and probably also add bcmp, bzero,
> and bcopy, or the System V memxxx versions. Don't
> take them from regex, by the way -- this version of bcmp
> probably doesn't do quite what you want the library
> routine to do.
I didn't studied regex source wery well, but It seems that regex
changes from sources to sources. ( well at least it changes in
size. ).
Regarding bcopy, bzero and bcmp you can add some defines in
include/sys/types.h.
Ciao.
--
Pietro Caselli |
Internet: pietro@deis35.cineca.it | IF YOU MEET THE BUDDHA
zaphod@petruz.sublink.org | ON THE ROAD,KILL HIM.
------------------------------
From: blum@rama.informatik.rwth-aachen.de (Robert Blum)
Subject: Re: TODO List (Is there such a beast?)
Date: 4 Feb 92 10:04:08 GMT
mrs@netcom.COM (Morgan Schweers) writes:
>Greetings,
> I've been told that some of what I'm hacking on is being worked on
>by others. (Not that I'm going to stop because of that. I'm having
>too much fun!) The one message that surprised me, was a reference to
>a TODO list.
I am(was?) maintaining the TODO list
> I'd very much like to see this 'TODO' list, since the last one I
>have suggested that VFS might be implemented in time for 0.11. (Got
>an idea of how far back that was?)
This was the time I stopped. I several times asked people to announce to me
what they were going to port, but there was *NO* feedback.
But let's give it another try: If anybody is working on any Linux
enhancements, please mail to
blum@messua.informatik.rwth-aachen.de
The reason for this request for mail is simple:
I have some exams coming, and almost no time to read every single mail/posting
> I've picked up a bunch of login, etc., programs and will be
>figuring out what I'm missing tonight, and hopefully implementing it.
--
UNIX should not be able to be crashed from user space.
Crashes belong in the kernel! (paul@actrix.gen.nz)
------------------------------
From: entropy@ee.WPI.EDU (Lawrence C. Foard)
Subject: tubes
Reply-To: entropy@ee.WPI.EDU (Lawrence C. Foard)
Date: Tue, 4 Feb 1992 12:36:01 GMT
I decided to call the IPC stuff tubes, its similar to sockets but much
simpler. A few questions about preferences:
The standard linux pipes always return with the read buffer full except
when the pipe has been closed on the writting end. This works well for
one way pipes but doesn't work for server/client communications where
you have requests and responces going back and forth. Here are a few things
I'm wondering about.
Read has several possibilities:
1) Return only data in the buffer unless there is none then block (unless
O_NONDELAY is on).
2) Try to read as much as one write call produced even if it doesn't fit
in the buffer. This is rather messy since it has to keep track of where
write calls ended.
3)Have it default to #1 and have an IOCTL to switch it back to totally
fullfilling each read request when possible.
I'm leaning toward 3 at this point, since this will work with the line
based I/O that most demons expect. Demons expecting fixed sized data can
switch it to the other mode. Does any one know of programs that would
have problems with this?
Write also has several possibilities:
1) Write all data requested unless the pipe breaks, if O_NONDELAY then
it will just write what will fit in the buffer.
2) Always write only what will fit in the buffer unless it is 0 then block.
I'm leaning toward 1 at this point, can any one see any reason why #2 would be
better?
(am I write in assuming O_NONDELAY is the same as FNDELAY?)
I've got a system call tube(fd[2],type) working which creates a bidirectional
connection and returns the descriptors for each end. type can be the following
TU_STREAM- bidirectional stream
TU_RANDOM- random access requests passed on the server (lseek works)
TU_FS- file system requests passed on to server
TU_FIFO- a plain old fifo (same as pipe(fd[2]))
[possibly another type designed for datagrams]
Currently only TU_STREAM is implemented. The next stage is making this work
when a tube special file is opened. Does any one know where I can get the
source to ls, mknod etc, I didn't see these utilities in the tsx-11 archives
and I will need to patch them.
------------------------------
From: tthorn@daimi.aau.dk (Tommy Thorn)
Subject: Re: Q: What is POSIX limit on filename length?
Date: 4 Feb 92 08:34:17 GMT
I don't think 14 is a POSIX standard, but anyway the limit
will be 255 once we get Berkeley Fast File System (FFS (ufs)).
VFS is not much (nothing?) in itself, but a stub for other
file systems, like nfs.
/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: r36110m@kaira.hut.fi (Mika Matti Jalava)
Subject: hang again
Date: 4 Feb 92 09:41:23 GMT
I got my system hang again. As I reported once, linking GNU emacs
caused sometimes the system hang so that in the other virtual consoles
I could only execute one command (sync...) before they hung too.
Now I saw the same symptoms while mv'ing a couple of big files to
another partition. I had kermit running in one vc, the mv was going in
one, and I executed ls in the third when it hung. I could sync the fs
from the remaining vc's, but after the first sync each of them died.
The result was only a lot of blocks marked used but not really being
used on the target partition, and fsck fixed it. But anyway, this
doesn't seem to be as reliable as it should be.
My system is a 386-25 with 4M RAM and 8M swap, 115M ESDI drive (the
one that works OK, at least otherwise...) with 4 linux partitions
(32M, 32M, 32M and 8M swap).
Mika
------------------------------
From: r36110m@kaira.hut.fi (Mika Matti Jalava)
Subject: could you distribute the sources?
Date: 3 Feb 92 21:45:40 GMT
I think it would be nice if also the sources of the programs ported to
linux were available at the ftp sites. Or in the case of GNU emacs and
such enormous packages, at least the diffs. Actually, I think in the
case of GNU programs this is even required.
This would be nice in case you want to change the configuration of a
program, or just for learning what changes have been needed to port
something to linux.
Mika
------------------------------
From: peter@micromuse.co.uk (Peter Galbavy)
Subject: Re: Serial support
Date: 4 Feb 92 11:17:06 GMT
ramesh@utdallas.edu (R. Ramesh) writes:
>This is not trying to solve your problem but... I am running kermit at 19200
>and not having any problem at all. In fact at times when a file is being
>transferred I loaded the system using one of the other virtual consoles. But
>I am a 486/33Mhz user. So the hardware may be more capable.
>BTW, I even tried running at 38400 (by cheating kermit by doing "stty 38400
>>/dev/tty65") and still it worked fine.
Maybe a stupid question, but will FAS port to Linux ?
>Ramesh
--
Peter Galbavy
Tech Support, Micromuse Ltd
Phone: +44 71 352 7774 E-Mail: P.Galbavy@micromuse.co.uk
"Sometimes I get a hunch, not an idea, not even a feeling, more like
a rabbit punch to the base of the brain." - Lobster Man From Mars.
------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: Serial support
Date: 4 Feb 92 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
------------------------------
From: derek@watson.ibm.com (Derek Lieber)
Subject: Re: Help: bug in ld(?) and where I can find its source code
Date: 4 Feb 92 14:06:18 GMT
Reply-To: derek@watson.ibm.com (Derek Lieber)
In article <1992Feb3.225424.20176@athena.mit.edu> hlu@eecs.wsu.edu writes:
>Hi,
>
>I am trying to compile GNU's binary utilities 1.9. Everything works
>fine, except ld, which reports "virtual memory exhausted". The one I
You've been bitten by linux's malloc(0) == NULL "feature".
You'll have to change the xmalloc() function to do a check for
a 0 byte request.
--
Derek Lieber
derek@watson.ibm.com
------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Deadline for 0.13
Date: 4 Feb 92 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
------------------------------
** 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
******************************