Subject: Linux-Development Digest #12
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, 10 Aug 94 16:13:15 EDT

Linux-Development Digest #12, Volume #2          Wed, 10 Aug 94 16:13:15 EDT

Contents:
  Registrar for major device #s? (David Hinds)
  Suggestion: Lets have a standard for numeric uid/gids (Torben Fjerdingstad)
  Re: Can't compile/build kernel 1.1-36 (Eric Paul)
  Program that demonstrates a problem with getwd (David Fox)
  Re: Few simple questions... (Bjorn Ekwall)
  Re: Suggestion: Lets have a standard for numeric uid/gids (Lutz Jaenicke)
  Changing to 1024x768 in X? (Ron  Olson)
  Status of MGR under Linux? (Dances With Geeks)
  Re: iso9660 file system post v1.1.36 (Rob Janssen)
  Re: kernel 1.1.41 breaks lilo on floppy (Mark Lord)
  Re: IO ports (Kjetil Torgrim Homme)
  Re: THANKS. (Kjetil Torgrim Homme)
  SVNet meeting August 17: Bill Jolitz - 386BSD 1.0 Design and features (Paul Fronberg [CONTRACTOR])
  Re: memory segmentation problem (Wallace Roberts)

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

From: dhinds@allegro.stanford.edu (David Hinds)
Subject: Registrar for major device #s?
Date: 9 Aug 1994 05:35:48 GMT

Does anyone know who I should talk to about "registering" a major
device # for a Linux device driver?

        -- David Hinds
           dhinds@allegro.stanford.edu

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

From: tfj@olivia.ping.dk (Torben Fjerdingstad)
Subject: Suggestion: Lets have a standard for numeric uid/gids
Date: 9 Aug 1994 21:56:20 +0200

Today I compiled at-2.7a on my fastest machine.
Then I nfs'et to it from another machine and did an 'make install'.

It did not work because the numeric user- and group id's are compiled
into the programs, and they do not agree on the two machines.
(at: Operation not permitted, cannot cd to /var/spool/atspool, or
something like that).

On the fast machine, the group daemon has gid 2
On the other one, it is gid 12.

Is any of these id's standard for the group daemon?

I wish there were standards for root,bin,sys,wheel,mail,daemon,
sync,news,uucp,adm, (or admin?)... and so on.

Earlier i lost my hair trying to make the mail programs share
/usr/spool/mail. It was also because some of the mail programs
from a binary linux distribution had a built-in check for the
numerid id's. They expected the group mail to have id 12, while
they were 6 or 7 on my system.

Wigs are highly expensive nowadays.

I will contribute to this by suggesting root to be user:gid 0:0
instead of 0:1, which is what it seems to be on several distributions.

-- 
torben fjerdingstad                     | linux-1.1.42     (God's Own OS).
tfj@olivia.ping.dk  /  234/85@fidonet   |

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

From: wizz@phantom.com (Eric Paul)
Subject: Re: Can't compile/build kernel 1.1-36
Date: 10 Aug 1994 14:24:00 GMT

Sam Gentile (owlmed@mv.mv.com) wrote:
: I obtained the 1.1.35 source and unpacked that. I then patched with the 
: 1.1.36 patch and started the traditional build process. It went a long ways
: and then:
: /usr/src/linux/include/linux/timer.h: In function 'init_timer':
: In file included from psaux.c:28:
: /usr/src/linux/include/linux/timer.h:85:  'NULL' undeclared (first use 
: this function)
: make[2]: *** [psaux.o] Error 1
: make[2]: Leaving directory '/usr/src/linux/drivers/char'

I have had teh same problem.  I FTP'd Linux-1.1.35 from Funet, FTP'd the 
patch, untarred linux in my /usr/src dir, unziped the patch, and typed:
 
patch -p0 < patch36

I had the same error message when I compiled.  I have tried every patch 
from 36 up to 41 and none of them have compiled.  I am running gcc 2.5.8 
on a HP Vectra 486DX2-66 with a 450 meg IDE drive if this matters.  If 
you need any other specs, drop me E-mail, I'll send them.

Eric

--
____________________________________________________________________________
|Eric Paul       |The world can't end |My Surface is Myself Under Which    |
|wizz@phantom.com|today, it's tomorrow|To Witness Youth is Burried.  Roots?|
|finger for PGP  |in Australia!       |Everybody has Roots. --WCW          |
|Lynx/Mosaic:    |http://www.phantom.com/~wizz/home.html                   |
============================================================================

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

From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Program that demonstrates a problem with getwd
Date: 09 Aug 1994 17:09:08 GMT

/* This program demonstrates a problem which arose compiling STk
   for Linux.  The code didn't use the PATH_MAX variable, but
   instead defined MAX_PATH_LEGNTH to be 256 and used a buffer
   of that size to pass to getwd.  This caused a seg fault, for
   reasons you can see by running this program.  If getwd is
   behaving correctly, the manual page should mention the constant
   PATH_MAX as the minimum safe length of the buffer argument. */

#include <stdlib.h>

#define MAX_PATH_LENGTH  256

char buf[MAX_PATH_LENGTH];
char after[1024];

main(int ac, char *av[])
{
  int i;
  for (i = 0; i < 1024; i++) after[i] = 0;
  getwd(&buf[0]);

  /* This shows that elements of after have been changed by the
     call to getwd.  Of course, there is no way for getwd to
     know the size of buf, but the manual page doesn't mention
     that it might write over memory beyond the amount necessary
     to hold the path name of the current working directory. */

  for (i = 0; i < 1024; i++)
    if (after[i] != 0) printf("after[%d] = %d\n", i, after[i]);
}
--
David Fox                                               xoF divaD
NYU Media Research Lab                     baL hcraeseR aideM UYN

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Few simple questions...
Date: 9 Aug 94 22:58:12 GMT

Eric Youngdale (ericy@cais2.cais.com) wrote:
 > In article <1154@blox.se>, Bjorn Ekwall <bj0rn@blox.se> wrote:
 > >Simo Varis (svaris@cs.joensuu.fi) wrote:
 > >[...]
 > > > Well, it really doesn't matter what's in my
 > > > kernel, if it doesn't use memory, but this does,
 > > > I'm afraid. So how could I avoid this? I watched
 > > > what's going in, and for my surprise, also
 > > > 3c509, de600, de620, 3c501 and plip got compiled.
 > > > Why? Also at least bios32 was compiled, and it's
 > > > totally useless for me, VLB-user. Maybe it doesn't
 > > > take up any memory...
 > >
 > >These drivers are mentioned in "linux/drivers/net/MODULES", which
 > >means that they will be compiled as loadable modules unless you
 > >enabled them in "make config".

 >      This is true, but I am concerned about the time that kernel 
 > compilation is beginning to take.  I do not have any one of these boards, 
 > and I only compile in network support for slip, so any time spent 
 > preparing these modules is a waste of time.  I would like to see one of 
 > two things done.  One possibility would be to change the configuration 
 > options to a Yes/No/Module so that the user can select which modules will 
 > be built.  The second possibility would be something whereby the user
 > types:

 >      make MODULES=true zImage

 > to build the kernel and the modules.  Both suggestions could be 
 > implemented, actually.  The amount of time spent might be small now, but 
 > in the future as more and more things become modularized it will become 
 > more important.

I quite agree, but there are still some problems to be solved:

As more and more drivers get "modularised", we will also see
modules depending upon other modules, in a "stacked" fashion.
This is most prevalent among the net drivers, but will also
happen in other areas, I'm sure.
David Hinds' latest PCMCIA support is a prime example of this.

The result from a "make config" ends up in <linux/autoconfig.h> as
        #define CONFIG_SOMETHING 1
to be used by gcc, and in ".config" as
        CONFIG_SOMETHING = CONFIG_SOMETHING
to be used by "make".

The tests made are of the form: "#ifdef CONFIG_SOMETHING"
which might include references to symbols from "submodules".
These "submodules" could either be included in the kernel due to
answering "y" to Configure, _or_ be compiled as loadable modules.

Now, if the submodule is a loadable module, there will be unresolved
references if "CONFIG_SOMETHING" was enabled.  If it wasn't enabled,
there might be some missing symbols in "kernel/ksyms.c" when you
use "insmod".

Either way, the current scheme won't work flawlessly...

We need something that supports interdependencies for configuring
loadable modules as well as modules compiled into the "base" kernel.
Perhaps ternary tests instead of the current binary tests have to be
enforced (?) in the sources and the Makefiles.  (There are a _lot_ of them...)

The kernel (with the latest versions of "insmod") already supports
the concept of "stacked" modules, but there is a lot of thinking
to be done before the support could be said to be sufficient...

There is some work going on in this direction, reported and discussed
from time to time in the KERNEL channel, but its not obvious how the
final solution should look (at least it isn't obvious to me :-) ).

Anyway, the "dirty" solution right now is to create an empty
"linux/drivers/net/MODULES", as this will inhibit the compilation
of net drivers as loadable modules.

The _real_ soultion won't be ready before v1.2.0 I'm afraid...
Or perhaps the EY Consortium will give us a pleasant surprise? :-)

Bjorn

 > -Eric

 > -- 
 > "The woods are lovely, dark and deep.  But I have promises to keep,
 > And lines to code before I sleep, And lines to code before I sleep."

What's "sleep"?  :-) :-)

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

From: jaenicke@emserver.ee.TU-Berlin.DE (Lutz Jaenicke)
Subject: Re: Suggestion: Lets have a standard for numeric uid/gids
Date: 10 Aug 1994 15:14:59 GMT

In article <32a4ih$36v@trane.uninett.no> hta@uninett.no (Harald T. Alvestrand) writes:
> ...
>I think this is a shortcoming of your local environment.
>If you are doing NFS mounts without some means of synchronizing your
>pw/group files, you are in BIG TROUBLE.
>

You are absolutely right!
I try to assure this by using NIS and it works fine for my normal
users. Some of the standard settings however make problems.
For example the group "mail":
Apollo DN10k, Domain OS 10.3:
        mail::6:bin
HP 700, HP-UX 9.01:
        mail::6:root
The group "mail" therefore is gid "6". (Sorry, no other Unix-Systems
available for comparison).
Linux Slackware 2.0:
        mail::12:mail
        disk::6:root,adm
... and my motivation to rework group "disk" and change "mail" to gid "6"
is not large, as I don't know which side effects this will trigger.

Consequently:
ls -l ~jaenicke (HP-UX):
drwx------   2 jaenicke mail        2048 Aug 10 16:03 Mail
ls -l ~jaenicke (Linux, mounted from HP-UX)
drwx------   2 jaenicke disk         2048 Aug 10 16:03 Mail/

A _good_ concept to choose the standard uids and gids with a look at
interoperation with other Unix- or Unix-Like systems would therefore
be very much appreciated.

        Lutz

PS. Cross mounting the mail spool dir is hence not possible, but that
would also imply to solve the nfs/lock problem and is not the problem
discussed here.

-- 
Lutz Jaenicke                        jaenicke@emserver.ee.TU-Berlin.DE 
Institut fuer Elektrische Maschinen  http://emlserv.ee.TU-Berlin.DE/~jaenicke/
Technische Universitaet Berlin       Tel. +49 30 314-24552
Einsteinufer 11, D-10587 Berlin      Fax. +49 30 314-21133 

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

From: rqo3606@acf3.nyu.edu (Ron  Olson)
Subject: Changing to 1024x768 in X?
Date: 10 Aug 1994 03:46:12 GMT

Hi all...

I am currently running X using the SVGA driver that was patched
with the Mach64 driver. I am able to run in 800x600, but I'm
afraid that's still too big for me. I want to run in 1024x768, but
all the changes I make to the Xconfig file and it still defaults
to 800x600, even after putting it at the top of my ModeDB section.

Might anyone know how this is done?

Thanks a lot for any info

Ron


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

From: lilo@slip-10-13.ots.utexas.edu (Dances With Geeks)
Subject: Status of MGR under Linux?
Date: 10 Aug 1994 00:12:48 GMT

I'm wondering if anyone can help me find out if there is current development
activity going on for MGR.  I have version 62 which appears to have come out
in February of this year and I am wondering if there is someplace where I
can ask MGR questions and find out when the next release is scheduled.

Version 62 runs *fairly* well under Linux, but there appear to be some
problems with switching from the MGR vt to another vt.  I have other
questions as well....

Thanks in advance for any help you can provide!  :)


lilo

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: iso9660 file system post v1.1.36
Reply-To: pe1chl@rabo.nl
Date: Tue, 9 Aug 1994 21:51:16 GMT

In <ALLAN.94Aug8160942@europa.mct.uucp> allan@mct.uucp (Allan Clearwaters) writes:

>Has anyone else noticed that the iso9660 filesystem is hosed in
>v1.1.41 (I compiled this version of the kernel and it hangs trying to
>mount my cdrom).  My cd is a Sony cdu31a - it worked up to patch level
>36 - I haven't tried the levels between this and 41.  Is there some
>explanation for this??

It works fine on my SCSI CD-ROM.
But when you read the mods and/or the announcement, you see that changes
have been made without extensive testing.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: kernel 1.1.41 breaks lilo on floppy
Date: 10 Aug 1994 15:19:28 GMT

In article <1994Aug10.090236.19425@roxi.rz.fht-mannheim.de> andre@borneo.dkfz-heidelberg.de writes:
>as with kernel version 1.1.41 lilo can't write the bootsector af a mounted
>floppy with a minix filesystem.
>
>  andre schroeter 

Same problem noted here as well.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Subject: Re: IO ports
Date: 10 Aug 1994 00:31:46 GMT

+--- Riku Saikkonen:
| gcc (gcc 2.4.5, libc 4.4.4, kernel 1.1.41) reported:
| Undefined symbol ___outb referenced from text segment
| Undefined symbol ___inb referenced from text segment

I was bitten by this, too.

Easy fix: Compile with optimize on.
Real fix: Change <asm/io.h> so that inb and friends are declared
"static inline" instead of "extern inline".


Kjetil T.

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

From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Subject: Re: THANKS.
Date: 10 Aug 1994 00:34:29 GMT

+--- Wallace Roberts:
| ok, what's his snail-mail address? let's start sending him
| donations.

If you finger torvalds@linux.helsinki.fi, you'll be told:

                Linus Torvalds (Linus.Torvalds@Helsinki.FI)
                Kalevankatu 55 B 37
                00180 Helsinki
                FINLAND

Cheers!


Kjetil T.

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

From: paulf@panic.Eng.Sun.COM (Paul Fronberg [CONTRACTOR])
Crossposted-To: comp.unix.bsd,comp.windows.x.i386unix,comp.os.386bsd.questions,comp.os.386bsd.development,comp.os.386bsd.announce,comp.os.386bsd.misc,comp.os.linux.misc,comp.unix.questions,comp.unix.internals,comp.unix.programmer,comp.unix.sysv386,comp.unix.solaris,ba.internet
Subject: SVNet meeting August 17: Bill Jolitz - 386BSD 1.0 Design and features
Date: 9 Aug 1994 17:44:00 -0700


SVNet Meeting, Wednesday Aug 17, 1994 7:30pm Mountain View


                            386BSD Release 1.0:
           New Innovations in Kernel Design and Architecture

                               William F. Jolitz
                                    TeleMuse


WHAT:  386BSD, R1.0 - Kernel Design and Features


   "Has 386BSD made any progress towards these new design goals  
   --  by  attempting  to create New Innovations in Kernel Design 
   and Architecture and meet these challenges head on -- or has it 
   fallen  into the fatal  stagnation  of so many other Unix projects 
   which held out great promise but then grew stale and bloated over  time
   for a lack of new ideas?"  That is the question posed by Bill Jolitz
   which he will answer in this presentation at SVNet.  

        In this brief talk, some of the new kernel design  work
   contained in 386BSD Release 1.0 will be discussed along with
   some additional new items of special  interest  (e.g.  secu-
   rity).  In  particular,  our speaker will  focus on answering these
   design challenges posed two years ago, to wit:

   *    How do we better adapt a Unix-like system to the PC  to
        encourage usability and plug-and-play?

   *    How do we  avoid  file  I/O  and  network  transmission
        bottlenecks  to  allow real multimedia and gigabit net-
        working?

   *    How do we achieve multiprocessing in the 1990's?

   *    How do we  allow  people  to  do  independent  work  on
        filesystems  and  other  subsystems  independent of the
        basic kernel?

   He will then outline in brief the next series of design
   goals and work-in-progress to be included in future versions
   of 386BSD.

   This talk is intended for people interested in new kernel 
   and operating systems design. 
 
     *** 386BSD Reference CD Demonstration System ***
 
   For those interested in viewing what is contained on
   the Dr. Dobbs Journal 386BSD Reference CD, a demonstration
   system will be made available.  This system contains the com-
   plete operational 386BSD Release 1.0 system as well as the
   complete and hyperlinked select kernel source annotations,
   book excerpts from the pending book on 386BSD Release 1.0
   entitled 386BSD From the Inside-Out, the complete Porting
   UNIX to the 386 386BSD article series which appeared in Dr.
   Dobbs Journal, and a number of other new 386BSD Release 1.0
   writings which have never before appeared in print.
 
WHO:  Bill Jolitz, Telemuse
 
   Bill Jolitz began the 386BSD Project in 1989 as a way
   of encouraging innovation in operating systems design on an
   inexpensive PC platform. He has worked on operating system
   design for BSD and commercial Unix systems since the 1970's
   (including 2.8 BSD, where he was the Principle Designer).
   Bill is also a popular published author who has written
   extensively on new kernel and system design, networking,
   security, and other areas. He currently works as an indus-
   try consultant on a wide range of projects, most recently
   projects in clustering, security, telecommunications, and
   gigabit networking.

WHEN:  Wednesday, August 17, 1994 at 7:30pm

 
WHERE:  Sun Microsystems Bldg 6, 2750 Coast Avenue, Mountain View
    Coast Ave appears to be just a driveway next to Bldg 5 on Garcia Ave 
    between Amphitheatre Pkwy and San Antonio, so don't get confused.


For more information, please call either Paul Fronberg at (415) 366-6403 
        or Ralph Barker at (408) 559-6202.

     SVNet is a UNIX  and open systems user group supported 
                 by member dues and donations.



             SVNet Meetings are FREE and OPEN TO THE PUBLIC.
                  UNIX is a registered trademark X/Open 




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

From: robertsw@agcs.com (Wallace Roberts)
Subject: Re: memory segmentation problem
Date: 10 Aug 1994 12:19:06 -0700

ehippo@aol.com (EHippo) writes:

        [ ...snip happens... ]

>  memset(p, size);

for starters, memset takes 3 parameters, not 2.  i think you meant:

        memset( p, '\0', size );

>The program compiles correctly, and runs "as is" on another system, so I
>thought I'd ask here.  I hope this is the right newsgroup.

never assume that just because a program runs "as is" on another system,
the program is fine, especially when that other system allows user
programs to scribble anywhere in memory.  i once ported a successful
commercial messy-dog app to unix; you should've *seen* the SIGSEGVs.
ugh.

gears,
ye wilde ryder
--
robertsw@agcs.com | 86 cr250 "dirt devil"    83 v65 magna "animal"
"E Pluribus Unix" | 79 it250 "mr. reliable"  84 650 nighthawk ">> for sale <<"
"Criminals (especially tyrants) prefer unarmed victims."
"Ignorance can be cured; stupidity, on the other hand, is hereditary."

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


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