Subject: Linux-Development Digest #959
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, 29 Jul 94 01:13:05 EDT

Linux-Development Digest #959, Volume #1         Fri, 29 Jul 94 01:13:05 EDT

Contents:
  Re: Xfree86: increase pallate? (David Wright)
  buggy accept() syscall in Linux 1.1.0? (Mike L. Kienenberger)
  mouse error on 1.1.35 (Supat Faarungsang)
  Re: Realtime? (Michael K. Johnson)
  Re: APC UPS owners or potential buyers, trying to show user base (Michael K. Johnson)
  Re: 1.1.36 make problem: 'NULL' undeclared (Lewis Tanzos)
  Re: procps-0.95 broken -- problem is in linux/sched.h (Jim Balter)
  Realtime sound progr. (Riku Saikkonen)

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

From: dmw@prism1.prism1.com (David Wright)
Subject: Re: Xfree86: increase pallate?
Date: Thu, 28 Jul 1994 12:41:08 GMT

=====BEGIN PGP SIGNED MESSAGE=====

>>>>> "JS" == Janne Sinkkonen <janne@avocado.pc.helsinki.fi> writes:

  JS> Is there such thing as FreeLSD?

        Sure, but it is only distributed in source form. You have to come up
with the ingedients on your own.

                                                Dave

=====BEGIN PGP SIGNATURE=====
Version: 2.6

iQCVAgUBLjenXm++A+T9du0zAQGI7gP7BC4GB4m/GLujKRTtte4cb2EmFviq/DM6
AavztAs7K2/r/4sSTS7mflAxBsggjJHXkWES+aDPAnRWeNjpe/ec13lntS+o+tcq
VhRtDY8lbceUXp7hO133bnKjidwYJxEIWGYCmq8r8i+5lHoLAJ/qFQzR5z9gQiop
JzG+s3AZWL4=
=QzH1
=====END PGP SIGNATURE=====
--
  ____________________________________________________________________________
 |        /\ /          | Prism Computer Applications        |  David Wright  |
 |      -/--\--         | 14650 Detroit Ave, Suite LL40      | dmw@Prism1.COM |
 |      /____\          | Lakewood, OH 44107  USA            |  216-228-1400  |

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

From: fxmlk@camelot.acf-lab.alaska.edu (Mike L. Kienenberger)
Subject: buggy accept() syscall in Linux 1.1.0?
Reply-To: fxmlk@aurora.alaska.edu
Date: Tue, 26 Jul 1994 02:06:04 GMT

I'm running a program which uses a great deal of network tcp/ip sockets.
It's a standard server single-process model where the main loop of the
program uses a select to listen for new connections from clients on a
specific port while waiting for activity on any of the already-accepted
sockets.  However, the accept() often fails with errors that normally only
appear when using the connect() call.

So far, I've received the following errors from the accept() call.
These are also received by the client (normally telnet or a telnet-like  
program.)

        EPIPE
        EAGAIN
        ECONNREFUSED
        ETIMEDOUT
        EHOSTUNREACH
        ECONNRESET

Note that not only are these errors normally not returned by accept(), but
that they are also "nonsense".   For instance, attempting to run a client
multiple times in a row could result in success, success, connection
refused, success, etc, even though the server process never changed the
listening socket.

The same program(s) have run successfully for months under other operating
systems (Mach, NetBSD, SunOS to name a few).

The main (and most cricital) program is a penn-p8 MUSH for those who care,
but I've also noticed the problem under other programs, one of which I've
included in it's entirety at the end of this posting.  These problems do
not necessarily occur often.

If this problem has been fixed (or at least lessened) in a newer release,
(I've checked /usr/src/linux/net/inet/tcp.c and didn't notice a fix,
although I did notice a mention of possible problems with accept()),
please let me know that as well.  For now, I'm just ignoring the errors.
However, since each of my clients are actually real live people on the
other end, receiving these messages really confuses them.

If you need more information, please let me know.  I'll post a summary
to the net if there's interest.

-Mike Kienenberger
 fxmlk@aurora.alaska.edu

=========================================================================
The system was installed from Yggdrasil Summer '94 CD.
The ethernet card is a SMC Elite 16TP card.

# uname -a
Linux starwars.arcade.com 1.1.0 #82 Sat Apr 23 02:55:44 PDT 1994 i486

# more /proc/version
Linux version 1.1.0 (root@adam.yggdrasil.com) #82 Sat Apr 23 02:55:44 PDT  
1994

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

# ls -l /lib/lib*
lrwxrwxrwx   1 root     system         14 Jul 19 23:22 /lib/libc.so.4 ->  
libc.so.4.5.26*
-rwxr-xr-x   1 root     system     623620 Apr 20 13:37  
/lib/libc.so.4.5.26*
lrwxrwxrwx   1 root     system         14 Jul 19 23:22 /lib/libm.so.4 ->  
libm.so.4.5.26*
-rwxr-xr-x   1 root     system     107524 Apr 20 13:37  
/lib/libm.so.4.5.26*
-rwxr-xr-x   1 root     system     682283 Apr 20 21:04 /lib/libxdosemu*

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

# ls -l /usr/lib/lib*
-rw-r--r--   1 root     system     218926 Apr 20 16:04 /usr/lib/libBLT.a
-rw-r--r--   1 root     system       5702 Apr 20 16:04 /usr/lib/libBLT.sa
lrwxrwxrwx   1 root     system         13 Jul 20 22:07  
/usr/lib/libBLT.so.3 -> libBLT.so.3.2
-rw-r--r--   1 root     system     244534 Apr 20 16:04  
/usr/lib/libBLT.so.3.2
-rw-r--r--   1 root     system      29060 Apr 21 05:11 /usr/lib/libF77.a
-rw-r--r--   1 root     system      83250 Apr 21 05:11 /usr/lib/libI77.a
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libX11.a  
-> ../X386/lib/libX11.a
lrwxrwxrwx   1 root     system         21 Jul 20 22:15 /usr/lib/libX11.sa  
-> ../X386/lib/libX11.sa
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libXau.a  
-> ../X386/lib/libXau.a
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libXaw.a  
-> ../X386/lib/libXaw.a
lrwxrwxrwx   1 root     system         21 Jul 20 22:15 /usr/lib/libXaw.sa  
-> ../X386/lib/libXaw.sa
lrwxrwxrwx   1 root     system         22 Jul 20 22:15 /usr/lib/libXdmcp.a  
-> ../X386/lib/libXdmcp.a
lrwxrwxrwx   1 root     system         21 Jul 20 22:15 /usr/lib/libXext.a  
-> ../X386/lib/libXext.a
lrwxrwxrwx   1 root     system         22 Jul 20 22:15 /usr/lib/libXext.sa  
-> ../X386/lib/libXext.sa
lrwxrwxrwx   1 root     system         19 Jul 20 22:15 /usr/lib/libXi.a ->  
./X386/lib/libXi.a
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libXi.sa  
-> ../X386/lib/libXi.sa
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libXmu.a  
-> ../X386/lib/libXmu.a
lrwxrwxrwx   1 root     system         21 Jul 20 22:15 /usr/lib/libXmu.sa  
-> ../X386/lib/libXmu.sa
lrwxrwxrwx   1 root     system         19 Jul 20 22:15 /usr/lib/libXpm.a  
-> ../X11/lib/libXpm.a
lrwxrwxrwx   1 root     system         19 Jul 20 22:15 /usr/lib/libXt.a ->  
./X386/lib/libXt.a
lrwxrwxrwx   1 root     system         20 Jul 20 22:15 /usr/lib/libXt.sa  
-> ../X386/lib/libXt.sa
lrwxrwxrwx   1 root     system         21 Jul 20 22:15 /usr/lib/libXtst.a  
-> ../X386/lib/libXtst.a
lrwxrwxrwx   1 root     system         22 Jul 20 22:15 /usr/lib/libXtst.sa  
-> ../X386/lib/libXtst.sa
-rw-r--r--   1 root     system      25186 Aug 30  1993 /usr/lib/libabi.sa
-rw-r--r--   1 root     system     194068 Apr 20 21:15 /usr/lib/libbfd.a
-rw-r--r--   1 root     system       6738 Apr 20 13:37 /usr/lib/libbsd.a
-rw-r--r--   1 root     system     420940 Apr 20 13:37 /usr/lib/libc.a
-rw-r--r--   1 root     system     175328 Apr 20 13:37 /usr/lib/libc.sa
-rw-r--r--   1 root     system     491432 Apr 20 13:37 /usr/lib/libc_p.a
-rwxr-xr-x   1 root     system     237795 Dec 18  1993  
/usr/lib/libchecker.o*
-rw-r--r--   1 root     system      37344 Apr 20 13:37  
/usr/lib/libcurses.a
-rw-r--r--   1 root     system      62066 Apr 20 13:37  
/usr/lib/libcurses.sa
-rw-r--r--   1 root     system      20496 Apr 20 13:37 /usr/lib/libdbm.a
-rw-r--r--   1 root     system      56528 Apr 20 13:37 /usr/lib/libdbm.sa
-rw-r--r--   1 bin      bin        546762 Apr 20 13:44  
/usr/lib/libdcurses.a
-rwxr-xr-x   1 root     system     193540 Apr 20 21:07 /usr/lib/libdosemu*
-rw-r--r--   1 root     system     138984 Apr 20 21:07  
/usr/lib/libexpect.a
-rw-r--r--   1 root     system     120788 Feb 11 04:57  
/usr/lib/libexptcl.a
-rw-r--r--   1 root     daemon         76 Jan 30  1993 /usr/lib/libexptk.a
-rw-r--r--   1 root     system        538 Apr 20 21:09 /usr/lib/libfl.a
-rw-r--r--   1 root     system     378544 Apr 20 13:38 /usr/lib/libg++.a
-rw-r--r--   1 root     system    2458354 Apr 20 13:37 /usr/lib/libg.a
-rw-r--r--   1 root     system      21490 Dec  4  1993 /usr/lib/libgcc.a
-rw-r--r--   1 root     system      24968 Apr 20 13:36 /usr/lib/libgdbm.a
-rw-r--r--   1 root     system       3628 Apr 20 13:37 /usr/lib/libgmon.a
-rw-r--r--   1 root     daemon      65236 Feb 12  1993 /usr/lib/libgmon.sa
-rw-r--r--   1 root     system      30392 Apr 20 13:37  
/usr/lib/libiberty.a
-rw-r--r--   1 root     system        284 Apr 20 13:37 /usr/lib/libieee.a
-rw-r--r--   1 root     system     110968 Apr 20 13:38  
/usr/lib/libiostream.a
-rw-r--r--   1 root     system      46046 Apr 20 16:04 /usr/lib/libitcl.a
-rw-r--r--   1 root     system        952 Apr 20 16:04 /usr/lib/libitcl.sa
lrwxrwxrwx   1 root     system         14 Jul 20 22:12  
/usr/lib/libitcl.so.3 -> libitcl.so.3.0
-rw-r--r--   1 root     system      81924 Apr 20 16:04  
/usr/lib/libitcl.so.3.0
-rwxr-xr-x   1 root     system      97934 Apr 20 08:31 /usr/lib/libjpeg.a*
-rw-r--r--   1 root     system      40358 Apr 20 13:37 /usr/lib/libldso.a
-rw-r--r--   1 root     system      17030 Apr 20 13:37 /usr/lib/libm.a
-rwxr-xr-x   1 root     system      12012 Apr 20 13:37 /usr/lib/libm.sa*
-rw-r--r--   1 root     system       1380 Apr 20 13:37  
/usr/lib/libmcheck.a
-rw-r--r--   1 root     system      10288 Apr 20 21:15  
/usr/lib/libmmalloc.a
-rw-r--r--   1 bin      bin        111076 Apr 20 13:44  
/usr/lib/libncurses.a
lrwxrwxrwx   1 root     system         25 Jul 20 22:12 /usr/lib/liboldX.a  
-> ///usr/X386/lib/liboldX.a
-rw-r--r--   1 root     system      45440 Apr 20 21:15  
/usr/lib/libopcodes.a
-rw-r--r--   1 root     system      12860 Apr 20 21:25 /usr/lib/libp2c.a
-rw-r--r--   1 bin      bin          4206 Apr 20 13:44 /usr/lib/libpanel.a
-rw-r--r--   1 bin      bin        553996 Apr 20 13:44  
/usr/lib/libpcurses.a
-rw-r--r--   1 root     system     105554 Apr 20 21:15  
/usr/lib/libreadline.a
-rw-r--r--   1 root     system      26386 Apr 20 14:30  
/usr/lib/libresolv.a
-rw-r--r--   1 root     system      58202 Apr 20 14:30  
/usr/lib/librpclib.a
-rw-r--r--   1 root     daemon       9150 Jan 29  1993  
/usr/lib/librpcsvc.a
-rw-r--r--   1 root     daemon      16026 Sep  2  1992 /usr/lib/libsoft.a
-rw-r--r--   1 root     system     172298 Apr 20 16:02 /usr/lib/libtcl.a
-rw-r--r--   1 root     system      26846 Apr 20 16:02 /usr/lib/libtcl.sa
lrwxrwxrwx   1 root     system         13 Jul 20 22:13  
/usr/lib/libtcl.so.3 -> libtcl.so.3.1
-rw-r--r--   1 root     system     186730 Apr 20 16:02  
/usr/lib/libtcl.so.3.1
-rw-r--r--   1 root     system     148812 Apr 20 16:03 /usr/lib/libtclx.a
-rw-r--r--   1 root     system      24316 Apr 20 16:03 /usr/lib/libtclx.sa
lrwxrwxrwx   1 root     system         16 Jul 20 22:13  
/usr/lib/libtclx.so.3 -> libtclx.so.3.1.1*
-rwxr-xr-x   1 root     system     161387 Apr 20 16:03  
/usr/lib/libtclx.so.3.1.1*
-rw-r--r--   1 root     system       6744 Apr 20 13:37  
/usr/lib/libtermcap.a
-rw-r--r--   1 root     system      53530 Apr 20 13:37  
/usr/lib/libtermcap.sa
-rw-r--r--   1 root     system     260042 Apr 20 08:31 /usr/lib/libtiff.a
-rw-r--r--   1 root     system     475406 Apr 20 16:03 /usr/lib/libtk.a
-rw-r--r--   1 root     system      46358 Apr 20 16:03 /usr/lib/libtk.sa
lrwxrwxrwx   1 root     system         14 Jul 20 22:14 /usr/lib/libtk.so.3  
-> libtk.so.3.1.1
lrwxrwxrwx   1 root     system         14 Jul 20 22:14  
/usr/lib/libtk.so.3.1 -> libtk.so.3.1.1
-rw-r--r--   1 root     system     489764 Apr 20 16:03  
/usr/lib/libtk.so.3.1.1
-rw-r--r--   1 root     system      21086 Apr 20 16:04 /usr/lib/libtkx.a
-rw-r--r--   1 root     system       2854 Apr 20 16:04 /usr/lib/libtkx.sa
lrwxrwxrwx   1 root     system         15 Jul 20 22:15  
/usr/lib/libtkx.so.3 -> libtkx.so.3.1.1*
-rwxr-xr-x   1 root     system     114340 Apr 20 16:04  
/usr/lib/libtkx.so.3.1.1*
-rw-r--r--   1 root     system      13650 Jan 25  1994 /usr/lib/libvga.a

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

# cat port_announcer.c
/*
 *      announce - sits listening on a port, and whenever anyone connects
 *                 prints out a message and disconnects them
 *
 *      Usage:  announce port < message_file
 *
 *      Author: Mike Kienenberger <fxmlk@aurora.alaska.edu>
 *              with some borrowing from Lawrence Brown  
<lpb@cs.adfa.oz.au>
 *              (message arg handling)
 */

#include <sys/param.h>
#include <sys/socket.h>
#include <sys/errno.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#ifdef NeXT
#include <libc.h>
#endif /* NeXT */

extern int errno;

void usage(program)
char *program;
{
        fprintf(stderr, "Usage:  %s port [< message_file]\n", program);
        fprintf(stderr,
        "        if no message_file specified, enter it and hit  
control-d\n");
        exit(1);
}

int main(argc, argv)
int     argc;
char *argv[];
{
    int start_socket();
    void accept_socket_channel();
    char msg[20481];
    char tmp[2048];
    int serversocket;
    int port;
    int child;

    if (argc != 2)  usage(argv[0]);
    else
    {
        port = atoi(argv[1]);
        if (0 >= port)  usage(argv[0]);
    }

    strcpy(msg, "");
    strcpy(tmp, "");
    while (1)
    {
        if ((gets(tmp)) == NULL) break;
        strcat(tmp, "\r\n");
        strcat(msg, tmp);
    }
    msg[20480] = '\0';

    serversocket = start_socket(port);
    
    if (-1 == (child = fork()))
    {
        int temperrno = errno;
        perror("port announcer");
        exit(temperrno);
    }
    else if (0 != child)
    {
        fprintf(stderr, "%s: pid %d running on port %d\n",
                argv[0], child, port);
        exit(0);
    }
    
    while (1)  accept_socket_channel(serversocket, msg);
    
    exit(0);
 }
 
int start_socket(socket_port)
int     socket_port;
{
    struct sockaddr_in  serveraddress;
    int serversocket;
    int opt;
    
    if (0 > (serversocket = socket(AF_INET, SOCK_STREAM, 0)))
    {
        int temperrno = errno;
        perror("port announcer");
        exit(temperrno);
    }

    opt = 1;
    if (setsockopt(serversocket, SOL_SOCKET, SO_REUSEADDR,
                    (char *) &opt, sizeof(opt)) < 0)
    {
        int temperrno = errno;
        perror("port announcer");
        exit(temperrno);
    }
    
    bzero((char *) &serveraddress, sizeof(serveraddress));
    serveraddress.sin_family = AF_INET;
    serveraddress.sin_addr.s_addr = htonl(INADDR_ANY);
    serveraddress.sin_port = htons(socket_port);
    
    if (0 > bind(serversocket, (struct sockaddr *) &serveraddress,
                sizeof(serveraddress)))
        {
                int temperrno = errno;
                perror("port announcer");
                exit(temperrno);
        }
    if (0 > listen(serversocket, 5))
    {
                int temperrno = errno;
                perror("port announcer");
                exit(temperrno);
    }
    
    return serversocket;
}

void accept_socket_channel(server_socket, message)
int     server_socket;
char *message;
{
    struct sockaddr_in  clientaddress;
    int clientlength;
        int tempsocket;
    
    clientlength = sizeof(clientaddress);
    tempsocket = accept(server_socket, (struct sockaddr *) &clientaddress,
                                                &clientlength);
    if (0 > tempsocket)
    {
                int temperrno = errno;
                perror("port announcer");
                exit(temperrno);
    }

        write(tempsocket, message, strlen(message));
        close(tempsocket);

        return;
}

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

From: supat@nuntana.animal.uiuc.edu (Supat Faarungsang)
Subject: mouse error on 1.1.35
Date: 26 Jul 1994 14:21:46 GMT

Hi,

I got following errors on mouse (psaux2)
when compile kernel 1.1.36

Could anyone fix it?

THANKS,
supat
==============
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m486 -c psaux.c
/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)
/usr/src/linux/include/linux/timer.h:85: (Each undeclared identifier is reported only once
/usr/src/linux/include/linux/timer.h:85: for each function it appears in.)
make[2]: *** [psaux.o] Error 1
make[2]: Leaving directory `/usr/src/linux/drivers/char'
make[1]: *** [driversubdirs] Error 1
make[1]: Leaving directory `/usr/src/linux/drivers'
make: *** [linuxsubdirs] Error 1


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

From: johnsonm@calypso-2.oit.unc.edu (Michael K. Johnson)
Subject: Re: Realtime?
Date: 29 Jul 1994 03:29:13 GMT


In article <LEE.94Jul27220934@netspace.students.brown.edu> lee@netspace.students.brown.edu (Lee J. Silverman) writes:

           Just a quickie: does Linux 1.1.x have a realtime mode, say if
   one wanted to use a Linux box in a lab to gather data?  If not, could
   it?  I remember someone asking this way back when we were at 0.99pl14,
   and there might have been some hardware restriction on why it couldn't
   be done, but I can't remember now.

Linux doesn't do "realtime" where "realtime" is defined as having a
maximum latency and being able to respond to an interupt in a
guaranteed amount of time.  It it architecturally unsuited for that,
and it's not worth hacking it to support anything like that.  If you
need that kind of support, look into QNX (no, it's not free).

However, as long as you don't need that kind of support (if you don't,
please don't throw the word "realtime" around), Linux is not a bad
platform for gathering data.  Linux *does* have a lower latency than
most other OS's, and gives priority to reading data.  This was
originally to give a responsive feel, but is also handy for data
gathering.

There are apparantly patches for some sort of HPIB support floating
around somewhere but I know nothing about them, and that may not be
what you are looking for at all.  Best of luck!

michaelkjohnson

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

From: johnsonm@calypso-2.oit.unc.edu (Michael K. Johnson)
Crossposted-To: comp.unix.bsd
Subject: Re: APC UPS owners or potential buyers, trying to show user base
Date: 29 Jul 1994 03:38:53 GMT


In article <317k55$kq3@news.halcyon.com> mpdillon@coho.halcyon.com (Michael Dillon) writes:

   In article <316bjc$hlh@thor.tjhsst.edu>,
   Craig Metz <cmetz@thor.tjhsst.edu> wrote:
   >    I had a talk today with Debbie Gray (sp?) of American Power Conversion
   >regarding trying to get information on how to communicate with their Smart
   >UPS products' onboard controllers in order to write a Linux driver. APC is
   >one of the *many* manufacturers that plays the old NDA game, i.e., ``we
   >consider that to be proprietary information that we have to protect''. H

   Really now! Those boxes use an RS-232 interface, right? What do they tell 
   the computer? If they only communicate one thing (power fail) then it
   is probably something as simple as shorting the RD and SD lines. Get a
   technician to check it out for you while you pull the plug.

The "Back-UPS" do this.

   If they are giving more info than that, then it probably can be 
   reverse engineered with simple program to monitor the incoming 
   serial port.

The "Smart-UPS" are smarter.  I'll be getting one, and I'll try to
reverse-engineer it.  Heck, the person at APC that I talked to said it
would be fine if I wrote a program to do monitoring under Linux and
distributed it freely.  She didn't say anything about an NDA.  Of
course, I didn't ask for the details, either.  I will after I buy it,
and make a royal stink if they don't give them to me.  If I have to,
I'll get their unixware software, set up unixware (there's a spare
copy at work I could borrow, it's not installed anywhere because it
doesn't like the disk I offered it...) and monitor it.  strace is
available on unixware, too... :-)

Actually, I have iBCS2 installed, so I may be able to use that to
trace their cute software.  I don't want to trust their software to
shut down *my* machine, though; I'd write my own even if I used
unixware.  We'll see what happens.

   I remember a UPS that we set up about 7 years ago. I provided two terminals
   on the box that it shorted together when the power failed. We hooked
   them up to pins 2 and 3 on a serial port and made a little shell script
   daemon that periodically checked for powerfail every five minutes. When 
   it got two hits in a row, it shutdown the system.

That will work for their "Back-UPS", assuming you get the right
combination of pins.  I think that it is possible to talk back to the
"Smart-UPS".

I'd buy from a more open vendor, but APC is the *only* vendor with a
decent LI product with 900kva in my price range.  The next one is 1.5
times the cost, more than I can afford.

michaelkjohnson

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

From: lewis@ds9.lesn.lehigh.edu (Lewis Tanzos)
Subject: Re: 1.1.36 make problem: 'NULL' undeclared
Date: 28 Jul 1994 15:06:44 GMT

In article <94209.162137BTITMARS@ESOC.BITNET> BARRY TITMARSH <BTITMARS@ESOC.BITNET> writes:
>Interesting thread.. Ill have to print it all out.
>Ok I did: patch -p0 etc  patch36
>make dep && make  and i did not see this error at all?

Same here.  I did

cd /usr/src
patch -p0 < patch36
cd linux
make clean; make config
make dep; make clean
nohup make zImage &

and I got no warnings or errors in the nohup.out file (that I remember).

>i have 1.1.36 up running now for 23hrs no problems.
>must admit i did not do make clean first..

I did.  It compiled just fine.  I haven't run it yet, since I don't
always have physical access to the machine, and I'm not changing the
LILO default image until I'm sure about it.


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

From: jqb@netcom.com (Jim Balter)
Subject: Re: procps-0.95 broken -- problem is in linux/sched.h
Date: Tue, 26 Jul 1994 02:20:26 GMT

In article <3103hb$77e@agate.berkeley.edu>,
Nick Kralevich <nickkral@po.EECS.Berkeley.EDU> wrote:
>In article <jqbCtHFss.K4K@netcom.com>, Jim Balter <jqb@netcom.com> wrote:
>>>However, when I tried to compile it, I came up with these error 
>>>messages:
>>>
>>>In file included from /usr/include/linux/fs.h:15,
>>>                 from /usr/include/linux/sched.h:86,
>>>                 from testfile.c:1:
>>>/usr/include/linux/net.h:104: parse error before `select_table'
>>
>>I don't understand the difficulty.  The compiler told you, quite explicitly,
>>that testfile.c includes sched.h which includes fs.h which includes net.h,
>>and that net.h has an error on line 104 at the token "select"table".
>>select_table is obviously a typedef, and so it has to be defined before being
>>used.  
>
>If you reread the error statement, it says that there was a parse error 
>BEFORE select_table.  In fact, you wil notice that line 22 of net.h 
>has the include file for linux/wait.h, so your solution is obviously
>incorrect.
>
>>Grepping the headers show that it is in linux/wait.h, so that needs to
>>be included somewhere.  Why would that take 4 hours?  
>
>It took 4 hours because linux/wait.h WAS included in net.h, without
>me having to add it!  The problem is BEFORE select_table.

Arrgghhh!!  Despite the fact that the error is staring you straight in the
face, with a rather explicit error message, you spent 4 hours because
you saw one word, "before", and jumped to all sorts of conclusions of
what it means.  Of course the error is *before* select_error, because
the compiler needs a type to come *before* a parameter name in a prototype;
it thinks select_table is a parameter name, not a type, because the typedef
wasn't compiled.  Here, try this on for size:

echo "int a(int b, c);" > test.c
cc test.c

test.c:1: parse error before `c'

Do you get it now?

>The other suggestion about using -D__KERNEL__ during complies,
>however, did work.  But I thought that it should be reserved
>for when one is compiling the kernel.  Or perhaps it just
>means that it should be included when compiling code that 
>involves source code from the kernel.

-D__KERNEL__ causes the declaration of select_table in wait.h to be compiled;
without it the effect is the same as if net.h had not been included.

As I pointed out in another message, the use of ifdef __KERNEL__ is buggy;
if a typedef is protected by __KERNEL__, then all uses of that type must
also be protected.

>"A man sits with a pretty girl for an hour and it seems shorter than 
>a minute.  But tell that same man to sit on a hot stove for a minute, 
>it is longer than any hour.  That's relativity."  -- Einstein

I believe you are quoting the fictional character from the movie in which
Einstein and Marilyn Monroe meet, rather than the man himself.


"Perfection of means and confusion of goals seem--in my opinion--to
characterize our age." - Albert Einstein
-- 
<J Q B>

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

Subject: Realtime sound progr.
From: riku.saikkonen@compart.fi (Riku Saikkonen)
Date: Thu, 28 Jul 94 00:59:00 +0200

Is there a way to program /dev/dsp in 'real time'?

I.e. if one just write()s to the stream, the program is always a bit
(the length of the buffer in the soundcard driver, I presume) ahead of
the actual sound.

I'm thinking of a sound player with something (oscilloscope, FFT, or
something) displayed along with the sound in real time. Of course, it
kind of spoils the display if it's a few seconds ahead of the sound...

So, what I'd likely need is some way to get information from /dev/dsp
on how much there is left in the output buffer. Or a way to wait until
almost all output is finished.

The IOCTL SNDCTL_DSP_SYNC seems to wait for all output to finish (which
is too much; it causes a break in the sound...) and even reset the DMA
buffer (and cause clicks, at least on a SB, so I presume it shuts the
SB's speaker too). So it doesn't work...

One way would be to calculate the timing within the program and call
write() more rarely, but it would be kind of hard to implement,
especially since I don't know of fast, accurate timing functions. (Are
there any? Accurate to milli- or microseconds, I mean. Is setitimer()
accurate?)

-=- Rjs -=- riku.saikkonen@compart.fi - IRC: Rjs
GCS/L/M/TW/S -d+ H+ s:- !g !p !au a17 w+ v+(---) C++ UL++++() P+ L++
3 E N+++ K- W+(++) M- !V po Y+ t/Tolkien+++ !5 !j R G' tv-() b++ D++
B? e>+++ u+++@ h--! f+ !r>++ n+ !y+(*)


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


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