Subject: Linux-Development Digest #13
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:     Thu, 11 Aug 94 01:13:04 EDT

Linux-Development Digest #13, Volume #2          Thu, 11 Aug 94 01:13:04 EDT

Contents:
  Re: Suggestion: Lets have a standard for numeric uid/gids (Kjetil Torgrim Homme)
  Re: Pentium version of gcc? (Lee J. Silverman)
  Re: Registrar for major device #s? (Matthias Urlichs)
  Re : g++ 2.6.0 kernel compiler problem (Dominique Delamarre)
  Re: g++ 2.6.0 kernel compiler problem (Amit Joshi)
  Re: How to do inb from a user program? (N J Andrews)
  More IO ports :) (Riku Saikkonen)
  Re: Anyone want T1 access from Linux? (Ed Boston)
  Re: Does anyone use SONY CDU-535 CD-ROM anymore? (Hans de Hartog)
  Re: Anyone want T1 access from Linux? (United Data Corporation)
  Re: g++ 2.6.0 kernel compiler problem (Linus Torvalds)
  Problems compiling dosemu 0.53.11 (Kim Enkovaara)
  using direct video-access in textmode (Maarten Boekhold (Who'd you expect??))
  Re: SLIP routing problems (Brian Watts)
  How to invalidate buffers? (Heiko Schlittermann)
  Will check_*_media_change() never be called? (Heiko Schlittermann)
  Re: Problems compiling dosemu 0.53.11 (Thorsten Meinecke)

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

From: kjetilho@ifi.uio.no (Kjetil Torgrim Homme)
Crossposted-To: comp.os.linux.admin
Subject: Re: Suggestion: Lets have a standard for numeric uid/gids
Date: 10 Aug 1994 00:41:59 GMT

+--- Torben Fjerdingstad:
| 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).

I agree, it would be nice to have a standard set of uid's or gid's. It
seems like a lot of them have been chosen at a whim (no offence!).
E.g., I don't like Slackware's calling group 0 for "root" instead of
the more common "wheel".

Perhaps this could be an extension to the FSSTND?

However, a program should _never_ hardcode a uid or gid, they should
_always_ look them up with getpwent and friends.


Kjetil T.

[ Followup-To: comp.os.linux.admin ]

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

From: lee@netspace.students.brown.edu (Lee J. Silverman)
Subject: Re: Pentium version of gcc?
Date: 08 Aug 1994 21:04:59 GMT


        There is an "optimized" version of gcc 2.4.0 available at
ftp.intel.com.  It looks like some employee or tech-nut hacked around
with it to improve the optimizations for Pentiums, as well as
everything else in the x86 family. 

        As anyone who's compiled GCC knows, it takes a while to get
the damn thing compiled.  After spending close to an hour building the
thing, I tried to compile Kernel version 1.0.8 with it.  No dice; it
seemed to die on some of the inlined assember.  (Might be my bad,
though; gcc should have known about gasm, but it might not have.)
Then I tried recompiling emacs (figuring that I might as well optimize
the big resource hogs) but that didn't work either (don't remember
why).  So I ditched the distribution.  All told, I wasted about 4
hours installing and testing it out.  Fun, but not very productive.

        Has anyone gotten anything to compile with this version of
gcc?  If so, has it proven to be faster?  Does anyone out there (intel
readers?!?!) know if someone's working on the optimizations in 2.6.0?

Just some thoughts...

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: Lee_Silverman@brown.edu
Phish-Net Archivist: phish-archives@phish.net
"Nonsense - you only say it's impossible because nobody's ever done it."

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Registrar for major device #s?
Date: 10 Aug 1994 07:15:59 +0200

In comp.os.linux.development, article <3274jk$6mi@nntp2.stanford.edu>,
  dhinds@allegro.stanford.edu (David Hinds) writes:
> Does anyone know who I should talk to about "registering" a major
> device # for a Linux device driver?

I'd like this requirement to Just Go Away.

With the new release of the MAKEDEV script, there's not much reason for
most drivers to use a fixed major number; MAKEDEV will find out the correct
number from /proc/devices.
register_{chr,blk}dev() just has to look for an empty slot if it's passed a
zero (and return the allocated number so you can unregister yourself).

--- /pub/src/linux-1.1/fs/devices.c     Tue Aug  9 18:05:55 1994
+++ fs/devices.c        Wed Aug 10 07:10:59 1994
@@ -64,6 +91,20 @@
 
 int register_chrdev(unsigned int major, const char * name, struct file_operations *fops)
 {
+       if (major == 0) {
+               for (major = MAX_CHRDEV-1; major > 0; major--) {
+                       if (chrdevs[major].fops == fops)
+                               return major;
+               }
+               for (major = MAX_CHRDEV-1; major > 0; major--) {
+                       if (chrdevs[major].fops == NULL) {
+                               chrdevs[major].name = name;
+                               chrdevs[major].fops = fops;
+                               return major;
+                       }
+               }
+               return -EBUSY;
+       }
        if (major >= MAX_CHRDEV)
                return -EINVAL;
        if (chrdevs[major].fops && chrdevs[major].fops != fops)
@@ -75,6 +116,20 @@
 
 int register_blkdev(unsigned int major, const char * name, struct file_operations *fops)
 {
+       if (major == 0) {
+               for (major = MAX_BLKDEV-1; major > 0; major--) {
+                       if (blkdevs[major].fops == fops)
+                               return major;
+               }
+               for (major = MAX_BLKDEV-1; major > 0; major--) {
+                       if (blkdevs[major].fops == NULL) {
+                               blkdevs[major].name = name;
+                               blkdevs[major].fops = fops;
+                               return major;
+                       }
+               }
+               return -EBUSY;
+       }
        if (major >= MAX_BLKDEV)
                return -EINVAL;
        if (blkdevs[major].fops && blkdevs[major].fops != fops)
-- 
Hackers do it in the software.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: delamar@amboise.univ-orleans.fr (Dominique Delamarre)
Subject: Re : g++ 2.6.0 kernel compiler problem
Date: 10 Aug 1994 07:05:13 GMT

Hi all,

I have a little proble compiling linux kernel with gcc-2.6.0 with option -O3
that I have tried recentely.

The symptom (not litterally, but complete): 
   internal compiler error got signal 6 in file dcache.c

Has anyone an Idea, has it already been reported?

   Dominique



=======================================================================

  e_mail: delamar@univ-orleans.fr              Dominique  Delamarre
                                                      LIFO
                                               Universite d'Orleans
                                                    B.P. 6759
  Tel: (+33) 38 41 72 67                       F-45067 Orleans Cedex 2
  Fax: (+33) 38 41 71 37                               FRANCE

=======================================================================



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

From: amitj@ruble.tts.telerate.com (Amit Joshi)
Subject: Re: g++ 2.6.0 kernel compiler problem
Date: 10 Aug 1994 15:57:57 GMT

Beeblebrox (M.S.Ashton@dcs.warwick.ac.uk) wrote:
: marc@offline.be (Marc Duponcheel) writes:

: >Hello linux developers,

: >Anyone has tried to use 2.6.0 for kernel builing ?

: Yes, works fine.
: ___
: M.S.Ashton@dcs.warwick.ac.uk              M.S.Ashton@csv.warwick.ac.uk
: C++ consultant and emacs support.         Mail me if you have any problems.

I have problems compiling the kernel with gcc 2.6.0 if change the option
"-O2" to "-On" where n>2 (eg. "-O8"). The file fs/dcache.c fails with 
cc1 getting signal 6. I have reported the error to gcc-bugs. Otherwise
version 1.1.38 failed because of errors in pas16.c and seagate.c (both are
fixed in later patches).

--
Amit Joshi
amitj@tts.telerate.com          -> Preferred address
amitj@telerate.com
"There's a pleasure in being mad ... which none but madmen know!" - St. Dryden


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

From: N J Andrews <N.J.Andrews@durham.ac.uk>
Subject: Re: How to do inb from a user program?
Date: 10 Aug 1994 16:00:45 GMT

In article <31pos2$ftc@ankh.iia.org>, rothr@iia.org (Richard Roth) writes:
|> Thomas E Zerucha (zerucha@shell.portal.com) wrote:
|> : How can I access the IO space (using inb and outb instructions) outside
|> : the kernel?  I know it is probably documented somewhere, but I was wondering
|> : if anyone knows this off the top of their head
|> : ---
|> : zerucha@shell.portal.com - main email address
|> 
|> Check out the ioperm(port, count, ???) function call. I forgot to doc the 
|> two params but (port, 1, 1) will allow inb()/outb() to that port.
|> 
|> The headers you need are: 
|>      fcntl.h (maybe)
|>      asm/io.h
|>      linux/hdreg.h   (maybe)
|>      linux/fs.h (maybe)
|> 
|> Sorry for the maybe's but this is from a code segment.
|> 

It's in the manual pages. I know this for a fact ( at least for Slackware 1.2 )
because I was looking at this call last week.

Hope you can find it on your system.

Cheers,


-- 
Nigel J. Andrews
Astronomical Instrumentation Group
Physics Department
University of Durham

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

Subject: More IO ports :)
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Wed, 10 Aug 94 18:52:00 +0200

Ok, I got the program compiled by using the -O2 option, as many of you
suggested.

But now it complains of a segmentation fault. It seems that the ioperm()
routine returns -1 (marking an error, as per the man page) but does not
set errno (perror reports 'Unknown error') as it should.

Then inb()/outb() fails with a seg fault, probably because we're not
supposed to access the ports without calling ioperm() first.

I tried it as root, as setuid root, and as a normal user - always the
seg fault. I also tried a couple of different ioperm() commands, namely:
ioperm(0x378,3,1);
ioperm(0x379,1,1);ioperm(0x37a,1,1);
ioperm(0x379,1,-1);ioperm(0x37a,1,-1);

Nothing worked...

I'm not sure about the last parameter to ioperm() though. Earlier
someone said that ioperm(port,1,1); should reserve that port; the second
parameter is the number of consecutive ports to reserve, the third,
according to the manpage, is 'turn_on' and sets the 'port access
permission bits'. Anyone have the syntax of that parameter?

E-mail or post, I will post a summary with some sample code if/when I
get this to work...

-=- Rjs -=- riku.saikkonen@compart.fi - IRC: Rjs
"In every meal, and in every word and song they found delight. The very
breathing of the air became a joy no less sweet because the time of their
stay was short." - J.R.R. Tolkien


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

From: eboston@boi.hp.com (Ed Boston)
Subject: Re: Anyone want T1 access from Linux?
Date: 10 Aug 1994 17:57:49 GMT

Bill Kress (kress@kentrox.com) wrote:
: So, basically, is there anyone out there who wants an internal CSU/DSU
: card for Linux, or Linux still too hobbie oriented to support this kind
: of a product?

What price range are we talking about?  I am working with out local county
library in setting up some access to the Internet for using WWW (we already
have access at the library).  We are also looking at other possible links
to other sites via ISDN or dedicated lines.

--
Edward Boston

   phone: (208) 396-3842
     fax: (208) 396-3976
internet: eboston@hpdmd48.boi.hp.com
 US Mail: Edward Boston
          Hewlett-Packard Company
          Boise Printer Division
          M/S 361
          11311 Chinden Blvd.
          Boise, ID  83714-0015

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

From: dehartog@ccult1.comcons.nl (Hans de Hartog)
Subject: Re: Does anyone use SONY CDU-535 CD-ROM anymore?
Date: Wed, 10 Aug 1994 09:06:52 GMT

jrc01@maroon.tc.umn.edu (Jeffrey Comstock) writes:

>In article <31v4q6$50f@solaris.cc.vt.edu>,
>David La Croix <dlacroix@guilder.bevd.blacksburg.va.us> wrote:
>>I just got a SONY CDU 535 type CD-ROM drive, and I'd like to use it under
>>LINUX... I'm using 1.1.38, and the patch I found sony535-0.5 doesn't patch
>>cleanly into the 1.1.38.  I would like to know if anyone is using one of these 
>>drives, and also, if this patch, (if done by hand) will cause problems with
>>the 1.1.30 and up kernels.  I'd like to use 1.1.39 if possible.
>>
>>Could support for these drives be put into the stock kernel?  (since this is
>>extremely close to the CDU 31A type drives.)


>I am using the yggdrasil kernel, and it works with my CDU535.  I don't know
>which patch level the ygg kernel is at..
>--
>Jeffrey Comstock
>INET: jrc@brainiac.mn.org               AT&T: 317-578-0884
>CW:   -. .-. ----- -..             

YES! PLEASE keep the Sony535 as a standard in future kernels!
I'm currently stuck with 1.0.<something> because of this!

-- 
 _____________________________________________________________________________
 Hans de Hartog, dehartog@comcons.nl, Voice: +31 348033100, Fax: +31 348033181
 Committed Consultancy BV, Korenmolenlaan 1b, 3447 GG Woerden, The Netherlands 

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

From: udc@netcom.com (United Data Corporation)
Subject: Re: Anyone want T1 access from Linux?
Date: Wed, 10 Aug 1994 15:42:39 GMT

Bill,

We would be interested in an ISDN connection.
-- 
Irving Greisman

United Data Corporation  | voice:    (415) 750-8068
3755 Balboa St           | FAX:      (415) 221-2798
San Francisco, CA 94121  | Internet: udc@netcom.com

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

From: torvalds@cc.Helsinki.FI (Linus Torvalds)
Subject: Re: g++ 2.6.0 kernel compiler problem
Date: 10 Aug 1994 20:33:11 +0300

In article <1994Aug6.153935.15933@dcs.warwick.ac.uk>,
Beeblebrox <M.S.Ashton@dcs.warwick.ac.uk> wrote:
>marc@offline.be (Marc Duponcheel) writes:
>
>>Hello linux developers,
>
>>Anyone has tried to use 2.6.0 for kernel builing ?
>
>Yes, works fine.

Newer kernels seem to compile with 2.6.0, but I have had a few
discouraging reports on the actual workings of those kernels.  I'd
strongly suggest not using 2.6.0 for kernel compilation: the new
compiler seems to do bad things to inline assembly, for example. 

                Linus

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

Subject: Problems compiling dosemu 0.53.11
From: kim.enkovaara@compart.fi (Kim Enkovaara)
Date: Wed, 10 Aug 94 20:23:00 +0200

I have been trying to compile Dosemu 0.53.11, but I always get the same
error messages. Version 0.52.9 (or few numbers lower compiled fine).

gcc -O2 -Wall   -I/usr/include/ncurses -I../include -I.. -c terminal.c
terminal.c:32: `attrset_normal' undeclared here (not in a function)
terminal.c: In function `terminal_initialize':
terminal.c:85: `attrset_xterm' undeclared (first use this function)
terminal.c:85: (Each undeclared identifier is reported only once
terminal.c:85: for each function it appears in.)
terminal.c:89: `attrset_normal' undeclared (first use this function)
make: *** [terminal.o] Error 1

I have 1.1.42 kernel, and ncurses 1.8.5 (just upgraded trying to solve
the problem). What might be causing the problem.

-=KIM=-
kim.enkovaara@compart.fi

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

Subject: using direct video-access in textmode
From: boekhold@morra.et.tudelft.nl (Maarten Boekhold (Who'd you expect??))
Date: 10 Aug 94 18:41:55 +0200

Hi,

I'm busy porting a program from DOS to Linux, and it uses direct access 
to video-mem in all display-modes I can think of. For graphics-mode this 
isn't a problem, svgalib can take care of it. But can I access the video 
memory in text-mode also? I can't remember seeing svgalib taking care of 
this, so, do I have to write an additional 'stextlib' similar to svgalib 
to do this? (perhaps extending svgalib, I don't know).

If anybody has any experience with this, please mail me (and no, 
rewriting to use ncurses is not really an alternative, since the routines 
are so mixed with graphics-mode parts an textmode-parts (and even a mixed 
mode), that this would greatly complicate the porting).

On another note, since I returned from holidays, netwroking doesn't work 
anymore here at home. I have 3 machines on ethernet (which were all off 
during holidays), of which one serves as 'modemserver' and has no 
keyboard, external drives and display (I have a terminal hookup up 
though). I have a lot of information on that machine and I can't get it of.

The situation is as follows: the machines were turned off (cleanly), 
turned on again, and the networking didn't work anymore. I don't have any 
errors, except for a message from mount at startup about a not available 
service or something (and it says something about bdflush not being 
started). All normal programs and daemons are running, and at the moment 
I'm completely frustated and don't want to look into it anymore (I have 
to cook anyway, so....)

Maarten
boekhold@morra.et.tudelft.nl

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

From: brian@xp.psych.nyu.edu (Brian Watts)
Subject: Re: SLIP routing problems
Date: 10 Aug 1994 19:29:31 GMT

Apologies for a false alarm....

I recompiled the kernel with :
IP forwarding/gateway : y
And SLIP works pefectly now.  I hadn't realised that the default
was NOT to forward IP packets.

Sorry for the waste of band-width.

I'm still curious as to why dip doesn't configure the interface
correctly though...

Brian

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

From: heiko@lotte.sax.de (Heiko Schlittermann)
Subject: How to invalidate buffers?
Date: Wed, 10 Aug 1994 17:06:56 GMT


Hi,
I'm just sitting with writing a loadable cd rom driver.  At least in
the course of testing I often have to remove and load the driver, and
try a dd < /dev / mcd, but it seems, the kernel buffers always
remember the already read blocks, so I can't test the newly inserted
driver.  (Ok, I could dd if=/dev/hda bs=1k count=[many] ...)

Is there a more or less clean way to get a buffer invalidate coded
into a driver?

-- heiko

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

From: heiko@lotte.sax.de (Heiko Schlittermann)
Subject: Will check_*_media_change() never be called?
Date: Wed, 10 Aug 1994 17:14:37 GMT

Im missing calles to check_*_media_change() ... I thought it would be
a task of some fs code to check the media_change state of the device,
at least when mounting it.  What happened to this call?

(I've added a printk to the function in my driver - the text will
never appear...)

Kernel:
Linux lotte 1.0.8 #4 Wed Aug 10 07:09:19 MET DST 1994 i486

-- heiko

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

From: kaefer@aglaia.in-berlin.de (Thorsten Meinecke)
Subject: Re: Problems compiling dosemu 0.53.11
Date: Thu, 11 Aug 1994 00:53:49 GMT

In article <1f.6185.1566.0NC8F28C@compart.fi>,
Kim Enkovaara <kim.enkovaara@compart.fi> wrote:
> I have been trying to compile Dosemu 0.53.11, but I always get the same
> error messages. Version 0.52.9 (or few numbers lower compiled fine).
> 
> gcc -O2 -Wall   -I/usr/include/ncurses -I../include -I.. -c terminal.c
> terminal.c:32: `attrset_normal' undeclared here (not in a function)
> terminal.c: In function `terminal_initialize':
> terminal.c:85: `attrset_xterm' undeclared (first use this function)
> terminal.c:85: (Each undeclared identifier is reported only once
> terminal.c:85: for each function it appears in.)
> terminal.c:89: `attrset_normal' undeclared (first use this function)
> make: *** [terminal.o] Error 1

There's a line with a spurious backslash in `pre53_7.dif.gz' just before
the patch to video/terminal.h, which causes patch(1) to abort. Remove
the offending line.

Another question:
Since kernel 1.1.41 fdpatches are in. To utilize non-standard floppy disk
formats with dosemu it's necessary to trigger the kernel's floppy format
autodetection before actually opening the disk. So I'm using the following
kludge (suggested by <Alain.Knaff@imag.fr>, the author of fdpatches), which
introduces security problems when dosemu runs setuid:

diff -u2 dosemu0.53/disks.c.orig dosemu0.53/disks.c
--- dosemu0.53/disks.c.orig     Wed Jul 27 01:25:19 1994
+++ dosemu0.53/disks.c  Mon Aug  8 23:33:05 1994
@@ -399,4 +399,5 @@
   if (dp == NULL || dp->fdesc >= 0)
     return;
+  system("mdir a: >&/dev/null");
   dp->fdesc = DOS_SYSCALL(open(dp->dev_name, dp->rdonly ? O_RDONLY : O_RDWR, 0));
   if (dp->fdesc < 0) {

Any thoughts?
-- 
Thorsten Meinecke - 31 year old computer addict
Though this be madness, yet there's method in't

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


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