Subject: Linux-Development Digest #312
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 15 Oct 94 13:13:11 EDT

Linux-Development Digest #312, Volume #2         Sat, 15 Oct 94 13:13:11 EDT

Contents:
  Re: Shared Libs: working toward a permanent solution? (H. Peter Anvin)
  Re: GNUStep...Is It Real or Just a Hoax?!? (Martin Michlmayr)
  We a FAQ: Linux vs. *BSD!!! (Jesus Monroy Jr)
  Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks) (Thomas Koenig)
  Re: Shared Libs: working toward a permanent solution? (Bryan Ford)
  Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive... (Michael Clarkson)
  Re: A badly missed feature in gcc (Kevin Lentin)
  Re: ext2fs vs. Berkeley FFS (Piers Cawley)
  Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Donald Becker)
  Re: A badly missed feature in gcc (Nate Williams)
  1.1.52 breaks Ingres creatdb (Enrico Badella)

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: Shared Libs: working toward a permanent solution?
Reply-To: [email-masked] (H. Peter Anvin)
Date: Sat, 15 Oct 1994 04:28:07 GMT

Followup to:  <[email-masked]>
By author:    [email-masked] (Brandon S. Allbery)
In newsgroup: comp.os.linux.development
> 
> I think you misunderstand his intent:  he's talking about using a segment
> register as if it were a general register containing an address.  Basically,
> using e.g. %gs as one would normally use %bp.  Segment overrides would not be
> used in this scheme; instead, the address would be calculated when needed by
> adding %gs to the library-base-relative address.
> 

No, no, no... that wouldn't work at all, especially since we're
talking 32-bit offsets here.  What I am talking about is using segment
aliasing; a segment can overlap another, but possibly with another
base (beginning offset).  Segment overrides can then be used instead
of a base pointer register.

        /hpa
-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
Microsoft is not the answer.  Microsoft is the question.  NO is the answer.

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

From: [email-masked] (Martin Michlmayr)
Subject: Re: GNUStep...Is It Real or Just a Hoax?!?
Date: 14 Oct 1994 15:19:41 GMT

Derrik Walker II ([email-masked]) wrote:
: I Seem to remember reading somewhere that FSF was working on a NeXTStep
: like environment (user and Development) that was Fully OOP - based  and 
: Display PS. This is intended to be ran on Linux for Mach 3.0 (Assuming 
: the Linux on Mach is also a real profect, of course).

 There is such a project. 
 GNUStep will run under X.It is as portable as the GNU Objective-C
 compiler. This current includes SunOS 4.1, Solaris 2.3, Ultrix 4.2, HP/UX
 9.x, SGI IRIX, OSF/1, FreeBSD, Linux, and perhaps others (but not AIX).

 There are several parts, which together build the GNU OpenStep project.
 One of those parts is the objcX library.
 objcX emulates NeXTSTEP and not OpenStep. There is a lot of work to do
 to convert it to OpenStep.

 There is no Display PostScipt suport yet, Keith Mason <[email-masked]>
 is coding this.

 There is also a FAQ, please contact me to get it.
:  
: So is this all a bunch of bull shit or is it real.  I love both Linux and NS,
: and a combaniation of the two would be the greatest!

 It is real, to join the mailing list, send mail to 
 [email-masked].

: If there is such a project, who do I contact to get involved?

me ([email-masked])

: -Derrik
:  [email-masked]                          [email-masked]
:         http://pclab19.law.csuohio.edu:8099/html/dwalker/home.html

  Martin Michlmayr <[email-masked]>

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

Crossposted-To: comp.os.386bsd.development,comp.sys.unix
From: [email-masked] (Jesus Monroy Jr)
Subject: We a FAQ: Linux vs. *BSD!!!
Date: Thu, 13 Oct 1994 08:31:14 GMT

        This is a weekly question.
        More often than not, we get into a flame war
        on this.  Let's stop this silliness!!!

        Can we get together and write a single FAQ on this?

        The distraction is overwhelming and we need a solution.

        I propose a single FAQ to answer the question:

        Which is better Linux or *BSD?

        It would have standard update procedures and 
        should be carried by the appropriate *.announce.

        Do I get a Yeah on this?

-- 
Jesus Monroy Jr                                          [email-masked]
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

From: [email-masked] (Thomas Koenig)
Subject: Re: Linux 1.1.52 (Lies, Damned Lies, and Benchmarks)
Date: 10 Oct 1994 22:41:50 GMT
Reply-To: [email-masked]

Jeff Kuehn ([email-masked]) wrote in comp.os.linux.development,
        article <[email-masked]>:

>       6.  And of course, the scheduler sucks mud.

I remember Matthias Urlichs reporting excellent results with the BSD
scheduler.  Would it be possible to run this test again, with this
scheduler patched in?
--
Thomas Koenig, [email-masked], [email-masked].
The joy of engineering is to find a straight line on a double
logarithmic diagram.

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

From: Bryan Ford <[email-masked]>
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 15 Oct 1994 11:09:18 -0400
Reply-To: [email-masked]

In message <[email-masked]> you write:
|   Date: Fri, 14 Oct 94 09:12:10 MDT
|   From: Bryan Ford <[email-masked]>
|
|   >The real problem with this sort of solution is that you have to educate
|   >GCC about segment registers, and you have to include the segment number
|   >into a pointer.  Otherwise, how is GCC supposed to know whether a
|   >pointer was pointing at memory from the library's data segment, or at
|   >memory passed in from the caller?  
|
|   It doesn't need to.  Any pointer that actually gets passed around in
|   a program in variables and such is still a 32-bit, absolute, "small model"
|   pointer as usual.  The only thing that needs to be changed is the method
|   of accessing or taking the address of a static variable.  To take the
|   address of a static variable, just convert the segment-register-relative
|   offset to a global, absolute offset by adding the base address of the
|   library, and use the resulting absolute pointer thereafter.  This will
|   work as long as a particular shared library doesn't move around in
|   a particular process's address space _while_it_is_running_, which would
|   be rather insane anyway. :-)
|
|Unfortuantely, life's not that simple.  What if you take the address of
|a static variable, and store it into a structure?  That structure member
|might contain a pointer to a static variable local to the shared
|library, or it might contain a pointer to memory in the main program's
|data segment.
|
|Or what the library routine needs to return the pointer to a static
|variable, like gethostbyname() does?

If the library takes a pointer to a static variable and stashes it in
a structure, passes it around, to the user, to twenty other libraries,
etc., it'll still work fine, because such pointers are _always_ relative
to the global data segment (DS), which permits access to the whole
virtual address space (including the libraries, at various offsets).
You only use the "special" segment register (GS or FS) to _directly_
access static variables within a library.  If you take the address of
a static variable in a library, the GCC-generated code _immediately_
converts the GS-relative offset into a DS-relative offset, and that
offset becomes the value of the pointer variable.  A DS-relative pointer
can be passed around arbitrarily and used anywhere.

|Without compiler support, people who code shared libraries would have
|to be very aware of the segmentation issues, since they would have to
|handle them by hand --- just as we do in the kernel.  I doubt that would
|be popular with applications programers.

You're still assuming I'm, proposing a general multisegment model.
I'm not!  I'm just proposing to use a segment register instead of ebx
(or whatever) to _initially_ find the address of static variables in
a library.  _All_ pointer variables, in library code or client code,
are _always_ relative to the _global_ segment (DS), and can be passed
anywhere and used for anything.  It's not a change in model at all;
just a minor architecture-specific hack to avoid losing a register.

Maybe an example would help.  First, some C code:

/* these are in a shared library */
extern int foo;
static bar = 3;

int *blah()
{
        int *x;

        foo = bar;
        x = &bar;
        *x = 5;
        return x;
}

/* this is in non-PIC client code */
void main()
{
        int *x = blah();

        printf("result: %d\n", *x);
}

Possible generated library code for blah():

_blah:
        pushl   %fs

        /* Load the library's data segment selector into fs.  */
        jsr     0f
0:      popl    %eax
        movl    _libseg-0b,%eax
        movw    %ax,%fs

        /* Assign from one library variable to another.
           Note that the values of the labels _bar and _foo,
           as the linker defines them, are library-relative.
           Hence we use %fs to access them.  */
        movl    %fs:_bar,%eax
        movl    %eax,%fs:_foo

        /* Take a pointer (x) to a static library variable (bar).
           Take the linker-defined library-relative offset
           and add the address of the library
           to find the global DS-relative pointer value.  */
        movl    $_bar,%eax
        addl    %fs:_libofs,%eax

        /* Access the data pointed to by that pointer from the library.
           All pointer variables are DS-relative, not FS-relative,
           even in the library, so don't specify a segment override at all.  */
        movl    $5,(%eax)

        /* Return the pointer to the client as well.
           Since it's already DS-relative,
           the client can access it with no problems.  */

        popl    %fs
        ret

(The code generated for main() is completely normal, non-PIC code.)

_libseg and _libofs are static variables in the library,
which are filled in when the library is loaded with the library's
data segment selector and the offset needed to convert an offset
relative to that selector into an offset relative to the global DS.

The stack pointer is always global (DS-relative) and shared by
all libraries and clients, so taking the address of an automatic
variable operates completely as usual.  Taking the address of a
function would operate just like taking the address of a static
variable - add the library's base address to come up with a global
address.  That way libraries can even pass function pointers to
other libraries or to clients.

Note that the code above could probably be optimized in various ways;
for one thing, it's really only necessary to load segment registers
in routines that are public entrypoints that can be called from
client code or from other libraries.  Also, it might be possible to
use the CS register instead of FS or GS as the library base "pointer";
the implementation would look quite different but mostly the same
principles would apply.  But these are just "possible optimizations";
the code as I presented it should work just fine.

Does this make things a little clearer?

                                Bryan

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

From: [email-masked] (Michael Clarkson)
Subject: Re: weird linux hangs 1.0.9 -> 1.1.51 inclusive...
Date: Thu, 13 Oct 1994 09:42:55 +0100 (BST)

Rob Newman wrote:

: We have similar problems --

: our setup:

: 486-DX2 66
: IDE 720MB hard disk  ( NO SCSI ! )
: 8 MB RAM
: NE2000 ethernet card

: In our setup, the hangs started when I upgraded from 1.1.10 to 1.1.45, and 
: became signicantly less frequent when I went to 1.1.50.  Man, if you figure 
: this out, I'd much appreciate it!

: Rob

We also have experienced similar problems:

our setup:

P5-66
WD Caviar 540 Mb HD
16 MB Ram
16 Mb Swap
NE2000 Ethernet Card
PCI STB Lightspeed 2Mb Ram

Looking at  the postings relating to this problem, it appears that the
connecting piece of hardware is the NE2000 Ethernet Card. In fact we seem
to have crudely fixed the problem by , by slowing down the reads/writes
performed by the Network Card.

If anyone else could suggest a better fix, please let me know.

Mike.

--
Michael Clarkson
Research Assistant
 ______  __   __    __ _  _
|  ____|/  \  \ \  / /(_)| |          FAXiL,    
| |___ / /_ \  \ \/ /  _ | |          The Wellcome Wing,
|  ___| ____ \  >  <  | || |          The General Infirmary,
| |  / /    \ \/ /\ \ | || |____      Leeds LS1 3EX, UK.
|_| /_/      \_\/  \_\|_||______|     Tel: 0113 2923595 Fax: 0113 2420926

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

From: [email-masked] (Kevin Lentin)
Subject: Re: A badly missed feature in gcc
Date: 13 Oct 1994 02:23:26 GMT

Jeff Kesselman ([email-masked]) wrote:

> Whats REALLY scary about thsi is you have just inroduced a dependancy on 
> a carraige-return into a language that previously assigned no syntactic 
> signifigance to a carriage-return beyond that of any other sperator.

> (Before you cite macros, remember that these are handle dby the 
> pre-processor, NOT the compiler proper.)

So are comments. The only non-C things the compiler sees are the # nn file
Directives so it knows where source comes from. So there is still no
meaning to the carriage return added to the comment syntax as far as the
compiler is concerned.

That aside, I believe C++ comments are better. They're great for single
line comments, make temporary removal of a line easy (I still use C
comments for temporary removal of small blocks of code and #if for bigger
ones). BUT I think C should remain C. You're just going to break something
somewhere eventually. 

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ [email-masked]  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

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

From: [email-masked] (Piers Cawley)
Subject: Re: ext2fs vs. Berkeley FFS
Date: Fri, 14 Oct 1994 13:36:44 +0000

In article <[email-masked]>
[email-masked] (Chris Bitmead) writes:
In another article someone writes:
   > Stuff about adding 'forks' to the filesystem deleted

   But the question still remains: Why do you want this???

Because it makes things simpler for many uses, especially for stuff like
associating documents with applications and the like -- file is generally not
clever enough to do this sort of thing. One could almost certainly write a far
more intuitive Desktop type frontend to X if you could be sure that all files
had associated info/data/resource forks.

   You say you would like a "main fork" in a file and then various
   "attribute" forks. Why this is better than a directory I don't know.

Because it makes it easier to write code. Even if it's syntactic sugar
'f0=open(foobar:INFO,RD_ONLY);' makes a good deal of sense, especially in
cases where foobar is an executable. I know you can stash a good deal of this
stuff in your .Xdefaults file and in /usr/lib/foobar or whereever, but it's
not exactly intuitive is it? Using data forks means that it becomes far easier
for a naive luser to move software about without breaking it by accident.

   Why should there be one "main" fork? And why are you too lazy to use cp -r
   to copy them?

Okay, you copy a fully working X application from one machine to another so
that it behaves in the same way on the new host as it did on the first one.
Now ask someone who doesn't have a great deal of experience with X to do the
same thing. Ask them to do the same thing with a Mac Application. I'll bet
good money that they do a far better job of the latter.

   What if you start to want forks with sub-forks. Soon you'll start to want
   the full facilities of directories, and we might as well leave it the way
   it is.

Oh don't be stupid.

   Don't be influenced by the over-featurism that NT offers. There's no need
   for this crud.

Actually, my model for this sort of thing is the Mac filesystem. I wouldn't
call it overfeatured, but it does a lot of stuff very well, and very easily,
that is a royal PITA to accomplish with Unix.

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

From: [email-masked] (Donald Becker)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
Date: 15 Oct 1994 10:11:34 -0400

[[ I rarely quote whole articles, but this one seemed important. ]]

In article <[email-masked]>,
Steve Davies <[email-masked]> wrote:
>We experience a problem on out Linux 1.1.19 systems where
>the inetd goes deaf and won't handle any more incoming connections.
>
>If you run inetd in debugging mode then as I recall you see that
>select() starts to return -1 [Dimly remembered]
>
>The fix is to kill inetd and start a new one.
>
>The cause?  I have found that the problem is caused by people connecting
>with SLIP and using the *wrong IP address* on their end.  In other words
>they have configured their IP stack with an address different from that
>in the diphosts file.

This would explain a lot!
The problem is unlikely to happen with other connection types.
Most people that could track this problem down have correctly configured
connections and never see the problem.

-- 
Donald Becker                                     [email-masked]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882         http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

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

From: [email-masked] (Nate Williams)
Subject: Re: A badly missed feature in gcc
Date: 12 Oct 1994 22:58:20 GMT

In article <[email-masked]>,
Chris Bitmead <[email-masked]> wrote:
>In article <wcreator.781655152@kaiwan009> [email-masked] (Steven M. Doyle) writes:
[ Using #ifdef or // to comment out lines out code ]

>>>use:
>>>#if 0
>>>#endif

>>      To each his own.  I personally use both in debugging my programs,
>>for one reason.  I see no reason to add the #if/#endif when one or three
>>lines of code is being commented out.  It's much simpler just to use /**/ or
>>//.

>Using comments is foolish IMO. With ifdef you can easily grep though the
>code to remove or look at commented out code. With C comments, it just
>gets lost.

And it totally confuses code formatters like indent.  With ifdef, you are
forced to make a (useless?) line which might give the reader an idea
why the code is commented out.

Nate

-- 
[email-masked]     |  FreeBSD core member and all around tech.
[email-masked]          |  weenie.
work #: (406) 994-4836       | 
home #: (406) 586-0579       |  Available for contract/otherwise work.

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

From: [email-masked] (Enrico Badella)
Subject: 1.1.52 breaks Ingres creatdb
Date: 14 Oct 1994 08:21:48 GMT

Has anyone used University Ingres with kernel 1.1.52? My impression is
that there is some problem handling environment variables of non root
users and/or setuid apps.

Quite a while ago I compiled University Ingres 8.9 with linux 0.99 and created
a installation diskette. I have used it on 1.0.8, 1.1.0, 1.1.20 and 1.1.45
linux kernels without problems. Now that I have upgraded to 1.1.52 the creatdb
utility refuses to work but everything else works fine. If I'm root creatdb
will effetively create a database in $INGRES/data/base but all file will be
owned by root, so they are not accessible but standard ingres commands. If
I try to create a database as an unpriviledged user the file will be written
in the current directory instead of $INGRES/data/base. If I created the
database with a kernel < 1.1.52 then swith to 1.1.52 everything works fine.

Any ideas before I plunge into debugging creatdb.c?

Thanks
eb

================================================================================
Enrico Badella                                  email  [email-masked]
Soft*Star s.r.l.                                       [email-masked]
Via Camburzano 9                                phone  +39-11-746092
10143 Torino, Italy                             fax    +39-11-746487

        People are strange
        When you're a stranger  (J. Morrison)
================================================================================

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

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