Subject: Linux-Development Digest #222
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 24 Sep 94 21:13:12 EDT

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: [email-masked] (Joerg Schneider)
Subject: Re: TAR or Streamer problem!
Date: 24 Sep 1994 20:58:24 GMT

[email-masked] 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: [email-masked] -- 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: [email-masked]

Larry Doolittle ([email-masked]) 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: [email-masked]

 As Andries Brouwer ([email-masked]) 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: [email-masked] (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 <[email-masked]>
To: [email-masked]

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  <[email-masked]>               UW phone: (206) 685-8068
Dept. of Applied Math, FS-20    University of Washington    Seattle, WA  98195
==============================================================================

------------------------------

From: [email-masked] (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                                [email-masked]
Picture a clever one-liner here...

------------------------------

From: [email-masked] (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 ([email-masked])
UNIX Technical Resource Group
Sunquest Information Systems

------------------------------

From: [email-masked] (David C. Niemi)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: 24 Sep 1994 21:52:16 GMT
Reply-To: [email-masked]

In article [email-masked], [email-masked] (Larry Doolittle) writes:
> David Holland ([email-masked]) wrote:
> : [email-masked]'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)    [email-masked]
Know the difference between the color of the wine and the color of
the glass.  (Jalaluddin Rumi)
==================================================================

------------------------------

From: [email-masked] (Orhan Unal)
Subject: Re: "guide" (xviews) for Linux ?
Date: 21 Sep 1994 21:03:01 GMT

In article <[email-masked]> [email-masked] (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: [email-masked]  *
********************************************************

------------------------------

From: [email-masked] (Bill C. Riemers)
Crossposted-To: comp.protocols.misc
Subject: Re: Porting applications to TERM
Date: 21 Sep 1994 21:05:01 GMT
Reply-To: [email-masked]

    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: [email-masked] (Bob Salita)
Subject: Re: Pointer to cyclades
Date: 24 Sep 1994 17:13:42 -0500

Pete Kruckenberg ([email-masked]) wrote:
: Daniel Gelinas ([email-masked]) 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 [email-masked].

Bob

------------------------------

From: "Theodore Ts'o" <[email-masked]>
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 24 Sep 1994 20:30:47 -0400
Reply-To: [email-masked]

   From: [email-masked] (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: [email-masked] (Jeff Kesselman)
Subject: Re: What user interface to use???
Date: Sat, 24 Sep 1994 21:50:28 GMT

In article <[email-masked]>,
Tony Schwartz <[email-masked]> 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" <[email-masked]>
Subject: Re: polled ports
Date: 24 Sep 1994 20:39:39 -0400
Reply-To: [email-masked]

   From: [email-masked] (Bruce Evans)
   Date: 5 Sep 1994 18:08:52 +1000

   In article <[email-masked]>, Rob Janssen <[email-masked]> 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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
******************************