Subject: Linux-Development Digest #724
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:     Mon, 16 May 94 21:13:09 EDT

Linux-Development Digest #724, Volume #1         Mon, 16 May 94 21:13:09 EDT

Contents:
  Parallel port Streamer. (erwan le bihan)
  Proposal for Diskette Information Interchange (Jesus Monroy Jr)
  Re: CD-ROM's do all read and write now? (Neal W. Miller)
  Re: Linux 1.0.8 SLOWER than .99pl13 !! (Wim van Dorst)
  Scanman driver for Linux ??? What about ScanMan 256? (Alexandre.Vermeerbergen)
  Re: Xfree86/mouse/IRQ/config problem (John M. Collinson)
  NeXT like voice mail ? (Shahid Ikram Butt)
  SERVER BUG XFree v2.0 (MACH8) Under Linux (Christopher Shaulis)
  SERVER BUG XFree v2.0 (MACH8) Under Linux (Christopher Shaulis)
  Re: wt news--version 0.02 - port to MSDOS (Rick Savoia)
  Kernel 1.1.12 RARP Patch (Dave Goldsmith)

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

From: elebihan@email.teaser.com (erwan le bihan)
Subject: Parallel port Streamer.
Date: Sat, 14 May 1994 14:12:07 GMT

Hi there!
Here's my little question.
I have a Slack V1.2.0 linux box running since one month, with quite no crash...
And i bought for M* D*S and Winshit a Colorado Trakker 250 Mo.
Linux is not able to handle it t the moment.
Does anyone knows how it can be programmed?
I want to build the driver...

Please answer by mail,since i dont read often the news.

Thanks.

--
erwan le bihan
Internet: elebihan@email.teaser.com

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

Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware.storage,comp.sys.ibm.ps2.hardware,comp.arch.storage
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Proposal for Diskette Information Interchange
Date: Sat, 14 May 1994 01:03:23 GMT

 
 
                Proposal for Diskette Information Interchange
                _____________________________________________
 
        author: jmonroy@netcom.com
        date: 05-11-1994
 
 
        Introduction
        ____________
 
                As will be noted, I started working on this idea
        several months ago (ok, a year ago).   None the less, the
        time has come to discuss this.  It will be needed, as a
        standardized method of distribution of floppy diskettes
        is not yet available.   Some will argue that the MS-DOS
        format is conducive.  However, because the bad-sector
        marking method is so file-system specific, it really is
        not transportable.   To add to this, I am not saying that
        there is not a standard method; there is just not a
        "standardized method".   It can also be said that each
        working OS group has it's own "boot methodology".  This,
        again, is not always conducive.
 
 
        The Proposal
        ____________
 
                The proposal is that all Public Domain (or freely
        available) Operating Systems use this method (or one like it)
        to store data on bootable floppy diskettes.  I have left the
        proposal as meager as possible,  so that there be no complex
        issues.  I have also limited the incorporation of the format
        to high density diskettes; those with  more than 15 (or more)
        sectors per track.
 
 
        Prerequisites
        ____________
 
        1)      Diskettes are intended for IBM PC/AT type machines,
                sometimes referred to as "MS-DOS machines" or "PC's".
 
        2)      Diskettes must be of the high density variety. Namely
                the 1.2 MB (MegaByte) or the 1.44 MB diskettes.
 
        3)      Higher density diskettes are also included, 2.88 and
                20 MB.
 
        4)      Other "machine-types" may be included if there is
                found a method for easy media/information-exchange.
 
 
 
 
 
General diskette format
_______________________
 
started: 22:55:04 Sun  04-11-1993  
presented: 13:25:05 Wed  05-11-1994  by jmonroy@netcom.com
 
 
 
    BOOT DISK ONLY
    ______________
 
 
                TRACK ZERO
 
            |     sector 1-3        |  sector 4 & 5 |  sector 6-15  |
            ---------------------------------------------------------
            | IBM/MS-DOS compatible | bad-sector map|   reserved    |
            ---------------------------------------------------------
 
                TRACK remaining
 
            |     sector remaining                                  |
            ---------------------------------------------------------
            |     use as needed                                     |
            ---------------------------------------------------------
 
 
 
        IBM/MS-DOS compatible
        _____________________
 
                TRACK ZERO  sector 1-3
 
 
        bad sector map
        ______________
 
                TRACK ZERO  sector 4-5
 
                byte-map = 8 bits
 
                1 bit    = 1 sector representation.
 
                So, 8 sectors per byte-map (or 4096 bytes per byte-map)
        or, 2048 sectors per 256 byte-map (or 1 megabyte per 256 byte-map)
        or, 40960 sectors per 5120 byte-map (or 20 megabytes per 5120 byte-map)
        BTW, a 5120 byte-map is 10 sectors, on the floppy, which would
        be for the new 20meg diskettes.
 
 
        reserved
        ________
 
                TRACK ZERO  sector 4-5
 
                A "bad-sector" map area for 20 meg diskettes.
 
                These disk drives are scsi and have their own format to
        by pass bad sector problems. In either case, reserving track
        zero make it compatible with IBM/MS-DOS.
 
 
        notes
        _____
 
                The question may arise, Can we boot from a tape?
 
                Without getting complicated, no.  The best solution,
        for the present, is to boot from diskette, load from diskette,
        then "option to load" from:
 
                1)      more diskettes
                2)      ethernet/token ring (whatever network device)
                3)      communication port
                4)      SCSI tape
                5)      QIC-40/80 tape
                6)      CD-ROM
                7)      etc. (whatever the option, NFS, e-mail, etc.)
 
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________


-- 
Jesus Monroy Jr                                          jmonroy@netcom.com
Zebra Research
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________

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

From: millen3@rebecca.its.rpi.edu (Neal W. Miller)
Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.os.mach,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware.misc
Subject: Re: CD-ROM's do all read and write now?
Date: 16 May 1994 13:40:05 GMT

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

>In article <2r1e1e$qi4@rainbow.sosi.com> stanf@rainbow.sosi.com (Stan Foy) writes:
>>: Can someone tell me if all CD drives read and write now?  Which ones
>>: are the "top of the line"?

>>  Nope, your standard CD is read only.

>It may also be worth pointing out that an MSDOS virus has been
>distributed disguised as a program which converts conventional CD
>drives to read-write.  No such thing is possible in software; don't
>install anything which purports to do it.

        Of course such software exists.  I've even got a cigarette lighter
in my car that gives the vehicle underwater and aerial capabilities.


-- 
==============================================================================
Neal Miller     | Rensselaer Polytech. | "This Side Up - Not Plummet Please!" 
millen3@rpi.edu | Troy, NY 12180       |   - the box for my Taiwanese CPU fan
==============================================================================

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

From: baron@clifton.hobby.nl (Wim van Dorst)
Subject: Re: Linux 1.0.8 SLOWER than .99pl13 !!
Date: Fri, 13 May 94 23:48:48 MDT

Dave Hinz wrote:
    } I was recently testing the floating performance of the Linux Slackware
    } distribution using the clinpack.c source.  For my  486DX2-66  I had
    } previously obtained around 3.1 Mflops DP under .99pl13 but now I get
    } only 2.8 Mflops under 1.0.8 -- that's a 10% loss in performance!!!

From the ratings listed in sony.com:/some....where/clinpack.dpr

} System               OS, Compiler              CPU/FPU   CPU   MFLOPS   REF
}                                                         (MHz)  DP,ROLL     
} -------------------- ------------------------- -------- ----- --------- ---
} Vega 486             NOTE B01, MS DOS 5.0      80486DX   33.3     1.467   1
} B01 gcc 2.1, gcc -O2 -funroll-loops -fomit-frame-pointer -fstrength-reduce
} 
} REF:                                                                      
} 1   Al Aburto, aburto@marlin.nosc.mil, average of 5 or more runs as the
}     results jump around a bit, 12 Oct 1992

Considering that your system is twice as fast as the one
listed here, a rating of 2.8 is quite reasonable. The
suggestions by others in this thread that improved timing is
making your rating more accurate (be it perceivably less) is
therefore not unrealistic.

ps. I get 0.447 MFlops on a 386DX+387DX/33, Linux 1.1.12, gcc 2.5.8.

Met vriendelijke groeten, Wim van Dorst
--
=====================================================================
Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
(-:        baron@clifton.hobby.nl           WvD@Akzo.nl           :-)
=====================================================================

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

From: vermeer@imag.imag.fr (Alexandre.Vermeerbergen)
Subject: Scanman driver for Linux ??? What about ScanMan 256?
Date: Mon, 16 May 1994 13:33:24 GMT


Hi, I saw that German folks made a driver for Scanman-32.
How about Scanman 256 ? Mine is a Scanman 256 in greyscale.
Would the Scanman-32 driver work with my scanner? 
[I know: the answer is *try it*... ok I'll see]

Alex.





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

Crossposted-To: comp.os.linux.admin,comp.windows.x.i386unix,comp.os.linux.misc,alt.uu.comp.os.linux.questions,aus.computers.linux,fr.comp.os.linux,maus.os.linux,de.comp.os.linux,fj.os.linux,no.linux
From: csjmc@blaze.trentu.ca (John M. Collinson)
Subject: Re: Xfree86/mouse/IRQ/config problem
Date: Mon, 16 May 1994 19:50:23 GMT

In article <2r10br$gfm@panix.com>, Douglas Donahue <odoncaoa@panix.com> wrote:
>Greetings,
>
>
>Here are the entries in /dev:
>
>lrwxrwxrwx   1 root     root            8 Mar 23 08:05 mouse -> bmousems
>crw-rw-rw-   1 root     root      10,   2 Nov 30 14:30 bmousems
>
>Here is the output of startx:
>
>> XFree86 Version 2.0 / X Window System
>> (protocol Version 11, revision 0, vendor release 5000)
>> Operating System: Linux 
>> Configured drivers:
>>   VGA256: server for 8-bit colour SVGA (Patchlevel 0):
>>       et4000, et3000, pvga1, wd90c00, wd90c10, wd90c30, wd90c31, gvga, ati,
>>       tvga8800cs, tvga8900b, tvga8900c, tvga8900cl, tvga9000, clgd5420,
>>       clgd5422, clgd5424, clgd5426, clgd5428, clgd6205, clgd6215, clgd6225,
>>       clgd6235, ncr77c22, ncr77c22e, cpq_avga, oti067, oti077
>> (using VT number 7)
>> 
>> Xconfig: /usr2/odoncaoa/Xconfig
>> (**) stands for supplied, (--) stands for probed/default values
>> (**) Mouse: type: Microsoft, device: /dev/mouse, baudrate: 9600
                     ^^^^^^^^^                      ^^^^^^^^^^^^^^^
                     I think your problem lies here, but If I am wrong
                     please feel free to correct me.  Your Xconfig file
                     should contain the line:
                     Busmouse         /dev/mouse
                     and comment out your baud setting.  The microsoft
                     setting the way i understand it is for serial
                     mice.


>> (**) FontPath set to "/usr/lib/X11/fonts/75dpi/,/usr/lib/X11/fonts/Speedo/,
>> /usr/lib/X11/fonts/misc/"
>> (**) VGA256: chipset:  tvga8900c
>> (**) VGA256: videoram: 1024k
>> (**) VGA256: clocks:  25.20  28.30  44.90  36.00  50.35  40.35  65.00  75.00
>> (--) VGA256: Maximum allowed dot-clock: 90MHz
>> (**) VGA256: Mode "800x600": mode clock =  36.000, clock used =  36.000
>> (**) VGA256: Mode "640x480": mode clock =  25.000, clock used =  25.200
>> (**) VGA256: Virtual resolution set to 800x600
>> (--) VGA256: SpeedUp code selection modified because virtualX != 1024
>> Warning: unable to get status of mouse fd (Invalid argument)
>>
>> waiting for X server to shut down 
>> 
>> xinit:  Unknown error (errno 0):  Client error.
>
>Cheers,
>
>Doug

John Collinson

-- 
============================================================================
|  John M. Collinson                      Internet: csjmc@blaze.trentu.ca  | 
|  Computer Studies and                              jcollinson@trentu.ca  |
|  Environmental Resource Studies              john.collinson@fleming.edu  |
|  Trent University, Peterborough, Ontario, CANADA                         |
============================================================================

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

From: sib1@Ra.MsState.Edu (Shahid Ikram Butt)
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc
Subject: NeXT like voice mail ?
Date: 15 May 1994 00:26:50 -0500


I have not installed Linux on my machine yet, I am looking to do that 
real soon. A quick question. Is anybody working on NeXT-like voice 
mail system for Linux ? I like the ability to send/receive voice mail on my
computer.  Just about everybody has sounblaster or compatible card and
it shouldn't be difficult to stnadardize something like that. 

If we could get voice messages and gifs in the sig file of a voice message
we'd very close to video-conferencing without wasting all that bandwidth.
The data could also be automatically compressed/decompressed 
uudecoded/uuencoded etc ? 

How easy or difficult something like this should be to write ? Does something 
like this already exist for Linux ? I haven't noticed in any Linux users' sigs
as I do in NeXT owners' sigs. Imagine putting "Linux mail accepted here" next
to your email address. 

Any ideas ?


Shahid
   ______________________sib1@Ra.Msstate.Edu____________________________
                  Cruising Information Super Highway
                  WWW : http://www.msstate.edu/~sib1

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

Crossposted-To: comp.os.linux.misc,comp.os.linux.help,comp.windows.x,comp.windows.x.apps,comp.windows.x.intrinsics,comp.unix.programmer,comp.programming
From: cjs@netcom.com (Christopher Shaulis)
Subject: SERVER BUG XFree v2.0 (MACH8) Under Linux
Date: Sun, 15 May 1994 05:24:52 GMT

The following concerns the Linux version of the XFree v2.0 MACH 8 X11R5 
server. I've gone over all the XGetWindowProperty calls in Xlib as well
as the MIT docs, and it appears that I'm passing all the correct 
arguments (valid arguments I might add). According to the outputs from 
XGetWindowProperty, it is returning one 32-bit item of type XA_INTEGER.
However, the number it returns is not even close to what I put (and 
xprop confirms) into the property. I believe that I have eliminated
all the possible causes except for the server itself. Though I would
rather someone make me look like an idiot and show me what the problem
with the code is, then have a bug report to my credit. Below is the code
I use to creat the property and retrieve the value. Along with sample 
output from xprop. And before I go, let me say one more time that 
handle->window, handle->prop, display, and all the rest are indeed valad
handles. temp is an unsigned long integer at all times.

/* Creating the property */
  handle->prop = XInternAtom(display,"TEST",False);
  XChangeProperty(display,
                  handle->window,
                  handle->prop,
                  XA_INTEGER,
                  32,
                  PropModeAppend,
                  &temp,
                  1);

/* Output from xprop */
TEST(INTEGER) = 0
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified location: 16, 248
                program specified size: 592 by 16
WM_ICON_NAME(STRING) =
WM_NAME(STRING) = "TW"

/* Retrieveing the property */
  Atom type_return;
  int format_return;
  unsigned long nitems_return;
  unsigned long bytes_after_return;
  unsigned long prop_return; 

  XGetWindowProperty(event->xany.display,
                     event->xany.window,
                     handle->prop,
                     0L,
                     1L,
                     False,
                     XA_INTEGER,
                     &type_return,
                     &format_return,
                     &nitems_return,
                     &bytes_after_return,
                     (unsigned long**)&prop_return);

/* Value returned */
32760

The above value decreases every time I call the function 
which retrieves the value.

Hope someone sees what I'm doing wrong.
Christopher
  ___     _  ___   ____  _  _ ___ _____  ___  ___  __  __     ___  ___  __  __ 
 / __|_  | |/ __| / __ \| \| | __|_   _|/ __|/ _ \|  \/  |   / __|/ _ \|  \/  |
| (__| |_| |\__ \/ / _` | .` | _|  | | | (__| (_) | |\/| | _| (__| (_) | |\/| |
 \___|\___/ |___/\ \__,_|_|\_|___| |_|  \___|\___/|_|  |_|(_)\___|\___/|_|  |_|
==================\____/=======================================================



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

Crossposted-To: comp.os.linux.misc,comp.os.linux.help,comp.windows.x,comp.windows.x.apps,comp.windows.x.intrinsics,comp.unix.programmer,comp.programming
From: cjs@netcom.com (Christopher Shaulis)
Subject: SERVER BUG XFree v2.0 (MACH8) Under Linux
Date: Sun, 15 May 1994 05:25:59 GMT

The following concerns the Linux version of the XFree v2.0 MACH 8 X11R5 
server. I've gone over all the XGetWindowProperty calls in Xlib as well
as the MIT docs, and it appears that I'm passing all the correct 
arguments (valid arguments I might add). According to the outputs from 
XGetWindowProperty, it is returning one 32-bit item of type XA_INTEGER.
However, the number it returns is not even close to what I put (and 
xprop confirms) into the property. I believe that I have eliminated
all the possible causes except for the server itself. Though I would
rather someone make me look like an idiot and show me what the problem
with the code is, then have a bug report to my credit. Below is the code
I use to creat the property and retrieve the value. Along with sample 
output from xprop. And before I go, let me say one more time that 
handle->window, handle->prop, display, and all the rest are indeed valad
handles. temp is an unsigned long integer at all times.

/* Creating the property */
  handle->prop = XInternAtom(display,"TEST",False);
  XChangeProperty(display,
                  handle->window,
                  handle->prop,
                  XA_INTEGER,
                  32,
                  PropModeAppend,
                  &temp,
                  1);

/* Output from xprop */
TEST(INTEGER) = 0
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified location: 16, 248
                program specified size: 592 by 16
WM_ICON_NAME(STRING) =
WM_NAME(STRING) = "TW"

/* Retrieveing the property */
  Atom type_return;
  int format_return;
  unsigned long nitems_return;
  unsigned long bytes_after_return;
  unsigned long prop_return; 

  XGetWindowProperty(event->xany.display,
                     event->xany.window,
                     handle->prop,
                     0L,
                     1L,
                     False,
                     XA_INTEGER,
                     &type_return,
                     &format_return,
                     &nitems_return,
                     &bytes_after_return,
                     (unsigned long**)&prop_return);

/* Value returned */
32760

The above value decreases every time I call the function 
which retrieves the value.

Hope someone sees what I'm doing wrong.
Christopher
  ___     _  ___   ____  _  _ ___ _____  ___  ___  __  __     ___  ___  __  __ 
 / __|_  | |/ __| / __ \| \| | __|_   _|/ __|/ _ \|  \/  |   / __|/ _ \|  \/  |
| (__| |_| |\__ \/ / _` | .` | _|  | | | (__| (_) | |\/| | _| (__| (_) | |\/| |
 \___|\___/ |___/\ \__,_|_|\_|___| |_|  \___|\___/|_|  |_|(_)\___|\___/|_|  |_|
==================\____/=======================================================



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

From: savoia@sw.stratus.com (Rick Savoia)
Crossposted-To: rec.games.programmer,comp.windows.x
Subject: Re: wt news--version 0.02 - port to MSDOS
Date: 16 May 1994 15:50:59 GMT

In article <1994May13.204100.19155@cc.usu.edu>, sl859@cc.usu.edu writes:
> > Please post these ports, or tell us where we can get them.
> 
> Posted 3 days ago to rec.games.programmer.
> 
> Joshua Jensen


How about a repost?  I didn't realize that the articles
got cancelled that quickly at my site and I was gone
for a few days last week.

Rick
-- 
==========================================================
Rick Savoia                     | "I'm just very selective
savoia@okemo.sqa.stratus.com    | about the reality 
Rick_Savoia@vos.stratus.com     | I accept" - Calvin
==========================================================


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

From: cs65x4@sdcc8.ucsd.edu (Dave Goldsmith)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Kernel 1.1.12 RARP Patch
Date: 15 May 94 06:52:10 GMT

There are two problems involving RARP support in the kernel 1.1.12:

1) To compile successfully if CONFIG_INET_RARP is defined, rarp.o
   must be added to the list of OBJS in the net/inet/Makefile

2) To compile successfully if CONFIG_INET_RARP is NOT defined,
   the referneces to RARP code in the files fs/proc/net.c and
   net/inet/sock.c must be surrounded with #ifdef ... #endif
   structures so as not to include them if RARP is not configured in.

The following patch file makes the necessary modifications to the
above mentioned three files.

Dave Goldsmith
cs65x4@icse1.ucsd.edu

=====  begin patch file =====
diff -u --recursive --new-file linux-1.1.12/fs/proc/net.c linux/fs/proc/net.c
--- linux-1.1.12/fs/proc/net.c  Sat May 14 16:15:12 1994
+++ linux/fs/proc/net.c Mon May  9 21:56:19 1994
@@ -44,7 +44,9 @@
 extern int udp_get_info(char *, char **, off_t, int);
 extern int raw_get_info(char *, char **, off_t, int);
 extern int arp_get_info(char *, char **, off_t, int);
+#ifdef CONFIG_INET_RARP
 extern int rarp_get_info(char *, char **, off_t, int);
+#endif /* CONFIG_INET_RARP */
 extern int dev_get_info(char *, char **, off_t, int);
 extern int rt_get_info(char *, char **, off_t, int);
 #endif /* CONFIG_INET */
@@ -100,7 +102,7 @@
        { 134,3,"udp" },
 #ifdef CONFIG_INET_RARP
        { 135,4,"rarp"}
-#endif
+#endif /* CONFIG_INET_RARP */
 #endif /* CONFIG_INET */
 #ifdef CONFIG_IPX
        ,{ 136,9,"ipx_route" },
@@ -216,9 +218,11 @@
                        case 134:
                                length = udp_get_info(page,&start,file->f_pos,thistime);
                                break;
+#ifdef CONFIG_INET_RARP
                        case 135:
                                length = rarp_get_info(page,&start,file->f_pos,thistime);
                                break;
+#endif /* CONFIG_INET_RARP */
 #endif /* CONFIG_INET */
 #ifdef CONFIG_IPX
                        case 136:
diff -u --recursive --new-file linux-1.1.12/net/inet/Makefile linux/net/inet/Makefile
--- linux-1.1.12/net/inet/Makefile      Sat May 14 16:14:25 1994
+++ linux/net/inet/Makefile     Mon May  9 21:56:19 1994
@@ -19,6 +19,12 @@
          eth.o packet.o arp.o dev.o ip.o raw.o icmp.o tcp.o udp.o \
          datagram.o skbuff.o devinet.o
 
+ifdef CONFIG_INET_RARP
+
+OBJS   := $(OBJS) rarp.o
+
+endif
+
 ifdef CONFIG_AX25
 
 OBJS   := $(OBJS) ax25.o ax25_in.o ax25_out.o ax25_subr.o ax25_timer.o
diff -u --recursive --new-file linux-1.1.12/net/inet/sock.c linux/net/inet/sock.c
--- linux-1.1.12/net/inet/sock.c        Sat May 14 16:15:14 1994
+++ linux/net/inet/sock.c       Mon May  9 21:56:19 1994
@@ -87,7 +87,9 @@
 #include "ip.h"
 #include "protocol.h"
 #include "arp.h"
+#ifdef CONFIG_INET_RARP
 #include "rarp.h"
+#endif /* CONFIG_INET_RARP */
 #include "route.h"
 #include "tcp.h"
 #include "udp.h"
@@ -1484,10 +1486,12 @@
        case SIOCSARP:
                return(arp_ioctl(cmd,(void *) arg));
 
+#ifdef CONFIG_INET_RARP
        case SIOCDRARP:
        case SIOCGRARP:
        case SIOCSRARP:
                return(rarp_ioctl(cmd,(void *) arg));
+#endif /* CONFIG_INET_RARP */
 
        case SIOCGIFCONF:
        case SIOCGIFFLAGS:
=====  end patch file =====

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


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