534 lines
21 KiB
Plaintext
534 lines
21 KiB
Plaintext
Subject: Linux-Development Digest #587
|
|
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
|
|
To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
|
|
Date: Tue, 29 Mar 94 09:13:07 EST
|
|
|
|
Linux-Development Digest #587, Volume #1 Tue, 29 Mar 94 09:13:07 EST
|
|
|
|
Contents:
|
|
Re: Async I/O (David F. Carlson)
|
|
Re: I want real scrollback. (Stefan Dalibor)
|
|
Re: IPX compliancy? (Alan Cox)
|
|
Re: Specialix Driver Round 2 (From specialix) (Alan Cox)
|
|
Re: IPX compliancy? (Alan Cox)
|
|
Raw parallel port device? (Bill Gribble)
|
|
Re: TCP/IP-Bug in 1.0 Kernel? (Alan Cox)
|
|
Full blown setlocale() with support tools (Nickolay Saukh)
|
|
Re: NFS timeouts (Byron A Jeff)
|
|
Re: Adaptec 2742T anyone? (Vinny Andella)
|
|
Kernel compile dying w/SIGSEGV (Douglas Donahue)
|
|
Re: Kernel compile dying w/SIGSEGV (Peter MacLeod)
|
|
fallback during boot in all cases? [was: Re: [moddev README omission]] (Georg Wiegand)
|
|
How to execute SCO binaries ??? (Oliver Wurm)
|
|
Re: PC as C64 file server (Andrew Bulhak)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: dave@valhalla.ee.rochester.edu (David F. Carlson)
|
|
Subject: Re: Async I/O
|
|
Date: 28 Mar 1994 12:52:03 -0500
|
|
|
|
May I suggest rather than using MVS as a model for your async I/O support,
|
|
get a recent draft of the IEEE POSIX1003.4 (nee' 1b) standard. This was
|
|
recently ratified by the IEEE real-time POSIX committee and although not
|
|
perfect contains much insight into the problems you discuss. The hassle
|
|
is that the IEEE has decided to make money on their standards so the documents
|
|
are not ftp'able.
|
|
|
|
Since Linux is already 1003.1 compliant, getting the pieces to 1003.4 in place
|
|
seems like the "Portable" thing to do.
|
|
|
|
|
|
dave
|
|
|
|
------------------------------
|
|
|
|
From: dalibor@faui30.informatik.uni-erlangen.de (Stefan Dalibor)
|
|
Subject: Re: I want real scrollback.
|
|
Date: Mon, 28 Mar 1994 17:51:53 GMT
|
|
|
|
|
|
In article <CnAL7p.72p@cwi.nl>, aeb@cwi.nl (Andries Brouwer) writes:
|
|
|> ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
|
|
|> :Why not put it in the kernel? It seems like a logical place for it. It seems
|
|
|> :like a lot of work have to coordinate the kernel with a user process, and
|
|
|> :could slow down the console driver due to context switching overhead, etc.
|
|
|> :The vt100 emulation is in the kernel already, this wouldn't be much different.
|
|
|>
|
|
|> Answer 1: Because we want to avoid kernel bloat.
|
|
|> Answer 2: Because a user process could give an arbitrary amount of scrollback,
|
|
|> possibly using buffering on disk, while it would not be exactly easy
|
|
|> (or clean) to make the keyboard interrupt routine access a disk file
|
|
|> or swap space.
|
|
|> Moreover, as soon as you have arbitrary scrollback, you'll want to search
|
|
|> for a string, dump parts of the screen to a file, etc.
|
|
|
|
Exactly! And all this exists, ready to run on your Linux box: Screen.
|
|
Scrollback limited only by the amount of RAM/swap-space available, vi-like
|
|
viewing/searching of scrollback-history, dumping of scrollback-history to
|
|
files, switching between umpteen virtual vt100-windows, cut'n'paste between
|
|
those windows (using keyboard commands), rebindable command keys, ability to
|
|
detach and reattach sessions etc. etc.
|
|
Screen performs also great when running in an xterm - IMHO it is one of the
|
|
really indispensable tools, just as important as a good editor or shell.
|
|
|
|
Once you have screen installed, the question of implementing things like
|
|
scrollback in the kernel really becomes irrelevant.
|
|
|
|
Screen-3.5.2 should be available in every GNU-archive, go try it - it makes
|
|
me start to believe the rumours about GUI-oriented environments being less
|
|
productive than state-of-the-art command-line interfaces.
|
|
|
|
Bye,
|
|
Stefan
|
|
---
|
|
Stefan Dalibor dalibor@immd3.informatik.uni-erlangen.de
|
|
http://faui30t.informatik.uni-erlangen.de:1200/Staff/dalibor/dalibor.html
|
|
The louder you scream, the faster we go.
|
|
|
|
------------------------------
|
|
|
|
From: iiitac@uk.ac.swan.pyr (Alan Cox)
|
|
Subject: Re: IPX compliancy?
|
|
Date: Mon, 28 Mar 1994 11:36:19 GMT
|
|
|
|
In article <1994Mar23.040824.23695@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
|
|
>In article <1994Mar22.145503.28541@uk.ac.swan.pyr> iiitac@uk.ac.swan.pyr (Alan Cox) writes:
|
|
>>There is a beta test IPX layer for Linux, but no netware support. Novell
|
|
>>guards its netware details with lawyers and complex licensing agreements
|
|
>>involving thousands of dollars. So forget it - Linux does Lan manager and NFS
|
|
>
|
|
>There is always reverse-engineering.
|
|
>
|
|
Dr.Dobbs journal Nov. 1993 covers most of it. It doesn't help in the slightest
|
|
if you look at the list of alleged software patents that Novell hold
|
|
in the USA. Reverse engineering doesn't exempt you from patents.
|
|
|
|
Alan
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: iiitac@uk.ac.swan.pyr (Alan Cox)
|
|
Subject: Re: Specialix Driver Round 2 (From specialix)
|
|
Date: Mon, 28 Mar 1994 11:45:46 GMT
|
|
|
|
In article <1994Mar23.182432.20120@kbbs.kiel.sub.org> hp@kbbs.kiel.sub.org (Holger Petersen) writes:
|
|
>rogers@drax.isi.edu (Craig Milo Rogers) writes:
|
|
>
|
|
>> Revealing that part of the host-side driver, as by publishing
|
|
>>its source code, would reveal details of the host-side interface which
|
|
>>(at least one) vendor wishes to keep a trade secret.
|
|
|
|
That's their problem. You can always reverse engineer it.
|
|
>
|
|
>Is ther any part in the Gnu-licence that says:
|
|
>
|
|
> "You have to use 'C' as _the_ language " ??
|
|
>
|
|
No but you are required to give the source in its 'preferred form' so you
|
|
can't scramble it up and shield it.
|
|
|
|
Alan
|
|
|
|
|
|
------------------------------
|
|
|
|
From: iiitac@uk.ac.swan.pyr (Alan Cox)
|
|
Subject: Re: IPX compliancy?
|
|
Date: Mon, 28 Mar 1994 11:50:49 GMT
|
|
|
|
In article <Cn6C79.6t0@cnsnews.Colorado.EDU> tierney@rintintin.Colorado.EDU (Craig Tierney) writes:
|
|
>Someone has already done the reverse-engineering. In Dr. Dobbs Journal a
|
|
>few months back, the NCP (Netware Core Protocol) was documented. The NCP
|
|
>is how the Shell(Netx) communicates with the server, on top of IPX.
|
|
>There is also a book that is being released about Netware that covers
|
|
>many of the undocumented aspects.
|
|
|
|
If you've tried playing with this you'll find that its not accurate and
|
|
it doesn't cover a lot of the 'hard' stuff like mapping a drive. I got a
|
|
server hack as far as login then got too busy.
|
|
|
|
Alan
|
|
|
|
------------------------------
|
|
|
|
From: bgribble@jarthur.cs.hmc.edu (Bill Gribble)
|
|
Subject: Raw parallel port device?
|
|
Date: 28 Mar 1994 18:26:08 GMT
|
|
|
|
The only existing drivers using the parallel port (that I have seen) are
|
|
PLIP and lp. I need raw parallel output with no handshaking and these
|
|
devices don't seem to provide it. Should I just kludge up an output-only
|
|
driver or is there enough general interest to write a decent bidirectional
|
|
i/o driver?
|
|
|
|
(alternatively, if someone has already done it I'd be happy to hear!)
|
|
|
|
Bill Gribble
|
|
|
|
|
|
------------------------------
|
|
|
|
From: iiitac@uk.ac.swan.pyr (Alan Cox)
|
|
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
|
|
Date: Mon, 28 Mar 1994 15:03:21 GMT
|
|
|
|
In article <1994Mar26.131145.1087@pe1chl.ampr.org> pe1chl@rabo.nl writes:
|
|
>Getting Alan's new binaries (ifconfig etc) broke it for me. It worked
|
|
>fine before...
|
|
>
|
|
Every copy of this problem I've checked out so far has been old version of
|
|
dip that don't know the new route syntax. So if you have a problem keep the
|
|
old route binary around or upgrade to dip337uri
|
|
|
|
Alan
|
|
|
|
|
|
------------------------------
|
|
|
|
From: nms@ussr.eu.net (Nickolay Saukh)
|
|
Subject: Full blown setlocale() with support tools
|
|
Date: Mon, 28 Mar 94 17:40:48 +0400
|
|
Reply-To: nms@ussr.eu.net
|
|
|
|
I've made new setlocale() with support tools for all LC_*
|
|
types (man pages are included). Previous functionality
|
|
(as in libc-4.5.21) retained. The file is
|
|
|
|
ftp.mrc-apu.cam.ac.uk:/pub/linux/new-locale.tar.gz
|
|
|
|
Known limitations are a) 8 bit codes only; b) depend on endianess.
|
|
|
|
NOTE: signed chars would not work with ctype.h for 8 bit codes.
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.admin
|
|
From: byron@cc.gatech.edu (Byron A Jeff)
|
|
Subject: Re: NFS timeouts
|
|
Date: Tue, 29 Mar 1994 01:35:04 GMT
|
|
|
|
In article <9403282352.AA26078@cs.utexas.edu>,
|
|
Frank Lofaro <ftlofaro@mayall.CS.UNLV.EDU> wrote:
|
|
>In article <1994Mar28.133906.8797@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes:
|
|
>>In article <proff.764778560@suburbia>,
|
|
>>Julian Assange <proff@suburbia.apana.org.au> wrote:
|
|
>>>ward@crl.com (Ward Mullins) writes:
|
|
>>>>I'm trying to use a Linux Box as an NFS server to a Sparc running Solaris
|
|
>>>>2.3, and I keep getting thousands of server timeouts, followed by server
|
|
>>>>OK messages.
|
|
>>>Linux nfs is broken, large reads kill it. Small read (around 512 bytes) are ok,
|
|
>>>with solaris.
|
|
|
|
>>Linux NFS is not broken. It has different buffer sizes than the Sun OS's
|
|
>>(SunOS and Solaris). It's the NFS clients's responsibility to set buffer
|
|
>>sizes. So if anything is broken (and nothing is) then it's Solaris ;-)
|
|
>>
|
|
>>Anyway the solution. When you mount set the buffer size to max 1k. Example:
|
|
>>
|
|
>>mount linux:/ /solaris -o rsize=1024 wsize=1024
|
|
>>
|
|
>>End of problem. I've transferred upwards of 120M at a time (tar backup)
|
|
>>over this kind of interface. No program necessary. Inventive though.
|
|
>>
|
|
>
|
|
>Linux NFS _is_ broken. You don't have to use the rsize wsize kludge for
|
|
>other OS's. It is a restriction that is unique to Linux (possibly plus a
|
|
>small handful of other OS's). This is BAD. I think it is very good that
|
|
>we have Linux and NFS for Linux for free and I am not flaming the net people,
|
|
>they have done a good job so far. It is not yet finished however. This is
|
|
>one of the things which should be given a very high priority.
|
|
|
|
It works. What's the problem? Just because it doesn't have the same size
|
|
buffers as other O.S. doesn't mean it's broken. By that reasoning then
|
|
the Shareware DOS NFS client I'm testing now is broken because it only
|
|
has 1K buffers (actually it is broken, long story).
|
|
|
|
What I can't figure out is why NFS doesn't have a negotiation phase where
|
|
the client and server can decide on the proper buffer size. Doesn't seem
|
|
hard. Broken specification, not broken implementation.
|
|
|
|
Anyway the only time you have problems is when you're unaware of the
|
|
buffer size differences. And if rsize and wsize are such kludges then why
|
|
does the originator of NFS (sun) have it in their mount code? Is there
|
|
something in the NFS specification that says that the buffers must be a minimum
|
|
size? What about when you're running NFS over SLIP and can't do fragment
|
|
re-assembly (smaller buffer sizes solve that problem)? Is Solaris NFS broken
|
|
then? Not a kludge, just added flexibility.
|
|
|
|
All I know is that if I set the buffer size right then everything works.
|
|
|
|
But back to the questions: why is Linux NFS limited to 1K buffers? How
|
|
difficult would it be to fix?
|
|
|
|
Note that I'm not bitching. I think it's fine just the way it is.
|
|
|
|
Followup to c.o.l.development.
|
|
|
|
BAJ
|
|
---
|
|
Another random extraction from the mental bit stream of...
|
|
Byron A. Jeff - PhD student operating in parallel!
|
|
Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu
|
|
|
|
------------------------------
|
|
|
|
From: vandella@world.std.com (Vinny Andella)
|
|
Subject: Re: Adaptec 2742T anyone?
|
|
Date: Tue, 29 Mar 1994 00:55:10 GMT
|
|
|
|
David Rapchun (rapchun@suicide.sdsu.edu) wrote:
|
|
|
|
: Hello, I understand there are some people working on writing a driver for
|
|
: the Adaptec 7770 series chip. IE, the 2742 and 2842 both use this new chip.
|
|
: I was just wondering how the work is coming along since I would really like
|
|
: to run Linux soon. Thanx.
|
|
|
|
: Dave.
|
|
|
|
: --
|
|
: *******************************************************************************
|
|
: * rapchun@mintaka.SDSU.edu Dave Rapchun *
|
|
: *******************************************************************************
|
|
|
|
|
|
PLEASE SEND HELP !!!!!!!!!!!!!!!!!!!!!!!!
|
|
|
|
I have a killer 486 66, with an Adaptec 2842 VL controller, I want to run
|
|
Linux too. I got the CD 3 weeks ago and have been searching the internet
|
|
for HELP !!!!!!
|
|
|
|
Please send any information to vandella@world.std.com
|
|
|
|
If a driver has not been developed yet please tell me the time frame for it.
|
|
|
|
Thanks
|
|
|
|
Vinny Andella
|
|
|
|
|
|
------------------------------
|
|
|
|
From: odoncaoa@panix.com (Douglas Donahue)
|
|
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,alt.uu.comp.os.linux.questions
|
|
Subject: Kernel compile dying w/SIGSEGV
|
|
Date: 28 Mar 1994 15:54:09 -0500
|
|
|
|
|
|
Greetings,
|
|
|
|
Over the course of the weekend, I attempted to recompile the kernel. The first
|
|
attempt was sucessful. However, subsequent attempts failed with what would
|
|
appear to have been segmentation violations. A representative error message
|
|
follows. The strange part of it though, is that the compile failed at a very
|
|
early point in the remake on one attempt, but breazed right through the same
|
|
point in the compile on a subsequent attempt. It's obvious to me that there
|
|
are not any errors in the source that are generating such problems. e.g.
|
|
dividing by zero. Has anyone else had such experiences? How about one of the
|
|
compiler and/or kernel experts speaking up? What would cause the compiler to
|
|
fail with a segmentation violation when one doesn't actually exist? What
|
|
would cause the kernel to generate such a signal and kill the compiler?
|
|
|
|
A representative failure message:
|
|
.
|
|
.
|
|
gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe \
|
|
-m386 -c -o init/main.o init/main.c
|
|
gcc: Internal compiler error: program cc1 got fatal signal 11
|
|
make: ***[init/main.o] Error 1
|
|
cpp: output pipe has been closed
|
|
|
|
Oh yea, 'signal 11' is defined in /usr/src/linux/signal.h as 'SIGSEGV'.
|
|
|
|
Cheers,
|
|
|
|
Doug Donahue
|
|
|
|
------------------------------
|
|
|
|
From: macleod@adoc.xerox.com (Peter MacLeod)
|
|
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc,alt.uu.comp.os.linux.questions
|
|
Subject: Re: Kernel compile dying w/SIGSEGV
|
|
Date: 29 Mar 1994 02:21:24 GMT
|
|
|
|
Douglas Donahue (odoncaoa@panix.com) wrote:
|
|
|
|
: Greetings,
|
|
|
|
: Over the course of the weekend, I attempted to recompile the kernel. The first
|
|
: attempt was sucessful. However, subsequent attempts failed with what would
|
|
: appear to have been segmentation violations. A representative error message
|
|
: follows. The strange part of it though, is that the compile failed at a very
|
|
: early point in the remake on one attempt, but breazed right through the same
|
|
: point in the compile on a subsequent attempt. It's obvious to me that there
|
|
: are not any errors in the source that are generating such problems. e.g.
|
|
: dividing by zero. Has anyone else had such experiences? How about one of the
|
|
: compiler and/or kernel experts speaking up? What would cause the compiler to
|
|
: fail with a segmentation violation when one doesn't actually exist? What
|
|
: would cause the kernel to generate such a signal and kill the compiler?
|
|
[etc]
|
|
|
|
I used to get this all the time. Then I changed the timing on my motherboard,
|
|
and it went away completely--I haven't had a problem since, and I've rebuilt
|
|
the kernel many times.
|
|
|
|
This has been discussed before, and the culprits blamed were ISA<->memory
|
|
transfers, motherboard memory itself, and the phases of the moon. It
|
|
would appear that simple tests, especially DOS- or Windows-based tests,
|
|
don't pound the machine hard enough, so rebuilding the Linux kernel is a
|
|
pretty good test. In any case, you can imagine that if gcc started paging,
|
|
and one of the paging transfers had an error in it, thus changing the
|
|
code, you could get a seg. violation. One problem with the kernel, at
|
|
least the last time I looked, is that a lot of the hardware traps
|
|
are mapped to one signal, segmentation violation. I'm not sure if that's
|
|
a POSIX thing or what, but it does make figuring out what's going on
|
|
a bit of a hassle.
|
|
|
|
Anyway, if your motherboard has lots of settings like mine does, start
|
|
changing things like ISA bus speed, DRAM wait states, ISA bus wait states,
|
|
etc. If it doesn't, you might be SOL. I think the thing I did that made
|
|
the most dramatic difference was slowing the ISA bus down to 8 Mhz.
|
|
A lot of motherboards have a 12Mhz setting, and many ISA bus cards
|
|
are unreliable at 12Mhz. Others have found that replacing SIMMs cured their
|
|
problems.
|
|
|
|
Also, if you have a 50Mhz DX motherboard, like I do, you might just want to
|
|
replace it with a 66Mhz DX2...Oh, another thing I've remembered--when I
|
|
first got my motherboard, it crashed a lot, and the problem turned out to be
|
|
that I had a 50Mhz motherboard with cache RAM for a 33Mhz motherboard, so
|
|
make sure that your cache SRAMs are fast enough.
|
|
|
|
-- Peter
|
|
|
|
------------------------------
|
|
|
|
From: gw@gwcomp.e.open.de (Georg Wiegand)
|
|
Subject: fallback during boot in all cases? [was: Re: [moddev README omission]]
|
|
Date: Mon, 28 Mar 1994 21:56:37 GMT
|
|
Reply-To: gw@gwcomp.e.open.de
|
|
|
|
In article <1994Mar26.194716.18712@afterlife.ncsc.mil>,
|
|
John Epstein <jepstei@afterlife.ncsc.mil> wrote:
|
|
>There is an important omission in moddev-0.1 README file.
|
|
>The lines to add to rc.local should be
|
|
>/sbin/insmod /sbin/moddev.o
|
|
>modload &
|
|
>
|
|
>The README file omitted the "&" --- booting will not finish!!!
|
|
>It did say modload runs in the background, which subtley implies
|
|
>that the "&" is needed.
|
|
>
|
|
>That is why one should ALWAYS have a fall back method of rescuing
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
>one's system.
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
>
|
|
>John
|
|
|
|
BTW:
|
|
What could it be to watch *all* possible errors during bootup ?
|
|
|
|
To put a line like:
|
|
trap 'echo -e "rc: status -- $?\ngoing single user .."; /bin/sh' 1 2
|
|
probably in every /etc/<whatever_is_executed> (rc, rc.local, rc.(i)net)
|
|
|
|
I'm shure there are better solutions ?
|
|
|
|
george
|
|
|
|
--
|
|
*******************************************************************************
|
|
# Georg Wiegand |Email: gw@gwcomp.e.open.de #
|
|
# University Essen, Germany |Phone/Fax: +49 201 495192 #
|
|
*******************************************************************************
|
|
|
|
------------------------------
|
|
|
|
From: owurm@k.mup.de (Oliver Wurm)
|
|
Crossposted-To: comp.os.linux.misc,comp.os.linux.admin,comp.os.linux.help
|
|
Subject: How to execute SCO binaries ???
|
|
Date: 28 Mar 1994 08:17:45 GMT
|
|
|
|
Hi everybody,
|
|
|
|
there is only one reason for us to run our SCO UNIX server under SCO UNIX:
|
|
We need some of the SCO-Programs installed there.
|
|
I've read some time ago in one of the comp.os.linux.??? Newsgroups about
|
|
an iBCS - Emulator, which is able to run the SCO binaries, but I can't find
|
|
it on the ftp servers (most of them are SunSITE-mirrors).
|
|
|
|
**PLEASE** mail me the name of a ftp server and the path to the iBCS stuff.
|
|
|
|
Thanks in advance,
|
|
|
|
Oliver Wurm \\\//
|
|
EMail: owurm@k.mup.de (o o)
|
|
==============================ooO=(_)=Ooo======================
|
|
, , , , ,---, ,
|
|
|\./| ___ ___ _ _~|~ -+- |---'_ _~|~ _ _ _
|
|
| | |_| | | | | | | |_~ | |_ ' | |_| | |_ | | |_~ |
|
|
____________________Unternehmensberatung GmbH__________________
|
|
Neue Weyerstrasse 6 Tel: +49 (221) 92404 227
|
|
D-50676 Koeln Fax: +49 (221) 92404 199 (-33 from US)
|
|
|
|
------------------------------
|
|
|
|
From: acbul1@lindblat.cc.monash.edu.au (Andrew Bulhak)
|
|
Crossposted-To: comp.sys.cbm
|
|
Subject: Re: PC as C64 file server
|
|
Date: 29 Mar 1994 05:34:56 GMT
|
|
|
|
Sven Goldt (goldt@math.tu-berlin.de) wrote:
|
|
: paul (paul@dino.eng.monash.edu.au) wrote:
|
|
: : Ok,
|
|
: : It seems quite clear that there is a need for a device that allows
|
|
: : a standard ibm pc to be used as a file server for our humble ol' Commodore
|
|
: : 64's. Is anyone working on such a device? What do people think about the idea?
|
|
: : Is it possible ??
|
|
|
|
: Well,it IS possible.If i find the time i will write such
|
|
: a client/server package.The HD could be accessed just like a
|
|
: normal floppy.I think the c64 part could act like a
|
|
: fastloader and the PC (server) part as a device driver or tsr program,but
|
|
: i prefer to use a server under unix.
|
|
|
|
I was thinking of a Linux daemon which polls a device on /dev/lp0 or
|
|
somewhere and acts as a virtual 1541. That way, this would place a very
|
|
light load on the machine, allowing it to be used for other tasks as
|
|
well.
|
|
|
|
Another Linux/1541 project, the reciprocal of this, would be a 1541 file
|
|
system which uses the X1541 cable.
|
|
|
|
--
|
|
Andrew Bulhak acb@yoyo.cc.monash.edu.au
|
|
Slackware: The Linux of the SubGenius.
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@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
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|