544 lines
20 KiB
Plaintext
544 lines
20 KiB
Plaintext
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: Sat, 24 Sep 94 21:13:12 EDT
|
|
Subject: Linux-Development Digest #222
|
|
|
|
Linux-Development Digest #222, Volume #2 Sat, 24 Sep 94 21:13:12 EDT
|
|
|
|
Contents:
|
|
Re: TAR or Streamer problem! (Joerg Schneider)
|
|
Re: [STATUS] Linus Floppy Driver Development (Alain Knaff)
|
|
Re: Err in _floppy_release only if mounted at boot (Alain Knaff)
|
|
Sequential IO only thing lacking in Linux ... (L.G. "Ted" Stern)
|
|
Re: Shared Libs: working toward a permanent solution? (Richard Krehbiel)
|
|
What is the status of LINUX/PPC port? (Tony Jones)
|
|
Re: [STATUS] Linus Floppy Driver Development (David C. Niemi)
|
|
Re: "guide" (xviews) for Linux ? (Orhan Unal)
|
|
Re: Porting applications to TERM (Bill C. Riemers)
|
|
Re: Pointer to cyclades (Bob Salita)
|
|
Re: Shared Libs: working toward a permanent solution? ("Theodore Ts'o")
|
|
Re: What user interface to use??? (Jeff Kesselman)
|
|
Re: polled ports ("Theodore Ts'o")
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: uk9o@rzstud1.rz.uni-karlsruhe.de (Joerg Schneider)
|
|
Subject: Re: TAR or Streamer problem!
|
|
Date: 24 Sep 1994 20:58:24 GMT
|
|
|
|
A.Couture@agora.stm.it wrote:
|
|
|
|
[...]
|
|
: What is the tape length? Here is what I get, I know that the 'unformated'
|
|
: tape is 120MB for a Jumbo250, but once formatted???
|
|
|
|
4200 `segments' = 4200 * 29KB = 121800 KB (if there are no errors on
|
|
the tape)
|
|
|
|
: I have done a simple test which has run ok.
|
|
: dd if=/dev/zero of=/dev/ftape count=120 bs=1024k
|
|
|
|
: This was supposed to write 120MB of null to the tape.
|
|
: Returned no errors.
|
|
|
|
: now when I use tar then there seem to have some problems writing to the
|
|
: tape, ALWAYS get I/O errors.
|
|
|
|
: Here is the command used with WinTar:
|
|
: > rsh explorer "tar -cvf - @\\cyborg\dosc\wapps\explorer.bkf -L 120M -V
|
|
|
|
: Explorer" | dd bs=10240 of=/dev/ftape
|
|
|
|
: Here is the results:
|
|
|
|
: dd: /dev/ftape: I/O error
|
|
: 0+11356 records in
|
|
: 0+11355 records out
|
|
: |
|
|
|
|
|
|
: Note that for every test the records count differ (+-500 @ 11356).
|
|
|
|
????
|
|
|
|
Have a look at your syslog for more info what is happening (debugging
|
|
level of ftape can be set with `mt fsr <level>').
|
|
|
|
Perhaps it's only a missing `mt erase' ...
|
|
|
|
Hope it helps.
|
|
|
|
--
|
|
Joerg Schneider -- e-mail: schneid@ira.uka.de -- phone: +49 721 607140
|
|
s-mail: Gerwigstr. 13, 76131 Karlsruhe, FRG
|
|
|
|
------------------------------
|
|
|
|
From: knaff@ngulu (Alain Knaff)
|
|
Subject: Re: [STATUS] Linus Floppy Driver Development
|
|
Date: 23 Sep 1994 10:38:00 GMT
|
|
Reply-To: Alain.Knaff@imag.fr
|
|
|
|
Larry Doolittle (doolitt@recycle.cebaf.gov) wrote:
|
|
[auto mounting a floppy as soon as it is inserted]
|
|
: This situation cries out for a Kernel hook, and the ability
|
|
: to have a floppy_mount_daemon that gets activated when the
|
|
: user puts in a floppy (periodic disk-change check?).
|
|
Unfortunately, this seems to be impossible to do on PC hardware.
|
|
There are no separate disk change and disk presence indicators
|
|
available. The disk change indicator gets set when set when no disk is
|
|
present in the drive. It isn't cleared when a disk is inserted
|
|
however. Only a seek clears it. Thus a program wanting to detect when
|
|
a disk is inserted would need to seek endlessly until a disk is
|
|
inserted. This would make a rather annoying noise, and would probably
|
|
wear off the stepper motor as well.
|
|
|
|
--
|
|
Alain
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: knaff@ngulu (Alain Knaff)
|
|
Subject: Re: Err in _floppy_release only if mounted at boot
|
|
Date: 23 Sep 1994 10:54:43 GMT
|
|
Reply-To: Alain.Knaff@imag.fr
|
|
|
|
As Andries Brouwer (aeb@cwi.nl) already pointed out in an earlyer
|
|
message to this same thread, the fix for all these mount/unmount
|
|
problems is to replace the following line in floppy release
|
|
if(filp->f_mode & 2)
|
|
with
|
|
if( !filp || (filp->f_mode & 2))
|
|
|
|
The problems occured when trying to mount a floppy disk with an
|
|
invalid file system or when trying to unmount a floppy disk. This is
|
|
because unmount uses a NULL file pointer. The replacement line needs
|
|
to be 'if( !filp || (filp->f_mode & 2))' and NOT 'if( filp &&
|
|
(filp->f_mode & 2))' because we want to do the syncing (fsync_dev) for
|
|
mounts too. The only time when we don't need to sync is on read-only
|
|
opens.
|
|
|
|
The mount point is irrelevant for the problem to occur.
|
|
|
|
The mount/unmount doesn't need to be done right after boot either for
|
|
the problem to occur. However, once this occurs, the same floppy
|
|
device and mount point cannot be mounted again, as the kernel thinks
|
|
that it is still mounted. After clearing /etc/mtab~ and mounting
|
|
another floppy device at another mount point the problem will occur
|
|
again.
|
|
|
|
Alain.
|
|
|
|
------------------------------
|
|
|
|
From: stern@amath.washington.edu (L.G. "Ted" Stern)
|
|
Subject: Sequential IO only thing lacking in Linux ...
|
|
Date: 21 Sep 1994 22:35:18 GMT
|
|
|
|
|
|
Hi -- I am posting the contents of e-mail sent to me regarding the recent BYTE
|
|
article evaluating a Fintronics Linux system. Apparently the only thing
|
|
lacking in Linux as opposed to other X86 PC *nices is the sequential IO
|
|
ability. The relevant paragraphs are marked with arrows on the right side.
|
|
|
|
NOTE that the original writer is full of praise for Linux! He simply would
|
|
like there to be some indication of how to get better seq. IO out of the
|
|
system.
|
|
|
|
Replies not necessary. It would be sufficient if the appropriate developer
|
|
sees this and takes due action. However if you do so, you might want to let
|
|
Al know.
|
|
|
|
Thanks for all the hard work!
|
|
|
|
===========Begin included message =========================
|
|
Date: Wed, 21 Sep 94 12:53:38 -0700
|
|
From: Al Goldstein <al@nsr.bioeng.washington.edu>
|
|
To: stern@amath.washington.edu
|
|
|
|
hi Mihail, [ I don't know why he is referring to me this way!]
|
|
|
|
Here is a comment on Bruce Dawson's article. As Bruce Dawson says (he mailed
|
|
us the benchmarks) the benchmarks are generally good. We just got a
|
|
Fintronic machine and have run these benchmarks also.
|
|
|
|
Some tests were outstanding and all were very good except one. That test <----
|
|
concerns sequential disk IO. A sparc10 has the same Drystones as Linux <----
|
|
running a 486dx2; yet with the same disk (possibly a better scsi adaptor) <----
|
|
the sparc10 does the byte io test 4 times faster. Similarly comparing <----
|
|
a SVR4 box running a 486 the sequential IO is much better. This is the <----
|
|
Byte 30 second file copy test.
|
|
|
|
Unix systems with the Berkeley fast file system have provision for "tuning" <----
|
|
the file system; this feature seems as of now to be lacking in Linux. <----
|
|
|
|
Nevertheless Linux is a great achievement, mainly because the source code
|
|
is given and so many people are interested in furthering it..
|
|
I don't think it would hurt to voice my complaint with a posting in the
|
|
hopes of future improvements.
|
|
|
|
Let me know if you are interested in seeing these benchmarks.
|
|
|
|
-Al Goldstein
|
|
|
|
=============End Included Message===============================
|
|
--
|
|
-- Ted
|
|
______________________________________________________________________________
|
|
Ted Stern <stern@amath.washington.edu> UW phone: (206) 685-8068
|
|
Dept. of Applied Math, FS-20 University of Washington Seattle, WA 98195
|
|
==============================================================================
|
|
|
|
------------------------------
|
|
|
|
From: richk@netcom12.netcom.com (Richard Krehbiel)
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: Wed, 21 Sep 1994 20:33:15 GMT
|
|
|
|
|
|
Why is everyone hung up on PIC for shared libraries?
|
|
|
|
Why not this way: Take a fairly large chunk of process virtual address
|
|
space, say 64M or so, and reserve it for shared library code and data.
|
|
When a shared library is loaded, find an available spot in that range,
|
|
load it, and then fix up self-relative code and data references with
|
|
the library's relocation dictionary. This way you don't pay the
|
|
performance penalty of PIC, and you still avoid library load address
|
|
conflicts. You have to worry about whether all libraries loaded by
|
|
all processes will fit into 64M, of course, and someone will have to
|
|
write a relocating loader.
|
|
--
|
|
Richard Krehbiel richk@netcom.com
|
|
Picture a clever one-liner here...
|
|
|
|
------------------------------
|
|
|
|
From: tony@odin.sunquest.com (Tony Jones)
|
|
Crossposted-To: comp.sys.powerpc
|
|
Subject: What is the status of LINUX/PPC port?
|
|
Date: 21 Sep 1994 13:52:42 -0700
|
|
|
|
Anyone know what the status of the LINUX port for the PowerMac is ?
|
|
I havn't read anything since like a month ago, when I recall seeing
|
|
something about testing starting, or maybe it their schedule *called*
|
|
for testing to begin last month.
|
|
|
|
If there is a mail-list (I tried the channels stuff in .fi with no luck)
|
|
can someone let me know.
|
|
|
|
I am also real curious how those porting LINUX came by the PowerMac
|
|
hardware specs (clearly I am referring to the ASIC specs not 601 CPU
|
|
information)
|
|
|
|
thanks
|
|
|
|
tony
|
|
--
|
|
Tony Jones (tony@sunquest.com)
|
|
UNIX Technical Resource Group
|
|
Sunquest Information Systems
|
|
|
|
------------------------------
|
|
|
|
From: niemidc@clark.net (David C. Niemi)
|
|
Subject: Re: [STATUS] Linus Floppy Driver Development
|
|
Date: 24 Sep 1994 21:52:16 GMT
|
|
Reply-To: niemidc@clark.net
|
|
|
|
In article D07@murdoch.acc.Virginia.EDU, doolitt@recycle.cebaf.gov (Larry Doolittle) writes:
|
|
> David Holland (dholland@husc7.harvard.edu) wrote:
|
|
> : urlichs@smurf.noris.de's message of 13 Sep 1994 12:27:36 +0200 said:
|
|
>
|
|
> : > Generally, I think it's not reasonable to force the user to start some sort
|
|
> : > of floppy recognition program after inserting a disk and before tar-xfv'ing
|
|
> You mean tar -xvf'ing :-) ^^^^^^^
|
|
> : > off /dev/fd0, if the format in question is known to the driver anyway.
|
|
>
|
|
> : I additionally think it's not reasonable to force the user to look up
|
|
> : the filesystem type and issue a mount command before reading from the
|
|
> : disk. Floppies should mount themselves (like on Macs and Amigas) to
|
|
> : the greatest extent possible given the hardware.
|
|
>
|
|
> : This is not bloat, it's an important issue for some people.
|
|
>
|
|
> OK, it's an issue. But it's bloat if it goes in the Kernel.
|
|
> This situation cries out for a Kernel hook, and the ability
|
|
> to have a floppy_mount_daemon that gets activated when the
|
|
> user puts in a floppy (periodic disk-change check?). This
|
|
> program could be a shell script, for all I care, that does
|
|
> some magic with "file" or some other tools, connects with
|
|
> some glossy X-based file manager, whatever. All this is
|
|
> *not* Kernel functionality, although it may need a Kernel
|
|
> patch or two to make it viable.
|
|
>
|
|
> Personally, I would never run such a daemon. I know people
|
|
> who would, though. Any volunteers to write such a beast?
|
|
|
|
I think the FDRAWCMD support in the 1.1.41+ kernels is about
|
|
as much as can be put into the kernel; in other words, I don't
|
|
think modifying the floppy driver will help.
|
|
|
|
The basic problem is that the floppy drive in no way notifies the
|
|
rest of the system when a disk has been inserted. This means that
|
|
the floppy drive must be polled periodically so as to notice when
|
|
a disk appears. This is not impossible, as a test already exists
|
|
to poll the drive when it is in use to detect the disk's removal.
|
|
However, as you suspected above, it could have a small but noticeable
|
|
effect on system performance.
|
|
|
|
I'd guess a poll interval of every 1 to 10 seconds is the range you'd
|
|
want to try.
|
|
==================================================================
|
|
David C. Niemi (SLMA, Herndon, Virginia, USA) niemidc@clark.net
|
|
Know the difference between the color of the wine and the color of
|
|
the glass. (Jalaluddin Rumi)
|
|
==================================================================
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: unal@uwnuc1.physics.wisc.edu (Orhan Unal)
|
|
Subject: Re: "guide" (xviews) for Linux ?
|
|
Date: 21 Sep 1994 21:03:01 GMT
|
|
|
|
In article <35onq8$rq1@harbinger.cc.monash.edu.au> davison@bruce.cs.monash.edu.au (Andrew Davison) writes:
|
|
>Do anyone know of a linux port of the "guide" GUI builder for XView ? I know
|
|
>that Sun versions exist, and am a little concerned that it might be a Sun
|
|
>commercial venture.
|
|
>
|
|
>I'm trying to compile an application which has been written using guide
|
|
>and have hit a wall you might say...
|
|
>
|
|
>Regards,
|
|
> Andy
|
|
|
|
DevGuide is a commercial Sun product and is not available for Linux. But
|
|
if you want to just compile your application and run in Linux, it's no
|
|
problem because some kind sould has ported libguide.a library to Linux,
|
|
which you can use to link your devguide generated code with.
|
|
|
|
Just get /pub/Linux/libs/X/guide-linux.3.0.1.tar.gz from sunsite.unc.edu
|
|
and have fun.
|
|
--
|
|
********************************************************
|
|
* Orhan Unal * Email: unal@uwnuc1.physics.wisc.edu *
|
|
********************************************************
|
|
|
|
------------------------------
|
|
|
|
From: bcr@k9.via.term.none (Bill C. Riemers)
|
|
Crossposted-To: comp.protocols.misc
|
|
Subject: Re: Porting applications to TERM
|
|
Date: 21 Sep 1994 21:05:01 GMT
|
|
Reply-To: bcr@physics.purdue.edu
|
|
|
|
|
|
Robert> : Porting shouldn't be necessary with the new termnet
|
|
Robert> library. Add in : the program Makefile following
|
|
Robert> definitions:
|
|
|
|
Of course there is still a 5% failure rate to this procedure. However,
|
|
I recommend spending your time patching termnet.c to eliminate the
|
|
respective failure, instead of trying to patch a single application
|
|
to run. For example, right now I'm working on patch termnet.c so
|
|
xpilot will work.
|
|
|
|
Robert> : to CFLAGS -include /usr/local/lib/termnet.h (or
|
|
Robert> whereever) : to LIBS -ltermnet -L/usr/local/lib ( ="= )
|
|
|
|
Robert> : That should do it. Note that -include is not understood
|
|
Robert> by some C : compilers (but gcc does grok it :-)
|
|
|
|
Robert> : Ideally, programs compiled in this way run with and
|
|
Robert> without term : and/or TCP/IP, they always take what's
|
|
Robert> available.
|
|
|
|
Robert> I think its amazing! does that mean that also
|
|
Robert> smail/sendmail can be compiled with term within? how can
|
|
Robert> you than receive email if your term pc is not registered
|
|
Robert> with a valid hostname?
|
|
|
|
Yes, but you still aren't going to receive mail directly from
|
|
internet. Smail just lissens to your SMTP port. Since, your mail
|
|
server probably isn't term aware it won't know to connect to your
|
|
local SMTP port when someone addresses a letter for you. However,
|
|
recompiling smail does allow it to work normally for outgoing mail.
|
|
However, it is much simplier just to use a tredir command instead
|
|
of recompiling smail. (Thats why I haven't bothered to upload the
|
|
recompiled smail binary anywhere.)
|
|
|
|
Bill
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: softwork@MCS.COM (Bob Salita)
|
|
Subject: Re: Pointer to cyclades
|
|
Date: 24 Sep 1994 17:13:42 -0500
|
|
|
|
Pete Kruckenberg (kruckenb@sal.cs.utah.edu) wrote:
|
|
: Daniel Gelinas (gelinas@CAM.ORG) wrote:
|
|
|
|
: : I keep on hearing of this Cyclades board. What is it exactly? How well is
|
|
: : it tested under linux, and where can I get one?
|
|
|
|
: : Just curios, I need a 16 port card and will have to go with a bocaboard
|
|
: : if nothing else presents itself.
|
|
|
|
: There's an ad for it in the latest Linux Journal. You can get the
|
|
: source code from sunsite.unc.edu in pub/Linux/kernel/patches, I
|
|
: think. If that's not right, get the ls-lR in pub/Linux and search it
|
|
: for cyclades. The code is there, and I think it will work up to
|
|
: 1.1.12. The developer's name is also in the .lsm, if you have more
|
|
: questions.
|
|
|
|
: Pete.
|
|
|
|
I have evaluated the Cyclades board. It seems to perform as spec'ed on SCO
|
|
and Linux, except Linux driver does not currently support hardware flow
|
|
control.
|
|
|
|
I use an 8 port board, 16 ports is available.
|
|
|
|
Contact Cyclades Corp. at 1-510-770-9727 or cyclades@netcom.com.
|
|
|
|
Bob
|
|
|
|
------------------------------
|
|
|
|
From: "Theodore Ts'o" <tytso@MIT.EDU>
|
|
Subject: Re: Shared Libs: working toward a permanent solution?
|
|
Date: 24 Sep 1994 20:30:47 -0400
|
|
Reply-To: tytso@MIT.EDU
|
|
|
|
From: ericy@cais2.cais.com (Eric Youngdale)
|
|
Date: 22 Sep 1994 11:27:19 GMT
|
|
|
|
The one thing I am not entirely clear about is where the
|
|
performance hit for PIC comes from. Is it due to the fact that we lose a
|
|
register, or is it because the addressing modes that are used to reference
|
|
data through the %ebx register are slower. (or both, for that matter).
|
|
Anyone have any guesses?
|
|
|
|
It's from losing a register. When you are as register-starved on an
|
|
[345]86, losing a register really makes a difference. On the 386 and
|
|
486 at least, there's no additional clock penalty for almost all of the
|
|
complicated effective address calculations. (The one exception is (base
|
|
+ scale * index), and I don't know if GCC will ever generate that. :-)
|
|
|
|
I'd also suspect that the performance hits are much greater on a 386
|
|
than on a 486, and that may account for some of the different numbers
|
|
that are floating around. The 486 has an on-chip cache, which would
|
|
really mitigate the extra memory fetches caused by the reduced register
|
|
set. Also, on the 386 tends to really penelize you a lot more for
|
|
memory accesses. For example:
|
|
|
|
Instruction 386 486
|
|
cycles cycles
|
|
|
|
cmp reg,reg 2 1
|
|
cmp mem,reg 6 2
|
|
|
|
add reg,reg 2 1
|
|
add reg,mem 6 2
|
|
|
|
|
|
One performance metric that would be worth looking at is simply counting
|
|
up the memory accesses a particular function requires, both with and
|
|
without PIC. This isolates out the effects of caches, etc., and is at
|
|
least a figure which won't vary from system to system.
|
|
|
|
Good luck with the ELF work! I hope the performance hit really isn't as
|
|
bad some people make it out to be. (Especially since I still only have
|
|
a 40 MHz 386. :-)
|
|
|
|
- Ted
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.admin
|
|
From: jeffpk@netcom.com (Jeff Kesselman)
|
|
Subject: Re: What user interface to use???
|
|
Date: Sat, 24 Sep 1994 21:50:28 GMT
|
|
|
|
In article <tony.69.000C2DAA@teleport.com>,
|
|
Tony Schwartz <tony@teleport.com> wrote:
|
|
>When do dial into your local ISP using a standard terminal connection, what
|
|
>software is used to providet the menuing, ability to do internet functions
|
|
>like telnet, ftp, gopher, etc???
|
|
|
|
telnet provides telnet.
|
|
ftp provides ftp
|
|
gopher provides gopher
|
|
etc.
|
|
there is no menuing as such, they axre all command-line driven.
|
|
|
|
All these UNIX utilities are designed to be run from the command line.
|
|
The menuing systems you might be familiar with are all front ends that
|
|
call these programs.
|
|
|
|
Oh, and manual pages are veiwed byt typing man.
|
|
(Type 'man man' for an explaination of how to use the online manual.)
|
|
|
|
Welcome to the real world of UNIX.
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: "Theodore Ts'o" <tytso@MIT.EDU>
|
|
Subject: Re: polled ports
|
|
Date: 24 Sep 1994 20:39:39 -0400
|
|
Reply-To: tytso@MIT.EDU
|
|
|
|
From: bde@kralizec.zeta.org.au (Bruce Evans)
|
|
Date: 5 Sep 1994 18:08:52 +1000
|
|
|
|
In article <CvMKs5.3AK@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
|
|
|
|
>It polls 100 times per second, the timer-interrupt rate. So 1200 baud
|
|
>is already slightly too fast for this mode.
|
|
>It could be usable with 16550A chips, but they have other problems when
|
|
>used with a mouse. Therefore they are disabled below 2400.
|
|
|
|
The other problems don't apply if the port is polled. Therefore the
|
|
16550 FIFOs shouldn't be disabled below 2400 if the port is polled.
|
|
|
|
Sorry for the late followup, but I only had a chance to look at this
|
|
now... Actually FIFO's are disabled a speeds below 2400 --- the only
|
|
thing that happens is that the FCR_TRIGGER is set at 1, so that an
|
|
interrupt is signalled after one character is in the FIFO. Of course,
|
|
this makes no difference if you are polling. So the FIFO's are enabled
|
|
even at speeds below 2400 bps, and so getting a 16550A chip if you are
|
|
doing polled operations is highly recommended.
|
|
|
|
- Ted
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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
|
|
******************************
|