Subject: Linux-Development Digest #757
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:     Wed, 25 May 94 13:13:11 EDT

Linux-Development Digest #757, Volume #1         Wed, 25 May 94 13:13:11 EDT

Contents:
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Karl Holmstrom)
  Re: Can I get a core dump of a process I need to kill? (Mitchum DSouza)
  CORBA, OMG, Distributed Objects (Jens Krauss)
  Re: Zombie problems (Matthew Dillon)
  Re: Using emx/gcc for OS/2 and Linux (Holger Veit)
  Re: Skinny Dip (Jari Tomppo)
  Symmetric Multiprocessing for Linux? (ian_vogt@ACM.ORG)
  Re: Another Huge Security Hole! (Michael Peek)
  Re: enhanced IDE and SCSI-2 supported? (Michael Peek)
  Anyone have an EISA book or spec? (John Aycock)
  Re: SIGHUP - Deep Kernal Guts question! (Jim Robinson)
  Re: Virtual Consoles (John Lellis)
  Re: Can I get a core dump of a process I need to kill? (Simon Roberts)
  Re: Skinny Dip (Al Longyear)
  Re: SIGHUP - Deep Kernal Guts question! (Dan Swartzendruber)

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

From: kalle@kyyppi.kcl.fi (Karl Holmstrom)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Date: 25 May 1994 08:18:34 GMT

In article <1994May23.160927.11361@kf8nh.wariat.org> 
bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:

 According to RMS, the GPL *already* does this:  it covers, among other things,
 interfaces specific to the GPLed program.  Or are you claiming the details of
 the modules interface aren't specific to the Linux kernel?

OTOH Novell could have figured out how to add support for Unixware
loadable modules in the Linux kernel:-)  Should followups be redirected
to alt.conspiracy?

 - kalle
--


Karl Holmstro"m
Finnish Pulp and Paper Research Institute
P.O. Box 70, FIN-02151 ESPOO, Finland
Tel +358 0 4371306
email: kalle@sihti.kcl.fi

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

From: Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>
Subject: Re: Can I get a core dump of a process I need to kill?
Date: 25 May 1994 08:02:27 -0400
Reply-To: m.dsouza@mrc-apu.cam.ac.uk

| The subject pretty much says it.  I'm trying to debug a program that is
| going into a loop.  Is there anyway to get a core dump when I kill the
| process?  This would really help since it usually takes about three hours
| of use before the program goes into the loop so stepping through with
| debug is obviously out of the question.

Why don't you just use `gdb' to attach itself to the running process once it goes
into the loop and debug from there. Use the "attach" command in gdb giving the
pid of the process as the argument.

Mitch

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

From: krauss@charlie.igd.fhg.de (Jens Krauss)
Subject: CORBA, OMG, Distributed Objects
Date: 25 May 1994 11:20:42 GMT
Reply-To: igd.fhg.de


Hy all there!

I'm very interested in distributed objects, perhaps I would like to 
implement something like that. If sombody out there is working on
dostributed objects for linux, mail me.
If nobody is out there, is there interest for an "corba"???

The problem is, that I have no acces to the OMG documents. But I have some 
ideas how to implement such thing. But whats about the standards...???
Would it be a good idea to programm such thing???

If there is no interest, perhaps I#ll doing it for my own, without standards!!

Ciao Jens

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

From: dillon@apollo.west.oic.com (Matthew Dillon)
Subject: Re: Zombie problems
Date: 24 May 1994 14:45:42 -0700

In article <BCR.94May24032448@k9.via.term.none> bcr@physics.purdue.edu writes:
:
:Hi there,
:
:I'm working on a set of routines that replace the standard networking
:routines for use with term.  This will allow me to port programs to
:term just by adding an include file.  So far things are working fine
:...
:
:there any other things I can check, or some trick to insure that
:the processes don't become zombies when the child exits?
:
:                              Bill

    When a child process exits, it *always* becomes a zombie *until* the
    parent reads the child's exit code with wait(), waitpid(), wait3(), or
    wait4().

    File descriptors have nothing to do with it.  Try this program, for
    example:

    #include <sys/types.h>
    #include <sys/wait.h>

    main()
    {
        int pid;

        if ((pid = fork()) == 0) {
            /*
             * This is the child process
             */
            sleep(6);
            exit(0);
        }
        /*
         * parent process (assume fork() doesn't fail for this example)
         */
        sleep(12);
        wait4(pid, NULL, 0, NULL);
        sleep(12);
        exit(0);
    }

    % cc /tmp/x.c -o /tmp/xxx
    % alias look "ps ax | fgrep xxx; echo ''"
    % /tmp/xxx &; sleep 3; look; sleep 6; look; sleep 12; look; sleep 12; look

 2425  p4 S     0:00 /tmp/xxx           parent and child running
 2427  p4 S     0:00 /tmp/xxx

 2425  p4 S     0:00 /tmp/xxx           child has exited, parent has not read
 2427  p4 Z     0:00 (xxx) <zombie>     the exit code yet

 2425  p4 S     0:00 /tmp/xxx           parent has read the exit code, child
 2435  p4 S     0:00 fgrep xxx          gone completely

 -                                      parent exits


    If you want to fork off a child and then not have to worry about dealing
    with his exit code later on, you can do a double fork:


        if ((pid = fork()) == 0) {
            /*
             * middle child
             */

            if ((pid = fork()) == 0) {
                /*
                 * lower child you want to detach
                 */
                dolotsofstuffhere();
                ...
                exit(0);
            }

            /*
             * middle child exits immediately, leaving the lower child
             * parentless (i.e. lower child's parent reverts to pid 1
             * when middle child exits).
             */
            exit(0);
        }

        /*
         * parent waits for middle child to exit
         */
        wait4(pid, NULL, 0, NULL);

    This way, you leave the lower child completely detached from the parent
    process -- if you close all your descriptors AND do a TIOCNOTTY ioctl()
    on /dev/tty, the process would also be effectively detached from the
    controlling terminal.

    Neat, eh?

                                                -Matt


-- 

    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: veit@borneo.gmd.de (Holger Veit)
Crossposted-To: comp.os.os2.programmer.porting
Subject: Re: Using emx/gcc for OS/2 and Linux
Date: 25 May 1994 08:35:22 GMT

In article <COATES.94May25174336@kelvin.physics.uq.oz.au>, coates@kelvin.physics.uq.oz.au (Tony Coates) writes:
|> In article <1994May21.212900.23676@midway.uchicago.edu> roe2@ellis.uchicago.edu (Cave Newt) writes:
|> 
|>    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
[...]
|>    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 
[...]
|> As to questions of Linux recognising the DOS stub, I know nothing of
|> the OS/2 or Linux executable file formats, but I assume that Linux,
|> like UNIX, uses a magic number to recognise executable file formats.
|> Thus if the OS/2 and Linux executable file formats aren't too
|> different (?) it might be possible to define a new magic number, which
|> would need to be imbedded in the DOS stub, defining a `Linux/OS/2'
|> merged executable.  It might be harder to make OS/2 understand any
|> sort of change in the stub, but I don't know at all what is possible
|> there.  If anyone can comment on whether what I am suggesting is
|> possible, or whether the two file formats are really too incompatible,
|> I would be interested to hear.

The stub itself does not mean anything, it just prints out a message like
'This program must be run under OS/2' (or Windows) and then exits.
No need to engage the dosemu for that. What is behind that stub are
special executable types with an id 'NE' (new executable, which is commonly 
16:16 segmented) or 'LX' (Linear executable, used by OS/2 for real 32 bit apps).
You seem to misunderstand the concept of 'magic numbers', actually, with a simple
entry in /etc/magic that points to the NE/LX entries it is no problem to
identify what type of executable is present.
However, the a.out format used by Linux is *very* different from the NE/LX formats.
A loader for NE-type files (under Windows) is needed for the Wine project,
and I guess it will be a real hack to mess around with segments, LDT entries,
different relocation mechanisms and several vendor additions.
The LX format should be more clean w.r.t. this, although several things like 
preloaded pages, debugging information, and other tricky additions would make the
job not simple as well.
What you basically need is a new program loader that detects NE/LX, puts the
executable in memory, does the necessary fixups and relocations, sets up the LDT
entries, registers and then runs the executable.
The problem is that you would have to consider several communication mechanisms with
the OS/2 kernel, such as kernel semaphores, shared memory accesses, conversion of
physical to virtual memory and vice versa, thread handling, the set of
FS_HELPER and DEV_HELPER routines that could occur occasionally, and many more
obstacles. Not all of these mechanisms are hidden in DLLs, but are performed
by indirect calls of functions whose address is provided by the kernel during
bootup (This is common for OS/2 device drivers, which is not necessarily wanted,
but I would not give any guarantee that apps doing certain tasks do not rely on 
these or similar mechanisms).
Another problem is that you have to rewrite all the DLLs that exist
under OS/2 for Linux. Only some of them are specified in detail in the
documentation. You would be surprised how many of them could be involved directly
or indirectly even for a small OS/2 program. The Wine developers already have a
hard job with porting about a dozen files containing the (public) API for Windows,
the OS/2 API is much more complex, provided you do not want to restrict yourself
to text mode apps (emulating OS/2 1.X).

-- 
         Dr. Holger Veit                   | INTERNET: Holger.Veit@gmd.de
|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...

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

From: tomppo@phys-3.jyu.fi (Jari Tomppo)
Subject: Re: Skinny Dip
Date: 25 May 1994 11:23:34 GMT
Reply-To: tomppo@tukki.jyu.fi

: Matt Keogh (keogh@anshar.shadow.net) wrote:

:                The ORIGINAL thigh cream, as seen on national TV
:                    This is the NEW, SUPER STRENGTH formula
:                      Accept none of the immitation creams
:                             YOU'RE WORTH THE BEST!!!

:      Now only $29.95 per bottle which INCLUDES shipping, handling and tax
:          U.S. orders only, please.  Rush check or money order to:

What's the story behind that fuckin' moron? I tried to send mail to
root@shadow.net & root@anshar.shadow.net, but they bounced back. I've 
seen that fuckin' advertisement in tens of newsgroups during this week.

Do we have a new canter&siegel case here?

--
-=: =========== : e-mail   : tomppo@tukki.jyu.fi : Tel. 949/ 542 929 :=-
-=: Jari Tomppo : snailmail: Rivitie 6 as 2  40950 Muurame  FINLAND =:=-
-=: =========== : Elama on aika tulsaa  --Freud, Marx, Engels & Jung :=-

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

From: ian_vogt@ACM.ORG
Subject: Symmetric Multiprocessing for Linux?
Date: 25 May 1994 14:07:27 GMT
Reply-To: ian_vogt@ACM.ORG

Are there plans afoot to extend Linux to support symmetric
multi-processing (a la Mach?)

I am a newcomer to Linux (and relatively new to *nix).
My main interest is in finding a good operating system for
high-reliability applications using multiple processors
(e.g. Master-Standby).

Thank you, Ian

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

From: peek@duncan.cs.utk.edu (Michael Peek)
Crossposted-To: comp.os.linux.admin
Subject: Re: Another Huge Security Hole!
Date: 25 May 1994 14:11:14 GMT

Uri Blumenthal (uri@watson.ibm.com) wrote:
: Hi,
:       It's Linux-1.1.14. The problem is: when you
:       log in as <whoever>, it still gives you UID
:       [you guessed it :-] 0.  I.e. to become root
:       on Linux-1.1.14,  you just have to login to
:       the box...

:       Linux-1.1.13 doesn't exhibit such bad behavior.

:       No fix yet, as I didn't figure out the cause.
:       One thing seems certain - it has nothing to 
:       to with getty/login/whatever program...The
:       new (1.1.14) kernel has your UID==0 always,
:       1.1.13 seems to be correct.

:       Regards,
:       Uri.
: ------------
: <Disclaimer>

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

From: peek@duncan.cs.utk.edu (Michael Peek)
Subject: Re: enhanced IDE and SCSI-2 supported?
Date: 25 May 1994 14:17:09 GMT

: If you mean burst-mode IDE support then the answer is a solid YES.
: There is a IDE-patch that has been posted in the news-groups.
: If you missed that one, I'll be happy to post it again.
: Concerning SCSI-2 support, I strongly believe that has been part
: of the drivers for a long time now.
: Hope this answers your question,
: Martijn.

How about the new IDE's that support 4 drives?  Does anyone know if/when
they will be supported?

Mike Peek - peek@math.utk.edu

#define std_disclamer \"I know nothing - take everything I say with\
a pinch of salt\"


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

From: aycock@cpsc.ucalgary.ca (John Aycock)
Subject: Anyone have an EISA book or spec?
Date: Wed, 25 May 1994 02:28:45 GMT

If you have one of these handy (I don't, obviously), I'm writing a
device driver for a SCSI card.  My documentation says that some EISA
config information is stored in "the free-form data area of system
RAM", which I presume is marked off on a per-EISA-slot basis.

Question: where the !@&#^%$ is this area, so I can access it?  Any
information gratefully accepted.
:ja


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

From: jimr@shorty.cs.wisc.edu (Jim Robinson)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 25 May 1994 00:54:43 GMT

In article <2rtcac$7rs@paperboy.osf.org> dswartz@pugsley.osf.org (Dan Swartzendruber) writes:
[...]
>I think you're both misreading his statement.  He didn't say it is
>bad to write your programs to be POSIX compliant, he said it is bad
>programming to write your programs assuming they will always run on
>a POSIX-compliant platform.  There's a world of difference, as I'm a
>few minutes of thought will show...

Actually I was not mis-reading it, my point was that it seems rather
silly to put in portable code for every non-posix system unless you
know for sure that there is a strong interest in it running on a
non-posix compilient system.  Again, I had been under the impression
that almost all major systems have, or are trying to have, posix
compilence.  The point was made in an earlier post that if you know
there is interest in non-posix ports, you should put in defs to handle
them.  I agree with that.

Jim


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

From: lellis@dmccorp.com (John Lellis)
Subject: Re: Virtual Consoles
Date: 25 May 1994 14:29:45 GMT

Stuart Herbert (ac3slh@sunc.sheffield.ac.uk) wrote:
: Apologies if this is to the wrong group :) but I'm looking for instructions
: on how to increase the number of virtual consoles I have available.

: Ideally, I'd like to have up to 24 :) (ALT F1-F12, and SHIFT-ALT F1-F12 if
: possible).  I've located the #define for setting the number of consoles,
: but I don't know what else I need to do to make it recognise the keypresses.

: Thanks,

: Stuart
: --
: Stuart Herbert -- S.Herbert@shef.ac.uk

In /linux/include/linux/tty.h, change the line:

        #define NR_CONSOLES     8

to whatever number you want.  In my case, I made it 12.

--

John Lellis (lellis@dmccorp.com)

--
... Our continuing mission: To seek out knowledge of C, to explore
strange UNIX commands, and to boldly code where no one has man page 4.




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

From: simonr@unipalm.co.uk (Simon Roberts)
Subject: Re: Can I get a core dump of a process I need to kill?
Date: Wed, 25 May 1994 14:30:34 GMT

Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk> writes:

>| The subject pretty much says it.  I'm trying to debug a program that is
>| going into a loop.  Is there anyway to get a core dump when I kill the
>| process?  This would really help since it usually takes about three hours
>| of use before the program goes into the loop so stepping through with
>| debug is obviously out of the question.

>Why don't you just use `gdb' to attach itself to the running process once it goes
>into the loop and debug from there. Use the "attach" command in gdb giving the
>pid of the process as the argument.

Sound enough.  If you really want to do it 'the hard way' you can
send the process a SIGILL (illegal instruction trap) and it will
core dump anyway.  I think there are other signals that will do
this also.

Simon
-- 
======================================================
Simon Roberts                    simonr@compucol.co.uk
                                 (0223) 250127
The Computer College             +44 223 250127

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

From: longyear@netcom.com (Al Longyear)
Subject: Re: Skinny Dip
Date: Wed, 25 May 1994 13:50:52 GMT

nik@myhost.subdomain.domain (nik w.) writes:

>so i guess we are finally experiencing what is probably just the beginning
>of endless tedious thousands of BULLSHIT advertisements...
>i guess we can do nothing but flame the hell out of these people until their
>disk drives explode.   on to battle!

There is only one type of fool who is worse that those who post
blatant advertisements on usenet and that is the fool who copies
the entire article only to add his comments to it!

It is bad enough to ignore the original item, but to have the same
article appear under different names because the fool copies it
is going a little too far.

If you are so provoked as to comment on it, then please do us all a
favor and do a little selective deletion.

The best way to get the advertisers off the network is to ignore
their advertisements. Their advertisements will expire and go away all
by itself.

I would have sent this by mail. However, you seem to have not setup
your own system correctly. Maybe a jar skinny dip will help. :)
-- 
Al Longyear           longyear@netcom.com

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

From: dswartz@pugsley.osf.org (Dan Swartzendruber)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 25 May 1994 16:53:57 GMT

In article <2ru7kj$5ua@spool.cs.wisc.edu>, jimr@shorty.cs.wisc.edu (Jim Robinson) writes:
> In article <2rtcac$7rs@paperboy.osf.org> dswartz@pugsley.osf.org (Dan Swartzendruber) writes:
> [...]
> >I think you're both misreading his statement.  He didn't say it is
> >bad to write your programs to be POSIX compliant, he said it is bad
> >programming to write your programs assuming they will always run on
> >a POSIX-compliant platform.  There's a world of difference, as I'm a
> >few minutes of thought will show...
> 
> Actually I was not mis-reading it, my point was that it seems rather
> silly to put in portable code for every non-posix system unless you
> know for sure that there is a strong interest in it running on a
> non-posix compilient system.  Again, I had been under the impression
> that almost all major systems have, or are trying to have, posix
> compilence.  The point was made in an earlier post that if you know
> there is interest in non-posix ports, you should put in defs to handle
> them.  I agree with that.

Well, that's not what was said.  The way the post to which I responded
was phrased implied that he was saying one shouldn't do POSIX compliance.

Despite the fact that POSIX is supposed to be a standard, I would
venture to guess that the majority of Unix systems out there are
not POSIX-compliant.  Given this, not checking for an error condition
or a signal or whatever because it can never happen on a POSIX system
strikes me as somewhat like the pedestrian being run over by a car -
technically he's in the right, but he's still dead...

-- 

#include <std_disclaimer.h>

Dan S.

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


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