Subject: Linux-Development Digest #745
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, 21 May 94 21:13:06 EDT

Linux-Development Digest #745, Volume #1         Sat, 21 May 94 21:13:06 EDT

Contents:
  Re: 32-bit Novell desktop OS combines Unix, (Brandon S. Allbery)
  libc 4.5.26 (Zhuo Er Lin)
  Re: 32-bit Novell desktop OS combines Unix, (Michaela Merz)
  Re: COMMODORE CALLS IT QUITS (Scott T. Traynor)
  Re: Using emx/gcc for OS/2 and Linux (Cave Newt)
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Mark A. Davis)
  Re: Distributions conside (George Mealy)
  PCI or VL bus SCSI Host Adapters (Bill Heiser)
  Re: Anybody working on BSD dump porting? (Matthew Dillon)
  Re: Nfs Buffercache Brok (Russell Coker)
  Re: O_SYNC support (Frank Lofaro)
  Re: Socket bind problems (Jim Harkins)
  Re: net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read (Bradley E. Smith)
  *Q: PAS-16 SCSI interface  (slzw0@cc.usu.edu)

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: 32-bit Novell desktop OS combines Unix,
Date: Sat, 21 May 1994 18:58:12 GMT

In article <rob.152.05AD83B6@eats.com>, rob@eats.com (Rob Newberry) says:
+---------------
| neither we're the Novell jerks at FOSE.  Again, what they said to me was along 
| the lines of "We are Novell.  We are Unix."  My post was simply to say that 
| this attitude, given to me from Novell people, was not "open."
+------------->8

With any luck, what you were talking to was the last of the "old guard" from
USL, which never *did* quite figure out that The Phone Company ("We're AT&T.
We don't care.  We don't have to.") is dead...

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
The FUDs at Microsoft are shouting "Kill The Wabi!"

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

From: umlin000@cc.umanitoba.ca (Zhuo Er Lin)
Subject: libc 4.5.26
Date: 21 May 1994 19:32:33 GMT

I just install libc 4.5.26 from tsx-11. (upgrade from 5.5.21)

I notice that scroll in X-Free 2.11 is slower (noticable difference).
 
-- 
========================================================================
|  Eric Lin                        Voice:   (204) 783-2884             |
|    Computer Engineering      FAX Modem:   (204) 783-2884             |
|    University of Manitoba     Internet:   Umlin000@cc.Umanitoba.CA   |

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

From: misch@misch@elara.fsag.de (Michaela Merz)
Subject: Re: 32-bit Novell desktop OS combines Unix,
Date: Fri, 20 May 1994 17:30:23 GMT
Reply-To: misch@misch@elara.fsag.de

In article 6kd@louie.udel.edu, chavey@bambam.cis.udel.edu (Laurent Chavey) writes:

>>|> we all know that Linus himself says that it would be virtually impossible,
>>|> or at least very difficult, to port the Linux kernel to another processor.
>>
>>That is definitely wrong, because the kernel is currently beeing ported
>>to 680x0 machines (ATARI,AMIGA) and running there and also there are people
>>doing ports to the DEC ALPHA and PowerPC.
>>
>I would also add, that some of the people working at novell are
>not born from the last rain. Some may in fact know very well what they
>are doing, and how one can port the kernel.
>Now, the fact that they used Linux as a base, show that they were not
>interested in the base (usual os stuff), but were more interested in
>adding all the functionality that will make Linux a good competitor
>against NT. Do not forget novell is on our side, TO NOT LET 
>MICROSOFT NAD BILL GATE OWN THE COMPUTER WORLD. Lets all fight to
>not have another giant dictate the computer future.


Oh no! You're fighting fire with fire. Don't forget, Novell is allready
the number two in business. And they are very aggressive in the marketing
strategy. MIC*SOFT is of course a target. But we're NOT on the same side 
with Novell. Novell is not a bit better. 

Michaela

---
The                                           
Free Software                                      (Phone) ++49-69-6312083
Association of Germany, FSAG                             We have a target!



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

From: traynost@logic.camp.clarkson.edu (Scott T. Traynor)
Subject: Re: COMMODORE CALLS IT QUITS
Date: Sat, 21 May 1994 20:19:23 GMT

Kevin Burtch X8534 Ppppp (kburtch@pts.mot.com) wrote:


: I doubt that. The reason there were no Mac clones, is that Apple
                                         ^^^^^^^^^^
Who needs clones when an ST/TT/Falcon or Amiga or can emulate it at the
same speed? BAH!
Scott "I am sick of mac Zealots!" Traynor
So i make Spelling mistakes Sue Me :)




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

Crossposted-To: comp.os.os2.programmer.porting
From: roe2@ellis.uchicago.edu (Cave Newt)
Subject: Re: Using emx/gcc for OS/2 and Linux
Reply-To: roe2@midway.uchicago.edu
Date: Sat, 21 May 1994 21:29:00 GMT

coates@physics.uq.zo.au writes:

>       What would be really interesting, if it were possible, would
>be files which were dynamically linked to equivalent shared/DLL
>libraries under Linux and OS/2 such that the same executable file
>would run under either Linux or OS/2, simply choosing the correct
>shareable/dynamic library for the correct operating system.  For
>anyone running both systems on the one machine, this would be a great
>way to save space, I suspect, having all tools on a common drive
>readable by both.

Ooo, I'd really love that, but I suspect it isn't (currently) possible.
I don't know anything about the Linux executable format, but OS/2's 
begins with a DOS stub (the old "MZ" thing), and I doubt that Linux 
understands that outside of dosemu.  Of course, there's no reason why 
Linux couldn't be *made* to understand it, but I assume we're talking
about a kernel hack at this point (or would it be a shell hack?).  I
wonder if Linus would be receptive (always assuming that there are no
problems with required static library routines)...

Note that I've cross-posted to c.o.l.d; redirect follow-ups if necessary.

Greg Roelofs

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

From: mark@taylor.wyvern.com (Mark A. Davis)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Date: Fri, 20 May 1994 02:25:57 GMT

tgm@netcom.com (Thomas G. McWilliams) writes:

>: Think about the possibilities. Linux, DOS and Windows all on the same
>: desktop, in their own windows. Ill be waiting over here in front of
>: the window marked "Corsair, coming soon".

>It is interesting to note that Novell now owns WorkPerfect.
>Would Novell make their WordPerfect available for their Linux?
>Novell's WordPerfect for Linux?

Possibly.  But it might be possible right now using the SCO binaries....
-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

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

Subject: Re: Distributions conside
From: george.mealy@channel1.com (George Mealy)
Date: Thu, 19 May 94 21:18:00 -0400


AT>   Message-ID: <Cq0E2t.1Jq@cs690-3.erie.ge.com>
.   Newsgroups: comp.os.linux.development
.   Organization: GE Transportation Systems, Control Engineering
.   
.   In article 2458@kf8nh.wariat.org, bsa@kf8nh.wariat.org (Brandon S. A
.   writes:
.   >In article <2rbcg5$pj1@news.tamu.edu>, drs0587@net.tamu.edu says:
.   >+---------------
.   >| On a Sun there is no operating system distribution competition, a
.   >| as a result, you see almost no movement toward including signific
.   >| features/tools that we have come to expect in any decent linux 
.   >| distribution. Why does Solaris still not have emacs, mosaic, arch
.   >| ftptool, mtools, perl, tcl/tk, gnu tar, tn3270, gzip, and patch,
.   >+------------->8
.   >
.   >Your argument here falls flat with one counter-question:  Why doesn
.   >provide emacs, Mosaic, archie, ftptool, mtools, perl, tcl/tk, ...? 
.   all,
.   
.   Gee, the reason nobody includes this stuff is probably because they 
.   willing to support it without ownership of the code, and the authors
.   about to give that away (or sell it).
.   
.   ---
.   
.   Andy Tefft               - new, expanded .sig -     teffta@cs690-3.e
.   
Gee, I didn't know you cared:-)

     ............................................
      george.mealy@channel1.com,  05/19/94  15:43

---
~ CMPQwk #1.4~ UNREGISTERED EVALUATION COPY

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

Crossposted-To: comp.os.linux.misc
From: heiser@world.std.com (Bill Heiser)
Subject: PCI or VL bus SCSI Host Adapters
Date: Sat, 21 May 1994 22:15:23 GMT

Neither the hardware FAQ nor the kernel config stuff mentions
anything about support in LINUX for VL or PCI bus disk controllers.
I'm particularly concerned about ADAPTEC support.

Are there any plans to support these so we can use the
faster busses for SCSI support?

Bill

-- 
 Bill Heiser   heiser@world.std.com


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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Crossposted-To: comp.os.linux.help
Subject: Re: Anybody working on BSD dump porting?
Date: 19 May 1994 18:17:11 -0700

In article <2reh76$hfv@bosnia.pop.psu.edu> barr@pop.psu.edu (David Barr) writes:
:In article <1994May18.210039.6822@belvedere.sbay.org>,
:David E. Fox <root@belvedere.sbay.org> wrote:
:>But what advantages does 'dump' have that 'tar' or 'cpio' do not?
:
:1. Does multiple dump levels

    so does gnu tar (script enclosed).

:2. Handles sparse files (and handles them correctly)

    gnu tar does this to a degree (it can detect that a file
    has holes, but cannot reproduce the holes on restore
    in exactly the same manner as they were created)... of
    course, read() doesn't care.  However, I have noticed that
    when I compile gnutar for linux, there appears to problems
    with sparse file recognition.

:3. Handles hard links (and handles them completely)

    What do you mean by completely?  tar handles hard links,
    but I may be missing something here.

:4. Does not affect atimes of backed up files

    True.  This is not important for most people.

:5. Supports multiple tape volumes (ok, so does GNU tar)

    grin.

:6. No pathname length/filename restrictions

    neither with gnu tar, though it's decidedly a hack. (gnu tar
    renames the too-long entries and appends special records to name them
    back at the end, or something like that.  Messy, but it works)

:7. Backs up devices/named pipes, etc.

    tar backs up fifo's just fine, device nodes just fine.  Ok, it doesn't
    backup stale unix domain sockets, but considering the files are
    useless in of themselves, it doesn't matter.

:
:--Dave


    Basically, unless you care about the fact that st_atime is hit,
    the only real advantage [r]dump has is that it generally goes much
    faster then tar because it sorts files to reduce the amount of
    seeking required.  

    [r]dump has many disadvantages:

    * you are at the mercy of the [r]dump program when part of the backup
      is corrupted.

    * dumps are not portable across architectures or filesystems.

                                        -Matt

Here are the scripts I use to backup my system (around 2GB of disk) onto
an DAT drive.  It doesn't do multi-volume stuff for obvious reasons (one
DAT easily holds everything), but it does do multi-level dumps.  The
level information is stored on the tape itself, which I think is way cool.

In anycase, the script uses the 'mt' program heavily and assumes a seekable
tape device as well as one that allows you to set the blocking factor.  Use
at your own risk, and don't email me questions please!  Think of it as an
educational oportunity :-)

===========================================================

#!/bin/tcsh -f
#
# gdump <level>

cd /etc/backup

set level = $argv[1]
set device = /dev/nrmt0
set files = "/ /var /a /b /c"
#set files = /tmp/misc

# Locate previous level on tape
#

mt -f $device rewind
mt -f $device status
mt -f $device setblk 16384
set n = 0
while ( $n < $level )
    rm -f level-$n
    mt -f $device fsf
    dd if=$device bs=16384 | tar --ignore-zeros -b 32 -xvf - level-$n
    if ( ! -f level-$n ) then
        echo "Failed to read level-$n from tape"
        exit 2
    else
        echo "Read level-$n from tape"
    endif
    @ n = $n + 1
end

@ prev = $level - 1

if ( $prev == -1 ) then
    rm -f temp.level-$level
else
    cp -a level-$prev temp.level-$level
endif

tar -c --one-file-system --block-size=32 --sparse -v -f - --listed=temp.level-$level --totals $files | dd of=$device bs=16384
set rc = $status
if ( $rc <= 3 ) then
    mt -f $device tell
    mv -f temp.level-$level level-$level
    tar -c --block-size=32 -v -f - level-$level | dd of=$device bs=16384
    set rc = $status
    mt -f $device weof 2
    mt -f $device tell
endif
if ( $rc > 3 ) then
    echo "tar failed, error code $rc"
endif

rm -f temp.level-$level

mt -f $device rewoffl

===========================================================

#!/bin/tcsh -f
#
# glist [level]

cd /etc/backup

set device = /dev/nrmt0

if ( $argv != "" ) then
    set level = $argv[1]
else
    set level = -1
endif

# List level or all levels
#

mt -f $device rewind
mt -f $device status
mt -f $device setblk 16384
rm -f level-*
set n = 0
while ( 1 )
    echo "LISTING LEVEL $n"
    if ( $level < 0 || $n == $level ) then
        dd if=$device bs=16384 | tar --ignore-zeros -b 32 -tvf -
    else
        mt -f $device fsf
    endif
    dd if=$device bs=16384 | tar --ignore-zeros -b 32 -xvf - level-$n
    if ( ! -f level-$n ) then
        echo "failed read level-$n from tape"
        exit 0
    endif
    if ( $n == $level) then
        break
    endif
    @ n = $n + 1
end

-- 

    Matthew Dillon              dillon@apollo.west.oic.com
    1005 Apollo Way             ham: KC6LVW (no mail drop)
    Incline Village, NV. 89451  Obvious Implementations Corporation
    USA                         Sandel-Avery Engineering
    [always include a portion of the original email in any response!]


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

From: Russell.Coker@f363.n633.z3.fidonet.org (Russell Coker)
Date: 18 May 94 13:53:00 +1000
Subject: Re: Nfs Buffercache Brok

acg>Isn't the Andrew File System (AFS) supposed to yield better
acg>performance than NFS?  Several supercomputing centers use AFS
acg>servers for mounting filesystems onto Crays & the like...

   AFS will give much better performance for WANs, at the cost of
reliability.  If the data is changed often/at all then there are huge
consistency problems.  Probably the best (only?) use of AFS is for
mounting home directories, that way as long as a user is only logged
in at one machine it will be usable.  What AFS does to give good
performance is to copy the entire file accross the network, let the
local system work on it, and then copy it all back again.  This is
obviously useless for database work....

acg>What is the legal status of AFS?  Could a port to Linux be done

   As far as the legal status goes, if a port to Linux can't be done
then you could always write your own network filing system that had
the same features.  The design of AFS is widely published....

  However for a LAN situation I really don't think that AFS is a good
thing as it causes more consistancy problems, requires large amounts
of local drive space for buffering, and the Venus module would waste
kernel memory...


  cya


  PS  I don't want to put you off developing this, but I beleive that
there are many better ways of designing network systems for MOST
applications (AFS is the best design for it's original usage at CMU).
___
 X MR/2 1.63x NR X unable to open trouser.zip - (A)bort or (W)arm boot

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

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: O_SYNC support
Date: Thu, 19 May 94 21:09:17 GMT

In article <2rf053$b9p@progress.progress.com> orr@progress.COM (James Orr) writes:
>I done some looking through the latest source I could find, and
>it appears that the O_SYNC flag to the open() call is still not
>supported. Therefore, my question is -- is this correct?, and if
>so, is anyone working on adding this support. I need this support
>to gaurantee file integrity, and if it is not available, I will 
>proceed with fsync, but before I do this, I just wanted to be
>sure.
>
>Thanks,
>
>-Jim Orr
>orr@progress.com
>--
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>James Orr - QA Developer             | Progress Software Corporation
>orr@bedford.progress.com             | 14 Oak Park
>(617) 280-4635                       | Bedford, Mass. 01730

Yeah, it still is not officially supported. I have hacked up
something, but I'd advise checking it out before you trust it.
(I just noticed, I forgot a small cosmetic fix to fs/ioctl.c, which
would remove the comment saying it is not implemented).

Here it is:

diff -r -u -N linux.unhacked/fs/open.c linux/fs/open.c
--- linux.unhacked/fs/open.c    Fri Apr 29 19:54:14 1994
+++ linux/fs/open.c     Sun May  1 00:18:50 1994
@@ -95,6 +95,7 @@
 {
        struct inode * inode;
        struct file * file;
+       int retval;
 
        if (fd >= NR_OPEN || !(file = current->filp[fd]))
                return -EBADF;
@@ -107,7 +108,13 @@
                inode->i_op->truncate(inode);
        inode->i_ctime = inode->i_mtime = CURRENT_TIME;
        inode->i_dirt = 1;
-       return notify_change(NOTIFY_SIZE, inode);
+       retval = notify_change(NOTIFY_SIZE, inode);
+        if (retval < 0)
+                return retval;
+        if (file->f_flags & O_SYNC)
+                return file->f_op->fsync(inode, file);
+        else
+                return retval;
 }
 
 /* If times==NULL, set access and modification to current time,
diff -r -u -N linux.unhacked/fs/read_write.c linux/fs/read_write.c
--- linux.unhacked/fs/read_write.c      Wed Dec  1 04:44:15 1993
+++ linux/fs/read_write.c       Sun May  1 00:18:50 1994
@@ -7,6 +7,7 @@
 #include <linux/types.h>
 #include <linux/errno.h>
 #include <linux/stat.h>
+#include <linux/fcntl.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
 
@@ -89,7 +90,7 @@
 
 asmlinkage int sys_write(unsigned int fd,char * buf,unsigned int count)
 {
-       int error;
+       int retval;
        struct file * file;
        struct inode * inode;
        
@@ -101,8 +102,14 @@
                return -EINVAL;
        if (!count)
                return 0;
-       error = verify_area(VERIFY_READ,buf,count);
-       if (error)
-               return error;
-       return file->f_op->write(inode,file,buf,count);
+       retval = verify_area(VERIFY_READ,buf,count);
+       if (retval)
+               return retval;
+       retval = file->f_op->write(inode,file,buf,count);
+       if (retval < 0)
+               return retval;
+       if (file->f_flags & O_SYNC)
+               return file->f_op->fsync(inode, file);
+       else
+               return retval;
 }
diff -r -u -N linux.unhacked/include/linux/fcntl.h linux/include/linux/fcntl.h
--- linux.unhacked/include/linux/fcntl.h        Fri Apr 29 19:54:15 1994
+++ linux/include/linux/fcntl.h Sun May  1 00:18:50 1994
@@ -1,7 +1,7 @@
 #ifndef _LINUX_FCNTL_H
 #define _LINUX_FCNTL_H
 
-/* open/fcntl - O_SYNC isn't implemented yet */
+/* open/fcntl */
 #define O_ACCMODE        0003
 #define O_RDONLY           00
 #define O_WRONLY           01




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

From: jharkins@netcom.com (Jim Harkins)
Subject: Re: Socket bind problems
Date: Fri, 20 May 1994 02:31:42 GMT

In article <jharkinsCq2G0n.5r8@netcom.com>, I wrote
>I'm running Linux 0.99 pl 13.  I'm writing a client-server app and seem to
>have hit a wall.  The server listens to a socket and, when something is
>received, forks a child to handle the request.  My problem is that when
>the child dies the parent seems to die as well.  The parent has stuff like

I'm following up my own article because canceling questions like this
result in my still getting responses.  After posting this I started
looking at the child, it turned out I was passing FD_CLR *foo instead
of foo.  As the code did an exit() right after the FD_CLR it looked
like the child exited at the right place.  

I inherited this code and it's a real learning experience  figuring out
problems like this.  I think my office mate learned a couple new words
this morning :-)  I'd turned on -Wall to gcc but was intimitaded by the
number of warnings so I turned it back off.  I suspect -Wall was giving
me the answer though.

Still don't know why I can't get lpd to run.

jim

-- 
"I want to die peacefully in my sleep like my grandfather.  Not screaming
in terror like his passengers."

Jim Harkins                          jharkins@netcom.com 
San Diego, CA.


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

From: brad@bradley.bradley.edu (Bradley E. Smith)
Subject: Re: net3 tcp window sizes (NOT SEQUENCE NUMBERS!), Please read
Date: 20 May 1994 11:54:26 -0500

Well I reduced the values to 128 & 64 and haven't had a hang yet.....
-- 
Bradley Smith                    brad@bradley.edu ---  309-677-2337
Network & Technical Services @ Bradley University, Peoria, IL

"It's amazing how much scrap metal you get from 4 cans of beer"

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

From: slzw0@cc.usu.edu
Subject: *Q: PAS-16 SCSI interface 
Date: 21 May 94 16:53:41 MDT

I have ProAudio Spectrum 16 with AHA-2842VL Controller.  As
far as I know, Linux does not support AHA-2842VL, I am trying
to use ProAudio Spectrum 16 SCSI interface for my SCSI HD and
SCSI CD-Rom dirve. However, the stackware boot up disk stoped
at partition recognition phrase although it recognized all of
SCSI devices.  Certainly, no SCSI device was detected if I
switch back to the AHA-2842VL controller but it still detect
my IDE HD partitions.  Is it matter if I just keep AHA on
board?  Are there anyone who can give me a tip?

Any advice will be appreciated!
Thanks

Park


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


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