Subject: Linux-Development Digest #838
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, 17 Jun 94 02:13:05 EDT

Linux-Development Digest #838, Volume #1         Fri, 17 Jun 94 02:13:05 EDT

Contents:
  Re: DOSEMU and Novell ("Brian E. Gallew")
  please help me... (Qi Y. Zeng)
  Yggdrasil Linux with GNU C++ ?? (sysop@comet.sb.sub.de)
  X-based backup (Modesto Tabares)
  mmap() and files ? (Andrew McGregor)
  Testing system memory? (Bogdan Urma)
  Compiling the kernel faster (Bogdan Urma)
  Re: Compiling the kernel faster (Arnt Gulbrandsen)
  IP Header errors (bryan collins)
  XBackup (Modesto Tabares)
  Re: Compiling the kernel faster (Kevin Lentin)
  Re: DOSEMU 0.52 (was Cannot compile dosemu0.50pl1 with kernel 1.1.19) (Mark Rejhon)
  Re: Filesystem semantics protecting meta data ... and users data (WLC)
  Re: Compiling the kernel faster (Thomas G. McWilliams)
  Re: Linux and symmetrical multiprocessing (Drew Eckhardt)
  ELF and COFF (Limin Yan)
  Linux and 2.88MB floppies? (Bill Broadhurst)
  Re: PCI Motherboards & Cards (Eckard Kopatzki)
  Re: DOSEMU and Novell (Mark Evans)
  Re: mmap() and files ? (Robert Sanders)

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

From: "Brian E. Gallew" <geek+@CMU.EDU>
Crossposted-To: comp.os.linux.help
Subject: Re: DOSEMU and Novell
Date: Thu, 16 Jun 1994 13:59:40 -0400

evansmp@mb52112.aston.ac.uk (Mark Evans) writes:
> Andrew Anderson (andersoa@news.db.erau.edu) wrote:
> : I have gotten DOSEMU to allow me to telnet into my Linux box and
> : login to my Novell file server.  However, DOSEMU appears to be hard-
> : coded somewhere to use the eth0 network device.  I did a grep on all
> : of the source code to DOSEMU, and changed all references to the eth0
> : device, but it will not talk to eth1.
> 
> : I need to have DOSEMU run on 2 different cards, because the netx client
> : will give me a security breach if 2 users try to login from the same
> : ethernet hardware address.  I have asked the novell group if vlm's fix
> : this (like the OS/2 requestor), but no one has replied.  I really need
> : to have the ability to run multiple DOSEMU sessions into my Novell
> : server, so any pointers are appreciated!
> 
> Attempting to run more than one DOSEMU on the same machine at once
> and attempt to get network connections running from both sessions
> is something which I think is currently not likely to work.
> Currently some of what should be in the kernel is in DOSEMU.
> (i.e. the "stubs" arn't quite "stubby" enough.)

Interesting, but I've been doing this here so that I can run MSMail in
one and be able to browse around the server on the other.  Admittedly,
I haven't been doing anything intensive or of extensive duration, but
I *have* had two netx/dosemu sessions going on simultaneously.

=========================================================================
| Little girls, like butterflies, need no excuse - Lazarus Long         |
=========================================================================

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

From: qizeng@acsu.buffalo.edu (Qi Y. Zeng)
Subject: please help me...
Date: Thu, 16 Jun 1994 01:53:14 GMT

Dear Netters:

I partitioned my 240 MB HD into
2 parts with 120 MB each. One
part is for DOS and Wins while 
another is for linux.

Because I have a project which
needs more space, I want to purge
Linux for the time being and use
that space as, for example, drive D.

Could you tell me howw to do it?

With best regards and many thanks!



-- 
qizeng@acsu.buffalo.edu
tel:716-691-7397

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

From: sysop@comet.sb.sub.de
Subject: Yggdrasil Linux with GNU C++ ??
Date: 15 Jun 1994 19:17:43 +0200

Hi,
i have seen here in a german store a Distribution of
Linux 1.1 from Yggdrasil named PLUG and PLAY LINUX !

I looked at the package, and ask the dealer, but it wont
help me to find out: Is this Linux Distribution delivered with
GNU C++ - Compiler ?



Richard Koenig +-----------------------+ Comet-Link
says: RAVING ! ! Sysop@comet.sb.sub.de ! +49-621-28823
what else ?    +-----------------------+ Mannheim, Germany

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

From: tm1@cis.ufl.edu (Modesto Tabares)
Subject: X-based backup
Date: 16 Jun 1994 18:50:16 GMT


anybody know if there is any X-based backup utility in the works?
sort of like a front end to tar and mt


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

From: physadm@phys.canterbury.ac.nz (Andrew McGregor)
Subject: mmap() and files ?
Date: 16 Jun 1994 05:00:47 GMT

Is anybody developing an mmap() system call that can map files
read-write at the moment? Are there any really horrible problems with
doing this? I'd be interested in having a go, however it'd be useful to
know what has already been done.

Andrew McGregor
Physics, University of Canterbury,
Christchurch, New Zealand
-- 
Andrew McGregor,
Physics, University of Canterbury, Christchurch, New Zealand.
adm@phys.canterbury.ac.nz

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

From: bogdan@crl.com (Bogdan Urma)
Subject: Testing system memory?
Date: 15 Jun 1994 23:02:55 -0700



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

From: bogdan@crl.com (Bogdan Urma)
Subject: Compiling the kernel faster
Date: 15 Jun 1994 23:09:25 -0700

    If I do a 'make -j zImage' shouldn't that compile my kernel faster
(more processes running at the same time),than just 'make zImage'?? 
For me it takes about the same time!

Bogdan
bogdan@crl.com


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

From: agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Compiling the kernel faster
Date: 16 Jun 1994 21:18:57 +0200

make -j isn't so good, but what I use, "make -j 5 -k -l 4.0" seems
about right if there's enough RAM to avoid swapping, and enough
files to compile in the same directory to keep the CPU utilisation
at 100%.  (I usually use a 16MB RAM 486 with no other users, and
without any X server).

If you don't supply an argument to -j, it will start all the
compiles in each directory at the same time, no good idea.

The important thing is to avoid make clean, of course.

--Arnt

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

From: bryan@raid (bryan collins)
Subject: IP Header errors
Date: 16 Jun 1994 08:45:13 GMT

I'm running 1.1.18 and I get the following the other day..

May 16 08:02:00 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 08:02:20 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 08:20:14 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 08:20:47 raid kernel: general protection: 0000
May 16 08:20:47 raid kernel: EIP:    0010:0013a10c
May 16 08:20:47 raid kernel: EFLAGS: 00010206
May 16 08:20:47 raid kernel: eax: 00000022   ebx: 00995192   ecx: 00000000   edx
May 16 08:20:47 raid kernel: esi: 0099a806   edi: 009951a6   ebp: 00824c00   esp
May 16 08:20:47 raid kernel: ds: 0018   es: 0018   fs: 002b   gs: 002b   ss: 001
May 16 08:20:47 raid kernel: Process crack-pwc (pid: 19632, process nr: 28, stac
May 16 08:20:47 raid kernel: Stack: 0013af33 00824c00 00824c8c 00824c00 3e22e769
May 16 08:20:47 raid kernel: Code: 53 8b 5c 24 08 8b 83 98 00 00 00 53 8b 40 10
May 16 08:20:47 raid kernel: Aiee, killing interrupt handler
May 16 09:54:18 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 09:54:37 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 09:57:19 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 09:57:39 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 10:00:21 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo
May 16 10:00:42 raid kernel: ICMP: Could not build IP Header for ICMP ECHO Respo

theres hundreds and hundred of these "could not create IP header" lines.

anyone else seen this?

bry

--

bryan collins

                email:
                        b@ctpm.org


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

From: tm1@cis.ufl.edu (Modesto Tabares)
Subject: XBackup
Date: 16 Jun 1994 18:44:02 GMT


anybody know if there is any graphics based backup utility for linux in the works
sort of like an X front end for tar and mt.



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

From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Re: Compiling the kernel faster
Date: 16 Jun 1994 06:36:44 GMT

Bogdan Urma (bogdan@crl.com) wrote:
>     If I do a 'make -j zImage' shouldn't that compile my kernel faster
> (more processes running at the same time),than just 'make zImage'?? 
> For me it takes about the same time!

There's only so much work your machine can do. There's a fixed amount of
work that needs doing to compile a kernel and so the time taken to compile
your kernel would be roughly the same when using multiple jobs. Multiple
jobs will speed things up if 

a) They result in you getting more use of the kernel. If lots of other
things are happening and you compilation represent 1/5 of that then
doubling the process to make it 2/6 gives you more time.

b) The processor is spending time doing nothing waiting for things, like
disks to do their stuff. Chances are that you machine is not doing this and
that your compilation is spending most of the time chewing up as much CPU
time as possible. Run 'top' while it is happening to see.

BUT, (and this applies especially to the first suggestion) one should bear
in mind that increasing the number of processes dedicated to a job does not
necessarily increase speed even if a) above is true. More time is needed to
switch processes (it's only a little though) and depending on what you are
doing, you will probably start using more memory. In the end, unless you
have lots of memory, you could start swapping which just slows things down
again.

In general using make -j will not speed up a compilation unless certain
specific conditions are met. A lot of the time it could end up slowing it
down. Now, if you had a SPARC 10 with lots of processors in it, that would
be a completely different story.

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

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

Crossposted-To: comp.os.linux.admin,comp.os.linux.help
From: mdrejhon@calum.csclub.uwaterloo.ca (Mark Rejhon)
Subject: Re: DOSEMU 0.52 (was Cannot compile dosemu0.50pl1 with kernel 1.1.19)
Date: Thu, 16 Jun 1994 16:02:08 GMT

You need DOSEMU 0.52 for Linux 1.1.12+ ... So you should go to the
sunsite FTP site tonight..  This is going to be released tonight (I know this
because I'm part of the ddosemu development team!)

Mark Rejhon


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

From: wcorcor@netaxs.com (WLC)
Crossposted-To: comp.benchmarks,comp.sys.sun.admin,comp.security.unix
Subject: Re: Filesystem semantics protecting meta data ... and users data
Date: 17 Jun 1994 00:20:25 GMT

Totally Lost (idletime@netcom.com) wrote:
: In article <2tn6pd$5gr@fido.asd.sgi.com>,

: Nobody asks ... probably true ... I think most assume (falsely)
: the reliability exists and seldom see a failing case that would worry
: them. Being enlightened you might say, I see many unix
: applications that scare the shit out of me knowing
: what can (and has in several cases) happened to critical
: data that peoples lives depend on.

: All the pharmacies systems running on SCO XENIX/UNIX and other PC UNIX's
: are time bombs from my point of view ... going to kill somebody
: or leave them with unnecessary damage.


  This is a very harsh statement.  You can only do so much with the operating
  system proper.  Nothing is going to stop a defective disk controller board
  or other insane hardware from possibly subtly damaging your data.

  The chances of a user typing in the wrong patient ID or a technician 
  entering the wrong result are MUCH greater than the type of failure
  you present; even so chances are the patient is not going get hurt.
  There are other checks that go on within the pharmacy.  

  It sure would be nice to see your ideas implemented though!

Bill Corcoran
bill@classix.com

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

From: tgm@netcom.com (Thomas G. McWilliams)
Subject: Re: Compiling the kernel faster
Date: Thu, 16 Jun 1994 21:13:21 GMT

Bogdan Urma (bogdan@crl.com) wrote:
: If I do a 'make -j zImage' shouldn't that compile my kernel faster
: (more processes running at the same time),than just 'make zImage'?? 
: For me it takes about the same time!

For most Linux-class machines, you should provide an argument
to the '-j' switch.  It seems "-j3" ,"-j4", and "-j5" are
typical "good" values, with "-j4" a reasonable starting point:

                 make -j4 zImage

Using the '-j' switch without a numeric argument might cause
problems on some machines and result in slower compilation.
The proper choice is dependent on the machine's load average. 
My suggestions are based on a lightly loaded machine.

Thomas
tgm@netcom.com

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

From: drew@kinglear.cs.colorado.edu (Drew Eckhardt)
Subject: Re: Linux and symmetrical multiprocessing
Date: 16 Jun 1994 18:30:35 GMT

In article <2tntkd$qsb@sun.cais.com>,
Eric Youngdale <ericy@cais.cais.com> wrote:
>In article <2tkmju$a5d@bigblue.oit.unc.edu>,
>Jonathan Magid <jem@bittyblue.oit.unc.edu> wrote:
>>Ah ha! Just as I always suspected, "Alan Cox" is a codename for the entire
>>computer society!
>>
>>Now if we can just figure out the organization which lurks behind the 
>>nom-de-compute "Eric Youngdale".
>
>       I need to get a life.  Perhaps I should say that we need to get a 
>life :-).

Speaking from personal experience, that would be terrible!  Since 
I got a life, I've noticed release dates slipping by months, a limited
motivation to fix non-critical bugs...
-- 
Drew Eckhardt drew@Colorado.EDU
1970 Landcruiser FJ40 w/350 Chevy power
1982 Yamaha XV920J Virago

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

From: liminyan@pollux.usc.edu (Limin Yan)
Subject: ELF and COFF
Date: 16 Jun 1994 17:52:39 -0700


Hi:

when I rebuild the kernel, it asks if I want program binaries in ELF
and COFF, what are ELF and COFF, how  they related to LINUX

- Elliot

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

From: bbroad@netcom.com (Bill Broadhurst)
Subject: Linux and 2.88MB floppies?
Date: Thu, 16 Jun 1994 21:27:02 GMT

Has anyone modified floppy.c to handle the perpendicular recording
method used in 2.88MB floppies?  If so, please tell me where I ca  get a
copy.  

If not, if someone would please send me the table information for the
2.88MB floppy format (especially the gap information) I will make the
modifications and do the testing/distribution to the many who have sent
me requests for the patch.  

Thanks in advance... 

-- 
 -----------------------------------------------------------------------
 Bill Broadhurst   | Independent contract Engineer.        | Finger for 
 San Diego, CA.    | PC Systems Development & Integration. | PGP 2.6 
 bbroad@netcom.com | Coding: BIOS & Diags (x86 Assembly)   | public key. 
 ----------------------------------------------------------------------- 

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

From: root@stevie.isar.muc.de (Eckard Kopatzki)
Subject: Re: PCI Motherboards & Cards
Date: 16 Jun 1994 22:40:15 GMT

Hi Keith,

recently, a PCI-HOWTO appeared in the common places (sunsite, tsx, ...) which
draws together what works and what does not work. For now, PCI seems to be no 
problem in general but at least the NCR (not NCE) SCSI controller is not
supported yet (the only PCI-SCSI controller working yet is manufactured by
Buslogic, or you can plug in your old AHA1542 and wait for Drew Eckhardt to
finish his development).

-- 
Eckard Kopatzki           Internet eko@isar.muc.de
Therese-Giehse-Allee 53     CompuServe 100024,2175
D-81739 Muenchen, Germany     Voice +49-89-6378103

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

Crossposted-To: comp.os.linux.help
From: evansmp@mb52112.aston.ac.uk (Mark Evans)
Subject: Re: DOSEMU and Novell
Date: Thu, 16 Jun 1994 16:09:32 GMT

Andrew Anderson (andersoa@news.db.erau.edu) wrote:
: I have gotten DOSEMU to allow me to telnet into my Linux box and
: login to my Novell file server.  However, DOSEMU appears to be hard-
: coded somewhere to use the eth0 network device.  I did a grep on all
: of the source code to DOSEMU, and changed all references to the eth0
: device, but it will not talk to eth1.

: I need to have DOSEMU run on 2 different cards, because the netx client
: will give me a security breach if 2 users try to login from the same
: ethernet hardware address.  I have asked the novell group if vlm's fix
: this (like the OS/2 requestor), but no one has replied.  I really need
: to have the ability to run multiple DOSEMU sessions into my Novell
: server, so any pointers are appreciated!

Attempting to run more than one DOSEMU on the same machine at once
and attempt to get network connections running from both sessions
is something which I think is currently not likely to work.
Currently some of what should be in the kernel is in DOSEMU.
(i.e. the "stubs" arn't quite "stubby" enough.)

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

From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: mmap() and files ?
Date: 17 Jun 1994 03:21:49 GMT

In article <PHYSADM.94Jun16170047@newton.phys.canterbury.ac.nz> physadm@phys.canterbury.ac.nz (Andrew McGregor) writes:

   Is anybody developing an mmap() system call that can map files
   read-write at the moment? Are there any really horrible problems with
   doing this? I'd be interested in having a go, however it'd be useful to
   know what has already been done.

Well, it's difficult to do with reasonable semantics and unreasonable
good performance, which is what most Linux users expect.  It will take
a (further) reworking of the mm and buffer cache to do right, and no
one wants to invest the effort in mmap() until the other subsystems
are up to snuff.  From a Linus posting on the KERNEL mailing list:

 > > Technically, what you ask is what I had in mind.  The actual mmap
 > > syscall does not map any pages to the process, but the page fault
 > > routine looks through the list of mmaped regions to find out how to
 > > obtain the page in question.  Different types of files can have
 > > different routines for mmap - for general disk files on non-NFS
 > > filesystems there is one special function for this, and it is
 > > actually this routine that I propose be modified.
 >  
 > Actually, I'll eventually redo the whole IO subsystem: I've been
 > thinking about it for a long time, and now that 1.0 is out, I can
 > hopefully do it when I have more time. The current system works very
 > well, but has a couple of problems:
 >  - full mmap() semantics are hard to get (write mappings)
 >  - the code to handle sharing buffers etc is horribly complex
 >  
 > What I'll eventually do is just make away with the buffer cache
 > altogether, and do it all with the memory management: I have a
 > reasonably good idea on how to do this efficiently without actually
 > having to rewrite all the filesystem code.
 >  
 > The big change is to stop using "devnr, blocknr" pairs for the buffer
 > cache, and instead use "inode, pagenr" pairs in the memory management
 > code.  The advantages are legio, and the disadvantages not too bad.
 > For
 > the current page sharing, we'd need to move over the the 4kB aligned
 > executable format, but this is a longish-term project anyway.
 >  
 > And yes, it means we can cache NFS stuff with a timeout etc..  No more
 > VFS "read/write/mmap/bmap", just a "readpage/writepage" routine.
 > Swapping over NFS/msdos/whatever should also become automatic with
 > these.

So, have a go if you wish, but coordinate with the other developers
(especially those that read the KERNEL mailing list).

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


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