Subject: Linux-Development Digest #81
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, 10 Sep 93 04:13:06 EDT

Linux-Development Digest #81, Volume #1          Fri, 10 Sep 93 04:13:06 EDT

Contents:
  Re: Lockups. Where to look for the trouble. (Stephen Tweedie)
  Re: Status of the NET-2 port (Brandon S. Allbery)
  Re: Idea, donate a Pentium machine to Linus, anyone? (Brandon S. Allbery)
  Re: Status of the NET-2 port (Robert Smart)
  Re: gcc 2.4.5 generates bad code. (Alex Kowalenko)
  NetWare protocol stacks? (ben elliston)
  PL12 keymaps.  CTRL key Problems. (Scott D. Heavner)
  Re: Status of the NET-2 port (Donald J. Becker)
  Re: Linux Standards (was Re: Debian: a brief status report) (Mike Jagdis)
  Re: Linux Standards (was Re: Debian: a brief status report) (Mike Jagdis)
  Re: Linux consultant/company FTP site? (Anthony Lovell)
  [Q] Where is threads library ??? (Sohail M. Parekh)
  *NO* HELP w/ mprotect() ??? (Bernhard Strassl)
  Re: Status of the NET-2 port (Nate Williams)

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

From: sct@dcs.ed.ac.uk (Stephen Tweedie)
Subject: Re: Lockups. Where to look for the trouble.
Date: Thu, 9 Sep 1993 17:10:22 GMT

In article <26enit$1e7@smurf.sub.org>, urlichs@smurf.sub.org (Matthias Urlichs) writes:

> With normal use, I found xia and ext2 to be reasonably close in
> performance.  e2fsck could be faster, though.  ;-)

Being done - you should thank Theodore Ts'o for this when it comes.

Cheers,
 Stephen.
---
Stephen Tweedie <sct@dcs.ed.ac.uk>   (JANET: sct@uk.ac.ed.dcs)
Department of Computer Science, Edinburgh University, Scotland.

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Status of the NET-2 port
Date: Fri, 10 Sep 1993 00:35:03 GMT

In article <26nuql$1vd@nms.telepost.no> tor@spacetec.no writes:
>In article 747592922@pbhrzx.uni-paderborn.de, n62274@pbhrzx.uni-paderborn.de (Kl.Schaefers) writes:
>> yeah, you are honest, however. There are several other people working
>> on the so called net-2 stuff, but they grab bsd sources, and only
>> remove the header :-) 
>
>As far as I know Fred and the other guys working on the Linux net code release 2 are
>writing *every* piece of the kernel code by themselves.

Don't mind him --- the BSDers are busy spreading FUD about non-BSD *ixes, as
usual...

I've reached the point where I feel about the USL/Berkeley lawsuit the way I
did about the Microsoft/Apple one:  I sincerely hope they kill each other off
so the rest of us can have some peace and quiet for a change!

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Idea, donate a Pentium machine to Linus, anyone?
Date: Fri, 10 Sep 1993 00:38:25 GMT

In article <26n39a$odv@noc.usfca.edu> callis@noc.usfca.edu (Kim C. Callis) writes:
>I do realize that this is wistful thinking. Why would anyone in their
>right mind want to donate a dollar for something that is available all
>over the Internet for free? Nevermind that we are speaking of a mere
>fraction of what it cost to get Un*x from SCO or ATT... Sorry, I just
>thought that something would come out of such a statement.

It worked for Cygnus (gcc Solaris 2 port), didn't it?

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca

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

From: smart@squid.mel.dit.CSIRO.AU (Robert Smart)
Subject: Re: Status of the NET-2 port
Date: Fri, 10 Sep 93 00:21:32 GMT

In article <26epsv$1gc@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>Note that I'm not competing with the people who work on the Net-2 effort.
>We simply have different priorities; they want to keep BSD code out of the
>kernel because of possible copyright problems (the USL lawsuit isn't dead
>yet), I want to use working code instead of spending the (essentially
>duplicate) effort to recreate a fully-featured TCP/IP stack.

The USL lawsuit is very dead - they're only arguing about how much
compensation UC should get for being maligned. If Linux could
be organized internally so that it could easily track networking
developments from Berkeley it would be a big plus. For example
you would then get:

 1. Multicast.

 2. CLNP (OSI connectionless protocol and one of the contenders for
    the next generation of IP).

 3. All the experiments with contenders for the new IP are being done
    in a BSD context.

 4. Low level support for lots of networking devices: ethernet, token
    ring, FDDI, ISDN, ATM/BISDN, etc...

 5. Network debugging tools.

We don't want to have to duplicate all this work.

I realise that the (Linux-)NET-2 release is designed to fit into
the Linux kernel. I realise that integrating BSD stuff is a pain.
The final decision has to come from Linus (and I'll bet he doesn't
want to drop work done by people who are particularly friendly
to Linux). It would be really nice if the people who've worked on
Linux Net-2 would say to Linus "We've learnt a lot and won't be 
upset if you change again".

I fear that this has a nasty potential to fragment the Linux software
development. What worries me even more is that I could be forced to
leave Linux to run one of the BSD derivatives for practical reasons.

Bob Smart

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

From: alexk@swdev.research.otc.com.au (Alex Kowalenko)
Subject: Re: gcc 2.4.5 generates bad code.
Date: 10 Sep 1993 00:46:56 GMT

gcc (the compiler) might be stable, but the C++ compiler is not stable, and buggy.

I have had problems developing a non-trival project in g++, and on both
linux and sun4 platforms g++ generates buggy code.  I'm not even using fancy
features such as templates.

Using g++ as a better checking C compiler is fine, but watch out when you
start putting classes into the kernel.

Alex Kowalenko
Contractor
Telstra 
Syndey Australia

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

From: c9333291@sage.newcastle.edu.au (ben elliston)
Subject: NetWare protocol stacks?
Date: Fri, 10 Sep 1993 02:36:03 GMT

Is there any modularity to the way in which Linux handles its network protocol 
stacks?

(in other words, would it be realistic to write NetWare IPX protocl support   
into Linux?)  (Maybe it already exists!?)

Thanks.
Ben


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

From: sdh@fishmonger.nouucp (Scott D. Heavner)
Subject: PL12 keymaps.  CTRL key Problems.
Date: Fri, 10 Sep 1993 03:05:02 GMT
Reply-To: sdh@po.cwru.edu

        With the PL12 keymaps (US), I notice that the CTRL key doesn't
work in quite the same way:

        1) Ctrl-alt-F? used to switch VC's as well as X displays, now if
           I want to flip through all my screens, I have to let up on the
           ctrl for non X (no biggie, but is there an easy way to put this
           back?)
        2) After I switch off an X display, the first VC I switch to, I can't
           access.  No keys seem to work and I have to switch to another VC, 
           then back to type.  This doesn't happen all the time, it is not
           scroll lock either.
        3) I can't type a ^^ (ctrl-carrot).  On a US keyboard, this is 
           ctrl-shift-6.  It always used to work.  It works in X, so maybe
           it's a termcap problem, but I don't know how to fix it.

        Maybe this should go in c.o.l.h but this seems like a good place.  
These may be old problems.  I think I remember reading about them once,
but I don't remember.


                                        Scott
                                        sdh@Po.cwru.edu

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

From: becker@super.org (Donald J. Becker)
Subject: Re: Status of the NET-2 port
Date: Fri, 10 Sep 1993 03:32:46 GMT

In article <1993Sep10.002132.13102@mel.dit.csiro.au>,
Robert Smart <smart@squid.mel.dit.CSIRO.AU> wrote:
>In article <26epsv$1gc@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>>Note that I'm not competing with the people who work on the Net-2 effort.
>>We simply have different priorities; they want to keep BSD code out of the
>>kernel because of possible copyright problems (the USL lawsuit isn't dead
>>yet), I want to use working code instead of spending the (essentially
>>duplicate) effort to recreate a fully-featured TCP/IP stack.

This is what is meant by a "chilling effect", no one is willing to
pick up software that has a questionable legal status.  And if the suit
goes the wrong way, you "knew, or should have known, that the code was
the intellectual property of <X>, and sought {unfair advantage},{to
dilute it's competitive value to <X>},{appropriate the item for your
own gain}".  Then it starts looking like a criminal rather than
strictly civil matter.

>The USL lawsuit is very dead - they're only arguing about how much
>compensation UC should get for being maligned. If Linux could
>be organized internally so that it could easily track networking
>developments from Berkeley it would be a big plus. For example
>you would then get:
...
> 4. Low level support for lots of networking devices: ethernet, token
>    ring, FDDI, ISDN, ATM/BISDN, etc...

I don't that this would necessarily be true.

>I realise that the (Linux-)NET-2 release is designed to fit into
>the Linux kernel. I realise that integrating BSD stuff is a pain.
>The final decision has to come from Linus (and I'll bet he doesn't
>want to drop work done by people who are particularly friendly
>to Linux). It would be really nice if the people who've worked on
>Linux Net-2 would say to Linus "We've learnt a lot and won't be 
>upset if you change again".

I fall on both sides of this issue.  I've put a _lot_ of effort into
the low levels of Linux networking, as almost all of the device-level
code was written by me.  I would be very disappointed to see that
thrown away.  I think many users would be disappointed as well -- the
ethercard drivers have been very solid, and going to BSD code would
mean dropping support for most of the not-quite-clone ethercards that
many Linux users have.

On the other hand, I see the not yet released "Net-2e" development
picking up significant parts of the BSD code, and I can't help
wondering what their goals really are.  I see little difference
between having 1/3 of the code being from BSD with the existing
networking code changed to fit it (e.g.  changed from sk_buffs to
mbufs), and 9/10 of being from BSD with only a new Linux kernel interface.

Coupled with this is my frustration at the way new bugs were introduced
with "Net-2", and then "development team" abandoned the code with the
promise "everything will be fixed when we come out with yet another
completely new structure".  I feel hamstrung, because any improvement
or bug fix I make is destined to be swept away.  I've been working on
an IP "fast-path" (to recover the significant drop in performance
going to "Net-2") and constant-expected-time fragment reassembly based
on Clark's algorithm.  I'm not going to release these, or even keep
working on them, if they are only going to be in for a kernel
patchlevel or two.  The same holds true for changing the device drivers
to be real devices, allocating low-memory buffers for DMA, and
implementing promiscuous and multicast modes -- these are trivial but
not worth doing if they will be immediately discarded.

Even if the USL lawsuit didn't exist, I think it's a good thing that
we are doing a publically-available networking implementation separate
and distinct from BSD.  BSD has historic cruft, and most of the design
decisions date from a far different era and are ripe to be
revisited.  A notable example is the use of 'mbufs', a structure that
is at the core of BSD networking.  It was designed to hold packets as
a linked list of protocol headers and data pages.  This was a good
idea in the days of microcoded machines with complex addressing modes,
short pipelines, and very small memories.  On modern machines they are
slower than storing always storing the packet linearly.  (Would
someone care to comment on how many times 'mpullup()' occurs in BSD,
and how expensive it is?)

Reading back over this letter I'm beginning to wonder if it's a good
time to join Ross.



-- 

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

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

From: jaggy@purplet.demon.co.uk (Mike Jagdis)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: Fri, 3 Sep 1993 21:44:00 +0000

* In message <CCqI5H.GB5@boulder.parcplace.com>, Warner Losh said:

WL> Until shadow breaks old, non-recompiled programs in a fail-safe way,
WL> it is totally useless, as it potentially allows root access (put a '*'
WL> in the password field to find old, broken prorgams faster).

Nonononono. Shadow *does* lock out the password field of /etc/passwd. SLS 
might not but that's just SLS...

WL> >I'd agree, once someone actually claims that everything I want to be
WL> >running will work ok (and be secure) under the shadow stuff.

It's easy to fix. There are plenty of examples. I've released patches for 
xdm, xlock, many of the network daemons. If "distributors" can't manage to 
grep for crypt and copy code from half a dozen examples they should have 
immediately to hand you've more to worry about than you think :-).

  Is there a definitive list of things you want?

WL> I know that rshd needs something done to it to make it secure with
WL> shadow passwords.

That's about the only one of the net-2 programs I missed then. I didn't 
think rshd did it's own password checks. I thought it just invoked 
/bin/login if the incoming wasn't trusted according to hosts.equiv or 
rhosts. The fix is trivial if you have the source :-).

WL> We need to have /etc/rc files that will properly check file
WL> systems before mounting them.

I have this. In fact everyone should have it. Simple inspection of the 
bootutils should allow it to be added to just about any setup.

WL> We need to have some way of UPDATING a system w/o wiping the
WL> old configuration.

I have this.

WL> We need to at least set the damn time zone information from
WL> the install script.

I have this.

WL> Net-2 configuration needs to be a little smoother.

I have this too.

WL> I think there should be some way to configure in various packages a
WL> little more easily and elegantly than SLS does now.

And this. It's all in the Purple Distribution. I would put it on an archive 
site but I'm on the end of a modem connection on which I pay the bills. So 
far exactly two (2) people have shown an interest in it appearing on an 
archive site so it hardly seems worth my while.

WL> I think that there should be some set of statically linked
WL> utilities that will save your butt in case of fires.

Now that's where we disagree :-). Use a boot disk. Even if you let LILO boot 
a hard disk kernel but point it at a root floppy with root=/dev/fd0. Get in 
the habit of thinking three times before doing *anything* as root. If you 
have to recover it treat it as a learning experience. Make sure it has 
impact :-).

                                Mike  
 

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

From: jaggy@purplet.demon.co.uk (Mike Jagdis)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: Fri, 3 Sep 1993 21:50:00 +0000

* In message <1993Sep2.223434.28575@mnemosyne.cs.du.edu>, Zack Evans said:

ZE> jpm>If you put BSD manpages in with other man pages, your man pages wont
ZE> jpm>look right when formatted.

ZE> I noticed that this morning :( Is there anything I can do
ZE> about it? Does anyone
ZE> have a super duper BSD to Linux man page conversion perl
ZE> script?

If you are using groff then you'll find that -mandoc works for more things 
than -man.

man and xman generally invoke 'nroff -man'. With groff nroff is a shell 
script. I changed mine to trap a -man argument and replace it with a -mandoc 
before calling groff itself. It's that simple :-).

                                Mike  
 

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

From: alovell@kerberos.demon.co.uk (Anthony Lovell)
Subject: Re: Linux consultant/company FTP site?
Date: Sat, 4 Sep 1993 19:37:37 +0000

loginov@sleepy.cc.utexas.edu (Alexey Loginov) writes:
: 
: Linux is a great operating system.  Linux is simply faster, half the
: size, and less buggy than the ATT sysV unix.  It is a real unix as
: opposed to many of the PC based attempts.  So why hasn't Byte, or PC
: magazine done a big story on it -- spread the news.  Who decides what
: they review anyway?
: 

The Advertisers 

---

anthony

==============================================================================
alovell@kerberos.demon.co.uk          |   If at first you don't succeed
                                      |
alovell@cix.compulink.co.uk           |   Get a Bigger Hammer
==============================================================================

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

From: sohail@trixie (Sohail M. Parekh)
Subject: [Q] Where is threads library ???
Reply-To: sohail@rhonda.jsc.nasa.gov
Date: Fri, 10 Sep 1993 05:26:58 GMT

I know someone was working on a threads lib for linux sometime back. Does 
anybody know if its complete yet ? Is their any other support available for
threads (and/or POSIX threads 1003.4a).

Sincerely,


Sohail


--
     Sohail M. Parekh                Grumman  Data Systems
     sohail@rhonda.jsc.nasa.gov      12000 Aerospace Ave. 
     (713) 483-5912                  Houston, TX 77034

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

From: bernhard@trick.ani.univie.ac.at (Bernhard Strassl)
Subject: *NO* HELP w/ mprotect() ???
Date: 10 Sep 1993 07:14:06 GMT


Recently I saw two postings from people that asked for the
implementation of the mprotect() system call (I include the
SUN man page below).

I also need this call to get the 'Texas object storage' running
on my Linux PC at home (it seems to work fine on our SUNs here)
and I waited for an answer of some Linux guru.

But there was absolutely no response to these requests (at least
on our news server) so I call for help again:

Please can anyone who is familar with the implementation of the
Linux virtual memory management post/mail me the source for
such a function?
I had a look at the kernel mmap() sources (I run a very old 0.99pl6
version of Linux which has this function only partially working) and
I think it will not be much work for a person who knows how the
memory tables are organized. (I would have to spend too much time to 
find it out by myself.)

Many thanks in advance!

-bernhard

===============================================================
The Xm++ / CommonInteract Project
Vienna User Interface Group
Bernhard Strassl              University of Vienna
xmplus@ani.univie.ac.at       Dpt. for Applied Computer Science
                              and Information Systems
===============================================================



MPROTECT(2)               SYSTEM CALLS                MPROTECT(2)

NAME
     mprotect - set protection of memory mapping

SYNOPSIS
     #include <sys/mman.h>

     mprotect(addr, len, prot)
     caddr_t addr;
     int len, prot;

DESCRIPTION
     mprotect() changes the access protections  on  the  mappings
     specified  by the range [addr, addr + len) to be that speci-
     fied by prot.  Legitimate values for prot are  the  same  as
     those permitted for mmap(2).

RETURN VALUES
     mprotect() returns:

     0    on success.
     -1   on failure and sets errno to indicate the error.

ERRORS
     EACCES         prot specifies a  protection  which  violates
                    the  access permission the process has to the
                    underlying memory object.

     EINVAL         addr is not a multiple of the  page  size  as
                    returned by getpagesize(2).

     ENOMEM         Addresses in the range [addr, addr + len) are
                    invalid  for  the address space of a process,
                    or specify one or more pages  which  are  not
                    mapped.

     When mprotect() fails for reasons  other  than  EINVAL,  the
     protections  on some of the pages in the range [addr, addr +
     len) will have been changed.  If the error  occurs  on  some
     page  at  address  addr2,  then the protections of all whole
     pages in the range [addr, addr2) have been modified.

SEE ALSO
     getpagesize(2), mmap(2)

Sun Release 4.1   Last change: 21 January 1990                  1


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

From: nate@bsd.coe.montana.edu (Nate Williams)
Subject: Re: Status of the NET-2 port
Date: 10 Sep 1993 07:19:17 GMT

In article <1993Sep10.033246.28836@super.org>,
Donald J. Becker <becker@super.org> wrote:
>BSD has historic cruft, and most of the design
>decisions date from a far different era and are ripe to be
>revisited.  

Berkeley networking code has been re-written multiple times, and
is now considered 'the standard' upon all other networking code
is based upon. 

>A notable example is the use of 'mbufs', a structure that
>is at the core of BSD networking.  It was designed to hold packets as
>a linked list of protocol headers and data pages.  This was a good
>idea in the days of microcoded machines with complex addressing modes,
>short pipelines, and very small memories.  On modern machines they are
>slower than storing always storing the packet linearly.  (Would
>someone care to comment on how many times 'mpullup()' occurs in BSD,
>and how expensive it is?)

Hmm, that may be the case, but I'll bet you dollars to donuts that it'll
be awhile before the Linux networking code (not BSD Net/2 code) can
saturate an ethernet.  Not bad for *slow* code, is it?

I recommend taking a bit of the Linux attitude which seems to have been
completely lost in the BSD groups.  I would rather have something that
works good-enough instead of something that is perfect when having
something perfect is going to take an un-known amount of time, and
something that is good-enough is available today (or soon).

A good example of this in Linux was the original shared libraries. 
People were able to use the (non-optimal) shared library packages
because they needed them.  Because they were non-optimal, they were
modified (which caused the users grief, but you didn't *have* to
upgrade).  Today, they are fairly well done.

Now, in the BSD camp (of which I am acutely aware of), we have been
arguing about shared libraries for a long time, when versions similar to
the old Linux shared libraries, and even a version similar to the
current versions have been available for a long time.  Instead of using
what we have (or even implementing new versions), most folks have spent
time arguing about why the Linux are not optimal, all the while we
really could be using the non-optimal ones until something better came
along.

Sigh......


Nate

-- 
nate@bsd.coe.montana.edu     |  In the middle of it ........ again. 
nate@cs.montana.edu          |  Running/supporting one of many freely available 
work #: (406) 994-4836       |  Operating Systems for [34]86 machines.
home #: (406) 586-0579       |  (based on Net/2, name changes all the time :-)

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


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