Linux-Development-Sys Digest #746, Volume #6     Wed, 26 May 99 15:14:18 EDT

Contents:
  Re: C  Header files (Kelly Burkhart)
  Re: Problems on booting a new compiled kernel (2.2.6) (Josef 
=?iso-8859-1?Q?M=F6llers?=)
  Re: LINUX ability to handle large beowulf clusters (Josef =?iso-8859-1?Q?M=F6llers?=)
  Creative SBLive! driver ? ("Jeremy Evans")
  Re: Modularizing loop device encryption filters (Jan Fredrik Leversund)
  Q: 2.2.7 cd-rom & scsi emulation support?
  Re: RedHat 6.0 SMP compile (David Fox)
  Re: [Q] time slice in SCHED_OTHER (Esben Haabendal Soerensen)
  Re: TCP/IP Libraries (Jens Kristian S�gaard)
  Terabite Plus Filesystems (Jake Maizel)
  _exit() and threads (Linux).  Broken? (Mike Romberg)
  structure alignment (gcc 2.7.2.3 on Linux) ([EMAIL PROTECTED])
  Re: Linux and Power Management (Moritz Franosch)
  NR_OPEN (1024*1024) (Jerry O'Keefe)

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

Subject: Re: C  Header files
From: Kelly Burkhart <[EMAIL PROTECTED]>
Date: 25 May 1999 22:49:16 -0500

neil <[EMAIL PROTECTED]> writes:

> Hi there all !
> I have a small problem  .I installed   redhat 5.2     okay  now i  want to
> test  my gcc   .   but it says  cannot fiond    <stdio.h>
> Hmm   okay so i did   a  :$find  /  -name  "stdio.h" -print  .So it  did
> not  find   a stdio.h file.What can be the  problem now.
> 
> Any help on this   would   be  very  nice.
> 
> 
> "Networks for the  People"
>                               by Anonymous   
> 
You need to install glibc-devel.  If I query rpm and grep for glibc I get this:

$ rpm -qa | grep glibc
glibc-devel-2.0.7-19
glibc-2.0.7-19
$

You most likely will get different results...

-- 
Kelly R. Burkhart
[EMAIL PROTECTED]

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

From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Subject: Re: Problems on booting a new compiled kernel (2.2.6)
Date: Wed, 26 May 1999 08:23:42 +0200

"Elias Penttil=E4" wrote:
> =

> Hi,
> I have this problem: when i've made my own kernel and i try to boot Lin=
ux
> with it, the LILO works, but when it tries to load Linux it hangs at
> 'Loading Linux'.
> Please help me.
> =

> Elias.

Can you give some information about the machine you're trying this on?
On certain SMP systems, LILO will shredder your MP config table.
Try LILO Version 2.2.

Josef
-- =

PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!

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

From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.advocacy
Subject: Re: LINUX ability to handle large beowulf clusters
Date: Wed, 26 May 1999 08:18:57 +0200

Jon Roberts wrote:
> =

> I was talking with a friend who is researching a supercomputer design
> that may become one of the top 10 machines in the world. I mentioned
> Beaowulf Linux clustering and the response was that Linux is good but
> can't support more than about 300 nodes in a cluster (and they plan on
> being larger than that). Is this true? If there IS a way around this
> limitation I'd like to know so I can make further recommendations for
> Linux to him.

There was a "Linux Cluster Event" run by a German TV station (WDR)
during its "ComputerNacht" event last december. See
http://www.uni-paderborn.de/cs/heiss/linux/cluster/artikel/cluster.html
(Sorry, but since the event is so long ago, there is little information
left, so all I could find was this German article)

They connected more than 512 Linux systems to solve some equations and
render a couple of films. Apparently they made it into the Guinness Book
of Records ...

Hope this helps,

Josef
-- =

PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!

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

From: [EMAIL PROTECTED] ("Jeremy Evans")
Subject: Creative SBLive! driver ?
Date: Wed, 26 May 1999 11:07:48 GMT

Is anyone working on or contemplating a driver for the Creative SBLive! 
soundcard ?

Jerry.

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

From: Jan Fredrik Leversund <[EMAIL PROTECTED]>
Subject: Re: Modularizing loop device encryption filters
Date: Wed, 26 May 1999 13:21:55 +0200
Reply-To: [EMAIL PROTECTED]

"J.H.M. Dassen (Ray)" wrote:
> From a cursory look at the kerneli patches, it seems that they allow several
> ciphers as dynamically loadable modules. I haven't looked into them in
> enough detail to see whether there is a cipher-independent module API (i.e.
> generic block-cipher API) in them.

There seem to be quite a lot of code related to specific cipher methods
in the generic cipher api (which kind of defies the purpose of a generic
api). Also, cipher module access relies on predefined method type
numbers, like these:

#define LO_CRYPT_NONE     0
#define LO_CRYPT_XOR      1
#define LO_CRYPT_DES      2
#define LO_CRYPT_FISH2    3
#define LO_CRYPT_BLOW     4
[snip]

All requests for a cipher method uses this type number, which
effectively means that even though the api may be generic, you still
have to make minor kernel changes to properly add your own cipher
method. This is partially (it seems) the reason why there is an
international version of the kernel constantly being maintained as new
regular kernels are released.

I believe it is possible to make it even more generic, and in a way that
also makes it unecessary to patch the mount/losetup/lomount utilities to
add a new cipher method. There is one thing that speaks in favour of the
current implementation: It is possible to override the predefined method
numbers by loading the cipher method into a "slot" different from the
predefined one.

For instance you can load the twofish [3] method into the blowfish [4]
slot. However, the tools you use for setting up your file system filters
use the #defines i mentioned earlier, still think that blowfish is at
slot [4], and they'll happily try to engage the twofish filter to
decrypt blowfish encrypted data. In effect a useless feature, one might
as well let the cipher method register itself to it's predefined slot.

One way of solving this is to create a new /proc file that contains a
list of method names, type number, key lengths, number of keys and
whatever you need. Naturally, the kernel would have to generate a type
number for each inserted method. This way the only modification needed
is to add support for the /proc file into the beforementioned utilities,
and they would automatically be able to use new methods.

Now for the punch line: If a adequately generic "tranformation"
interface is created, maintaining an additional international kernel
would be unecessary. It would simply suffice to keep the actual cipher
code out of the kernel distribution.

And while we're at it, lets stop calling it "cipher" and "crypto", it's
bound to tick some american department of something off.


--
Jan Fredrik Leversund ([EMAIL PROTECTED])
Consultant at Avenir (http://www.avenir.no)
Phone: +47-55360592, Cellular: +47-90198866
Address: Strimmelen 8, 5030 LAND�S, Norway

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

From: [EMAIL PROTECTED] ()
Subject: Q: 2.2.7 cd-rom & scsi emulation support?
Reply-To: [EMAIL PROTECTED] 
Date: 26 May 1999 13:18:58 +0100


hi,

did anyone succeed compiling 2.2.7 kernel with scsi emulation
 support, cd-rom support? i can't get through due to some
missing header files...

thanks,
-peter. 
-- 

Peter Cejchan
Institute of Geology, Academy of Science, Prague, CZ
<[EMAIL PROTECTED]>

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

From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: RedHat 6.0 SMP compile
Date: 26 May 1999 07:06:58 -0700

Lost the beginning of the thread here, but note that the header files
in the 6.0 kernel-headers RPM do not match the symbols in the 6.0 SMP
kernel.  This will cause problems when building kernel modules for an
SMP kernel.
-- 
David Fox           http://hci.ucsd.edu/dsf             xoF divaD
UCSD HCI Lab                                         baL ICH DSCU

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

Subject: Re: [Q] time slice in SCHED_OTHER
From: Esben Haabendal Soerensen <[EMAIL PROTECTED]>
Date: Wed, 26 May 1999 12:18:06 GMT

>>>>> "Soohyung" == Soohyung Lee <[EMAIL PROTECTED]> writes:

Soohyung> I want to know how long the time quantum(time slice) on the
Soohyung> SCHED_OTHER and SCHED_RR.  Is time quantum meaningful in
Soohyung> SCHED_OTHER and SCHED_RR.  What I say is 'How often the
Soohyung> context switching occurs' .

The default is 10ms and 1ms for Alpha.

Soohyung> Can I adjust this quantity, and if possible, how to ?

It should be possible to adjust this quantity, but you will experience
an increased overhead wasted on timer interrupts.

/bart
-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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

From: [EMAIL PROTECTED] (Jens Kristian S�gaard)
Subject: Re: TCP/IP Libraries
Date: 26 May 1999 02:40:19 +0200

"Mathew Verdouw" <[EMAIL PROTECTED]> writes:

> I am about to change our office server from NT4 (I spit on it) to RH6.0.
> The only obstacle is that I need to write a TCP/IP server for some custom
> software.  Can anyone point me to where I can find a TCP/IP library and/or
> examples.  My C is a little rusty, so I need some tips.

Why not use inetd, and then get rid of all this network code?

That way, your program will only use the normal stdin/stdout, and
inetd will do all the networking for you.


-- 
Jens Kristian S�gaard,
[EMAIL PROTECTED] -- http://soegaard.hypermart.net/

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

From: Jake Maizel <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: 
comp.os.ms-windows.nt.admin.misc,comp.sys.sun.admin,comp.sys.hp.misc,comp.os.linux.hardware
Subject: Terabite Plus Filesystems
Date: Wed, 26 May 1999 10:25:08 -0700

We are building a system that needs to handle a huge number of files 
that are 500KB-1MB in size (1-2TB total).  Our only constraint right now
is the desire to use intel-based hardware for the host computers for
cost purposes.  My question really is regarding which OS would best
handle a filesystem of this size.  We are using lots of unix and NT so
we don't have a bias one way but we don't have experience with any OS
using a filesystem this big.  What we are considering for hardware are
HP LPr hosts connected to a AL-FC RAID system (probably HP).  We would
want to pick either HPUX, linux, NT or Solaris x86.   Any experience
that could be passed would be great.

jake

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

From: Mike Romberg <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.programming.threads
Subject: _exit() and threads (Linux).  Broken?
Date: 26 May 1999 11:14:28 -0600


 Here is a simple C++ program that shows a possible problem with calling
_exit() in a signal handler for a multithreaded program.  
It creates a number of threads that increments a global counter.  
Each thread inherits a global signal handler for numerous signals
including SIGSEGV.  

Each thread runs the same code.  In the threads, I inserted a few lines
that will cause a segmentation violation.  On Linux, if the signal
handler calls  _exit() when it receives SEGV, the process doesn't 
terminate like it should, and its almost like _exit() is completely 
ignored!  The process continues normally even though it encounters 
_exit() multiple times.  This does not happen under HPUX-10.20 
(dce threads).

Anyways, I found a work around.  It seems like a big-time hack, but it 
works every time.  Instead of calling exit() or _exit(), I call
raise (SIGKILL) which is safe to call in a signal handler (I think.)

Its quite easy to verify the _exit() problem.  Compile the attached
program with the -D_REENTRANT switch, and link it with the pthread
library.  The usage of the program is
     tstThreads <num threads> <quit val> <delay>

The args are not that important since we are crashing the program.
Use something like tstThreads 20 10000 0.1

Thanks a lot for your help!


#include <pthread.h>      // pthread_*()
#include <iostream.h>     // cout, cerror
#include <sys/time.h>     // select()
#include <sys/types.h>
#include <unistd.h>       // sleep()
#include <signal.h>        
#include <stdio.h>        // perror(), sscanf, strerror
#include <stdlib.h>       // atol()
#include <string.h>       // strerror()
#include <errno.h>        // errno

// Variables that will be shared among all threads.
static long quitValue;
static long currentValue = 0;
static float delay = 0.0;
static pthread_mutex_t *globalLock;

void handleSignal (int sig)
    {
    // Tell the user that the signal arrived, and terminate if
    // necessary.  
    switch (sig)
        {
        case SIGHUP:
            exit(1);
        case SIGSEGV:
            _exit(1);    
        case SIGINT:
            exit(1);
        case SIGTERM:
            exit(0);
        case SIGQUIT:
            exit(0);
        case SIGALRM:
            break;
        case SIGPROF:
            break;
        case SIGURG:
            break;    
        case SIGUSR1:
            break;
        case SIGUSR2:
            break;
        default:
                 ;
        }
    }

// Simple thread that continually trys to increment the current value
// by its arg until the current value exceeds the quit value.
static void* simpleThread (void* arg)
    {
    // Convert the floating point delay to a struct that select()
    // understands.
    struct timeval delayStruct;
    long timeOutMicroSecs = (long) (delay * 1000000);


#ifdef PTHREADS_DRAFT4
    // Asynchronous signals we want to catch:
    static int asyncSignals[] = {SIGHUP, SIGINT, SIGTERM, SIGQUIT,
                                 SIGALRM, SIGPROF, SIGURG, SIGSEGV/*,
                                 SIGUSR1, SIGUSR2*/};
    static const int NUM_ASYNC_SIGNALS =
    (sizeof asyncSignals / sizeof(int));
    struct sigaction signalAction;
    sigemptyset (&signalAction.sa_mask);
    signalAction.sa_flags   = 0;
    signalAction.sa_handler = handleSignal;
    for (int eachSig = 0; eachSig < NUM_ASYNC_SIGNALS; ++eachSig)
        if (sigaction(asyncSignals[eachSig], &signalAction, 0) == -1)
            cerr << "Cannot install handler for signal "
                 << asyncSignals[eachSig] << " "
                 << strerror (errno) << endl;
#endif
    
    short *numToAdd = (short*)arg;

    cout << "About to crash thread: " << pthread_self() << endl;
    int *crash;
    *crash = 47;
    
    for (;;)
        {
        // Wait to access the current value.
        pthread_mutex_lock (globalLock);

        // Increment the current value.
        cout << "Adding " << *numToAdd << " to " << currentValue << endl;
        currentValue += *numToAdd;
 
        // Are we finished?
        if (currentValue > quitValue)
            {
            cout << "Thread " << *numToAdd << " was the last to execute."
                 << endl;
            exit(0);
            }
        pthread_mutex_unlock (globalLock);

        // Put a little time between unlocking and locking to give
        // someone else a try.
        delayStruct.tv_sec = (time_t) (timeOutMicroSecs / 1000000);
        delayStruct.tv_usec = timeOutMicroSecs % 1000000;
        select (0, 0, 0, 0, &delayStruct);
        }
    
    // Exit the thread.
    return 0;
    }

int main(int argc, char** argv)
    {
    // Parse the args.
    if (argc != 4)
        {
        cerr << "Usage: " << argv[0]
             << " <num threads> <quit val> <delay> " << endl;
        exit (1);
        }
    long numThreads = atol (argv[1]);
    quitValue = atol (argv[2]);
    sscanf (argv[3], "%f", &delay);

    // We want to use default attributes for both the threads and the mutex.
    // Syntax is different between Draft 4 and final standard.
#ifdef PTHREADS_DRAFT4
    #define DEFAULT_ATTRIBUTES pthread_attr_default
    #define DEFAULT_MUTEX_ATTRIBUTES pthread_mutexattr_default
#else
    #define DEFAULT_ATTRIBUTES NULL
    #define DEFAULT_MUTEX_ATTRIBUTES NULL
#endif

    // Create a mutex that will be used by all threads.
    globalLock =  new pthread_mutex_t;
    pthread_mutex_init (globalLock, DEFAULT_MUTEX_ATTRIBUTES);

    // Asynchronous signals we want to catch:
    static int asyncSignals[] = {SIGHUP, SIGINT, SIGTERM, SIGQUIT,    
                                 SIGALRM, SIGPROF, SIGURG, SIGSEGV/*,
                                 SIGUSR1, SIGUSR2*/};
    static const int NUM_ASYNC_SIGNALS =
    (sizeof asyncSignals / sizeof(int));

    // Use sigaction() to install our handler (handleSignal()) for each of
    // the above signals.
    struct sigaction signalAction;
    sigemptyset (&signalAction.sa_mask);
    signalAction.sa_flags   = 0;
    signalAction.sa_handler = handleSignal;
    for (int eachSig = 0; eachSig < NUM_ASYNC_SIGNALS; ++eachSig)
        if (sigaction(asyncSignals[eachSig], &signalAction, 0) == -1)
            cerr << "Cannot install handler for signal "
                 << asyncSignals[eachSig] << " "
                 << strerror (errno) << endl;

    // Allocate the arguments on the heap since they will be passed to
    // the threads.
    short *threadArgs = new short [numThreads];

    // Create and detach the specified number of threads.  Pass the
    // thread its index + 1, for its argument.
    for (int i = 0; i < numThreads; i++)
        {
        threadArgs[i] = i + 1;
        pthread_t thread;
        if (pthread_create(&thread, DEFAULT_ATTRIBUTES, simpleThread,
            &threadArgs[i])
            == -1)
            {
            cerr << "pthread_create() failed: "
                 << strerror(errno) << endl;
            exit (1);
            }
        #ifdef PTHREADS_DRAFT4
        if (pthread_detach(&thread) == -1)
        #else
        if (pthread_detach(thread) == -1)
        #endif    
            {
            cerr << "pthread_detach() failed: "
                 << strerror(errno) << endl;
            exit (1);
            }
        }

    // The main thread should wait forever, but not use any CPU time.
    // We will exit this process through the signal handler.
    while (true)
        if (select (0, 0, 0, 0, 0) == -1 && errno != EINTR)
            break;
    }

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

From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.questions,gnu.gcc
Subject: structure alignment (gcc 2.7.2.3 on Linux)
Date: Wed, 26 May 1999 16:56:44 GMT

I am porting code from a 16-bit windows platform to Linux.  Much of
the code actually came from 80386 assembly and was ported from that to
16-bit windows.  This history has given me a lot of code that is not
portable in nature and must either be rewritten (a LOT of work) or
handled properly.

One of my problems is the alignment of structures.  Much of the code
is written with the assumption of WORD alignment.  Now, many of my
structures are padded up to DWORD alignment and it is breaking the
code.

(sorry for the cross-posting, but I received no responses with my
original post to gnu.gcc)

Question:
Is there a pragma or command-line option for gcc that will force WORD
alignment for structures either for individual structures or for all
structures in the code?

Question: (this is more for a Linux newsgroup)
If I force WORD alignment, will the kernel (2.0.36) or glibc (2.1.1)
interface break?

Question: (last one)
Would a different version of gcc (or egcs) be any better?


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

From: Moritz Franosch <[EMAIL PROTECTED]>
Subject: Re: Linux and Power Management
Date: 26 May 1999 20:12:53 +0200



"Jeffrey Noll" <[EMAIL PROTECTED]> writes:

>     My question is simply, is this possible? Once i detect this can I put
> both the HD and
> cpu/mb into standby mode (naturally assuming the mb supports it) and then
> wake it back up
> when i detect the car ignition?

Yes.
Enable advanced power management (APM) in der kernel configuration.
Disable SMP, APM will not work (properly) with SMP.

With 'apm -S' you can put the machine into standby mode. The CPU should 
stop then.
With 'hdparm -y' you can put the HDD into standby mode.

I could not put both the machine and the HDD into standby mode (if
anyone can, please mail me), but I could tell the BIOS to switch off
the HDD after let's say 15 minutes idle time. So when the machine goes
to standby the HDD goes to standby 15 minutes afterwards.

You can wake up the machine again with keyboard or mouse input.


Moritz

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

From: Jerry O'Keefe <[EMAIL PROTECTED]>
Subject: NR_OPEN (1024*1024)
Date: Wed, 26 May 1999 11:52:18 -0700

Redhat 6.0 2.2.5-15 kernel sources have NR_OPEN defined as (1024*1024)
in fs.h. This appears to come from a file in kernel-2.2.5-15.src.rpm
called
fdset-2.2.4.diff. I cannot find this patch in any of the kernel sources
at LinuxHQ, 2.2.5 to 2.3.3. This patch makes it possible to open more
than
the present standard of 1024 file handles. I tried redefing NR_OPEN,
NR_FILE
and FD_SETSIZE to larger sizes in 2.2.6-2.2.9, but this broke portmap
and which broke nfs.

So by question is, is this a RedHat only patch. and will it appear in
later
releases of Redhat kernels? or any new kernel?

 Thanks for any help



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


** 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: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to