Subject: Linux-Development Digest #417
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:     Fri, 28 Jan 94 17:13:07 EST

Linux-Development Digest #417, Volume #1         Fri, 28 Jan 94 17:13:07 EST

Contents:
  Re: Winders NT on MC68K? (Jerry Shekhel)
  Re: kmalloc for more then 4096 Bytes ? (David C. Niemi)
  Re: Winders NT on MC68K? (Alan Cox)
  Second and 3-rd VLB Video cards for Non-Workspace use? (Izumi Ohzawa)
  Re: nfs performance (Donald J. Becker)
  Re: Non-blocking I/O (Lawrence Foard)
  ftape: How reliable is it? (grantma@ritz.equinox.gen.nz)
  Re: Winders NT on MC68K? (Jerry Shekhel)
  Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?) (David Simmons)
  Re: Which is better? 680x0 or 80x86? (Donald J. Becker)

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

From: jerry@msi.com (Jerry Shekhel)
Subject: Re: Winders NT on MC68K?
Date: 27 Jan 1994 21:34:45 GMT

David C. Niemi (niemidc@YP.lab) wrote:
: >
: >It is *more* portable than the lot of operating systems we call "UNIX",
: >since it's designed to be 100% source compatible across all supported
: >architectures.  The portability problem is the thing that NT solves for
: >developers.
:
: Yeah, like forcing everyone to live in Florida is a solution to snow and
: ice.  I prefer making my own choices, thank you.
:

Where the heck is *this* coming from?  Does MS somehow prevent hardware
vendors from continuing to sell UNIX?  Of course not.  NT doesn't *limit*
your choices, it gives you a new choice.  In the past, there was UNIX --
runs on everything, but apps need to be ported from one platform to the next.
Now there's also NT -- runs on fewer platforms, but is 100% software
compatible across those platforms.

:
: As to the validity of the issue, I sincerely doubt NT makes APPLICATIONS
: any more portable than any other vendor's OS that is on multiple hardware
: platforms (e.g. Solaris, AIX, OSF/1, SunOS 4, NextStep, and even VMS).
:

It probably doesn't, because the idea behind Solaris and NeXTSTEP is the
same, but NT is the first that seems capable of getting the software vendors'
attention.

:
: It is quite unfair to claim that NT is more compatible than all versions UN*X
: from a dozen different vendors, when it is only because it is implemented
: by just one vendor that it is consistent.
:

Unfair?  I look at things from the developer's point of view.  I like being
able to cover three platforms for the porting price of one.  No UNIX lets
me do that.

:
: NT is broken because the OS itself is not designed to work on big-endian
: processors.  This has NOTHING to do with applications.
:
: >Excuse me, but MS is being accused of writing unportable code.  It's up to
: >you to cite your sources, in order to make your accusation stick.
:
: I already gave my source.  Microsoft says ITSELF that their code was not
: designed to work on big-endian processors.  They admit it.  What more do
: you want?  This application binary data red herring you threw out there is
: not Microsoft's excuse; it is your excuse on their behalf.
:

Where?  Where did MS say that NT could not work on big-endian processors?
Please cite a real reference!  You know, I've been developing software for
many years, and I can't even conceive of a way to write software so that
it depends on one endian-ness or another.  Can you tell me exactly what it
is about NT that makes it so dependent on little-endian-ness?

:
: The reason it is more work to write portable UN*X applications is because of
: needing to run on many different vendors' versions of UN*X on many hardware
: platforms.  Surely you know this.
:

Surely I do.  So?  Knowing this is hardly a comfort when I have an app to
develop.

:
: Obviously Microsoft has a single API for
: NT because NT only just came out and is from a single vendor.  Give NT a
: couple of more releases, and you'll have plenty of #ifdef statements.
:

What?!  Where are you getting the basis for this prediction?  Portability
glitches are precisely the thing NT is designed to avoid!  Do you predict
the same for NeXTSTEP and Solaris, then?

:
: Better yet, try to support NT, Win3.1, Chicago, OS/2, and DOS with the
: same code base,
:

What for?  Win32 is the API I'd use.  That way, my app would work on NT,
Chicago, Win 3.1 (with Win32s), and NT on other hardware platforms.

:
: and tell me if you still think Microsoft makes it easy for developers with
: their "single API".
:

They make it easier than trying to develop for the 50 or 60 UNIX API's that
are out there.

Your cheap shot is totally uncalled for.  NT and Chicago have the same API,
and programs written to that API will run on Win 3.1 (with Win32s).  OS/2
isn't even a Microsoft product, so bashing it doesn't help you bash MS.

: >
: >However,
: >I also work in the real world, where the numerous incompatibilities between
: >binary files, UNIX versions, X servers, X toolkits, virtual toolkits, etc.,
: >are real problems.
:
: Yeah, tell me about it.  Keeps us employed.  But don't call it impossible or
: even unworkable, because it ain't, not even between completely unrelated
: implementations of UN*X from vendors that hate each others' guts.
:

Nothing is impossible.  Hell, maybe someday the UNIX world will agree on a
single API.

: David C. Niemi  David.Niemi@oasis.gtegsc.com
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL  | Molecular Simulations Inc. | Cowboy Junkies, Phish,    |
| Drummers do it... |     Burlington, MA USA     | Tribe, Guns N' Roses,     |
|    ... In rhythm! |        jerry@msi.com       | TAMA, Zildjian, Linux...  |
+-------------------+----------------------------+---------------------------+

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

From: niemidc@YP.lab (David C. Niemi)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: 27 Jan 1994 19:09:06 GMT
Reply-To: niemidc@oasis


It seems more and more to me that we need a general-purpose real-memory
contiguous block allocation routine.  I wrote one a while back with the
intent of providing DMA buffers for the floppy, ftape, and sound drivers.
Later, it seemed that they could be useful for SCSI too, with a little
work to make them interruptible.  Now it appears that similar memory
allocation routines are also needed for networking as well.

Is it just my imagination, or do we truly need a general routine to handle
all of this stuff?  It seems we do.  Perhaps after 1.0 Linus can take a
look at this.

To summarize what my routines did:
-       New files: mm/dma_mem.c; include/linux/dma_mem.h

-       Routines: dma_mem_alloc(size,flags); flags include whether the
        memory must be below 1 MB, below 16 MB, or no restriction; and
        whether or not the memory must fit within a 64KB or 128KB segment.

        dma_mem_free(): returns previously allocated memory to the DMA
        memory pool.  Incorporates the freed chunk into other chunks it
        is contiguous with.

        dma_mem_reserve(): used at initialization time to ensure that more
        memory is kept available for future allocation, but does not actually
        allocate it.

-       config.in entries for initial and permanent DMA memory pools.

What it looks like is that Linux should have routines to allocate chunks of
physical memory similar to dma_mem_*, but the name should be more general and
they need to be interruptible (which can be done fairly easily to my code, but
hasn't yet).  Any thoughts?
---
David C. Niemi  David.Niemi@oasis.gtegsc.com
======================================================
Now I must sit here and ponder the yonder
Herbivores ate well 'cause their food didn't never run



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

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: Winders NT on MC68K?
Date: Fri, 28 Jan 1994 13:52:07 GMT

In article <2ia9c7$s92@harbinger.cc.monash.edu.au> kevinl@bruce.cs.monash.edu.au (Kevin Lentin) writes:
>> Nothing is impossible.  Hell, maybe someday the UNIX world will agree on a
>> single API.
>
>It's quite close already. I have developped products under UN*X that were
>designed to be portable but we didn't concentrate much on that aspect at
>the time. At least one of these now runs on about a dozen platforms (mostly
>UN*X but OS/2 as well) with a minimal (very minimal) amount of porting
>effort. The same program would easily be able to be compiled on other UN*X
>variants with almost 0 effort. With WIN32 your options are far more
>limited.
>

Well POSIX already covers many sections of Unix, IBCS2 covers a lot of binary
ground, there is SVID and the ANSI C standard. It's a none issue anyway a
Unix port takes a day or two and a full regression test either for Unix or
for NT will take a week. Then there is alpha testing of each version,
beta testing of each version, compatibility testing, end user comment -
At least I assume you do these sort of things like any responsible company
would. 
Oh and you njeed to test each version. I've already seen an NT program that
didnt work on the Alpha - a programming error and some lucky timing assumptions
and the alpha was just too fast......

As a footnote: I realsed a multiuser game a while ago. It runs on SVR4, Linux,
Modern BSD systems, and several others. It isn't full of #ifdef xxx-unix. In
fact the only big #ifdefs are for the AMIGA running amigados. How ? - I used
the standards, I used ansi C, I used the ansi C library routines.

Alan
iiitac@pyr.swan.ac.uk

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

From: izumi@pinoko.berkeley.edu (Izumi Ohzawa)
Crossposted-To: comp.sys.next.hardware,comp.sys.ibm.pc.hardware.video
Subject: Second and 3-rd VLB Video cards for Non-Workspace use?
Date: 27 Jan 1994 03:22:43 GMT
Reply-To: izumi@pinoko.berkeley.edu

I would like to add 2-nd and possiblely 3-rd VLB video cards with
fast direct access of VRAM from the PC's CPU (like Wingine) under
NEXTSTEP or Linux.

However, I do NOT want these additional video boards to become part
of Workspace served by the WindowServer (or X server).  I would
like to access them outside of the WindowServer/DPS as custom
devices.  There will not be any GUI stuff on them, i.e., no
windows there.

Do any of video cards allow multiple instances on a single machine,
i.e., I/O addresses, BIOS and VRAM ranges configurable to
non-overlapping areas?

I know that some of the high-end cards that use TMS340 series
processors can be used this way, but their VRAM typically is not
accessible directly from the bus (not fast enough anyway).  I am
looking for NON-accelerated video boards with VRAM mapped directly
into CPU's address space.

Any suggestions appreciated.

--
Izumi Ohzawa             [ $@Bg_78^=;(J ]
USMail: University of California, 360 Minor Hall, Berkeley, CA 94720
Telephone: (510) 642-6440     Fax:  (510) 642-3323
Internet: izumi@pinoko.berkeley.edu (NeXTMail OK)

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

From: becker@super.org (Donald J. Becker)
Subject: Re: nfs performance
Date: Wed, 26 Jan 1994 17:14:59 GMT

In article <2ho9m7$b4g@smurf.noris.de>,
Matthias Urlichs <urlichs@smurf.noris.de> wrote:
>In comp.os.linux.development, article <2gmqcm$53f@trondviggo.nvg.unit.no>,
>  venaas@trondviggo.nvg.unit.no (Stig Venaas) writes:
>> 
>> In Ultrix one has daemons (biod) that help the nfs daemons by doing
>> read-ahead and write-behind buffering. One can also run multiple nfs daemons
>> at the same time. Is that possible with Linux?
>> 
>Running multiple daemons should be possible. You can't start more than one, 
>but inserting a few fork() calls in nfsd should work.

Just running multiple copies of 'nfsd' wouldn't be a performance win in most
situations.  Something that might speed up the Linux NFS server is making it
multithreaded within a single address space, or having several processes
share the database.

NFS is mostly stateless, but the typical NFS traffic is very predictable.
The Linux NFS server caches various pieces of information.  Having multiple
independent copies running would defeat this caching.

BTW, the core of the Linux NFS server is the 'hnfsd' server, which I wrote
while I was at Harris-ATD.  It was a rewrite of a simple read-only server
written by Mark Shand.  Rick Sladkey wrote a better configuration file
parser and added a few other features to make the current Linux version.
(I mention this because the copyright notices seem to be missing in some
current Linux distributions.)

>Linux doesn't have a biod yet. As usual, it's just that nobody with the 
>required experience has yet needed the added performance badly enough to 
>write the necessary kernel code. ;-)

Both 'biod' and an in-kernel NFS server are implementation details specific
to Sun's code.  Most commercial NFS implementations do it that way because
they *license* Sun's implementation, not because it's the only (or best) way
to do it.  (Compare the user-level Linux NFS server that allows cleanly
adding features such as pseudo file systems, to the grungy in-kernel hack
that Sun is stuck with for historical reasons.)


-- 

Donald Becker                                          becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715                        301-805-7482

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

Crossposted-To: comp.os.linux,comp.os.linux.help,comp.os.linux.misc
From: entropy@world.std.com (Lawrence Foard)
Subject: Re: Non-blocking I/O
Date: Fri, 28 Jan 1994 19:11:35 GMT

In article <1994Jan28.020542.22309@umr.edu> quandt@cs.umr.edu (Brian Quandt) writes:
>Does Linux have support for non-blocking i/o routines?
>
>Also, what is the largest amount of virtual memory that can be supported
>under Linux? 
>
>Here's what I'm trying to do:
>       Create a real-time buffer that is very large.  I'd like to 
>       do this as a piped process.
>
>       p1 | p2 | p3
>
>       where
>
>       p1 is a the process running in real time generating or sayu around
>       1.5MB/sec
>
>       p2 just reads data from p1 and trys to send it out to p3, if it
>       can't (non-blocking writes) it just allocates memory and
>       keeps it there until it can then write out to p3.  And since
>       Linux supports Vitural memory ... I can effectively create
>       a real time cache that is as large as my virtual space (disk drive).
>
>       p3 is just some process that does not run in real time.  Note that
>       this assumes that p1 dies before we run out of VM.

Yes. The select call can be used for this, it will tell you when its ok
to write. You can also just keep trying to write after doing:

fcntl(fd,F_SETFD,O_NONBLOCK) 

to a file descripter.

-- 
====== Call the skeptic hotline 1=900=555=5555 talk to your own personal . 
\    / skeptic 24 hours/day.     Just say no to victimless crimes.      . .
 \  / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day.  . . .
  \/ The true theory of everything will run on a finite turing machine. . . .

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

From: grantma@ritz.equinox.gen.nz
Subject: ftape: How reliable is it?
Date: Fri, 28 Jan 1994 05:45:01 GMT

I know this might not exactly be the right group for this question, but I
would like to hear some feedback from the ftape developers, and their
experience with the current ftape device driver and its reliability.

I am currently writing up my thesis using my Linux system.  I am just
wondering how dependable the ftape driver is for doing backups and restores.  
The worst thing I want is for my customized Linux setup (it took four
months!) to go down the gurgler.  It would take at least a month to get
everything I have up and running reliably again.  (My system is a much
altered and modified SLS 1.03 which has loads of add-ons and is setup just
right for me.  It is now a Linux user's dream!)

I am looking at buying a Summit SE 250 for the back up device as it comes
with a 2 year warranty and is more solidly built than Conner and CMS tape
drives.  The other thing is that it looks like ftape will evolve and get
more and more solid.

Could you please e-mail me your experiences, and I will collate and
summarize them.

Thank yo uvery much,

Matthew.


PS: Cripple your computer -- run Multiple Schlerosis (MS) DOS.
-- 
    _/  _/   __/   _/_/_/ _/_/_/ _/  _/  _/_/  _/  _/     Matthew A. Grant
   _/_/_/  _/  _/   _/     _/   _/_ _/  _/_   _/  _/    1 Domain Tce, Chch. NZ.
  _/  _/  _/_/_/   _/     _/   _/_/_/  _/    _/_/_/   (03) 338-4287
 _/  _/  _/  _/   _/     _/   _/  _/  _/_/  _/  _/  grantma@ritz.equinox.gen.nz      

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

From: jerry@msi.com (Jerry Shekhel)
Subject: Re: Winders NT on MC68K?
Date: 28 Jan 1994 18:49:36 GMT

Miguel de Icaza (miguel@roxanne.nuclecu.unam.mx) wrote:
: > 
: > All these UNIX systems you're talking about are not 100% source code
: > compatible.  You're confusing "being portable" with "having been ported".
:
: Berkeley Unix is compatible with Berkeley Unix, SV3 with SV3, and so
: on. 
:

No.  SCO Unix and IRIX are both based on SVR3, and they're *very*
incompatible.

: >
: > Sure, there are versions of UNIX available for lots of different platforms,
: > but writing a portable UNIX application is a nightmare!  NT promises to
: > solve that problem by being 100% portable across all architectures, and if
: > that means that one of the endian-nesses has to die, well, IMHO let it die.
:
: They said the same when they delivered OS/2 1.5...
:

No.  OS/2 has always been an Intel-only system.

: Miguel.
--
+-------------------+----------------------------+---------------------------+
| JERRY J. SHEKHEL  | Molecular Simulations Inc. | Cowboy Junkies, Phish,    |
| Drummers do it... |     Burlington, MA USA     | Tribe, Guns N' Roses,     |
|    ... In rhythm! |        jerry@msi.com       | TAMA, Zildjian, Linux...  |
+-------------------+----------------------------+---------------------------+

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

From: simmons@EE.MsState.Edu (David Simmons)
Subject: Re: Winders NT on MC68K?  (was Re: Which is better? 680x0 or 80x86?)
Date: 28 Jan 1994 06:41:08 GMT
Reply-To: simmons@EE.MsState.Edu

In article <2ia5ej$9pj@wsdnws.cfi.waseda.ac.jp> 63912i@cfi.waseda.ac.jp ("Alexander During") writes:
>I tell you what: I have Linux running in a 4 Meg LAPTOP without any CD-ROM
>attached to it and it works. It is my choice to make it faster and throw
>in some more RAM, but it is definitely not compulsory as in the case of
>Windows NT. To make myself very clear: An OS that needs 16 Megs of RAM is
>just fucking unportable. Just because of that.

Amen.  With Linux, you can customize the installation to your needs.  You
can do without X if you want, and save some CPU cycles there.  I wonder
what a microsoft dealer would say if you asked if you could install NT
without the windowing system to cut back on requirements.  He'd probably
say something like "I don't understand"...

-- 
David Simmons, System Administrator                 simmons@ee.msstate.edu
Mississippi State University Electrical and Computer Engineering
"Linux:  Because a PC is a terrible thing to waste."                  

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

From: becker@super.org (Donald J. Becker)
Subject: Re: Which is better? 680x0 or 80x86?
Date: Wed, 26 Jan 1994 22:04:57 GMT

In article <2i14so$a4a@draco.unm.edu>,
-=| Bantolph |=- <bantolph@unm.edu> wrote:
>All of the recent discussion on Linux on the mac has made me come up
>with a few questions. Which is a better processor for running a UN*X
>like operating system on, the Motorola 680x0 series or the Intel 80x86
>series? I have heard a few people complain about 68000's not being able

Traditionally the 68K series has been the processor of choice for Unix-like
systems.  But the tremendous engineering and development efforts in the PC
market has removed most of the flaws and limitations in the original
x86 architecture and systems, and the clearly the processor family of choice
at the low end.

For quick comparison, what's the least expensive non-x86 processor board
capable of running a full VM OS that compares to a $250 66Mhz SLC2
motherboard?  


-- 

Donald Becker                                          becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715                        301-805-7482

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


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