Linux-Development-Sys Digest #205, Volume #8 Tue, 10 Oct 00 15:13:17 EDT
Contents:
Re: Most popular Linux development environment(s)? Graphical? (Johan Kullstam)
HELP: Snoop for Linux?.Exist? (Francesco Fondelli)
Re: Most popular Linux development environment(s)? Graphical? (Kevin Holbrook)
Re: Where do actual block device/disk read&writes end up in the kernel
("[EMAIL PROTECTED]")
Compile Failure ("John Hall")
LinuxThreads : problem with sigwait() ("Oliver Kowalke")
task queues: slower under kernel 2.2?? ("Dan Miller")
Determining what CPU is going to execute a thread from a program ("Miguel Angel
Rodriguez Jodar")
LinuxThreads : problem with thread specific data ("Oliver Kowalke")
Re: ext2 file size limit? ([EMAIL PROTECTED])
Re: Most popular Linux development environment(s)? Graphical? (jazz)
Re: task queues: slower under kernel 2.2?? (Andi Kleen)
Re: Compile Failure (Paul Kimoto)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Most popular Linux development environment(s)? Graphical?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 10 Oct 2000 10:28:30 -0400
[EMAIL PROTECTED] (jazz) writes:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > In our last episode (Sun, 08 Oct 2000 19:27:39 -0400),
> > the artist formerly known as jazz said:
> > >I'm thinking of switching from mac to Linux. If I did, what programming
> > >setup would I likely find myself using? Gnu? Is there anything with
> > >a graphical interface, esp. for the debugger, as in Codewarrior,
> > >where you see a window containg your code and you can clearly mark
> > >breakpoints and follow the program counter steping through your code?
> > >With windows for variables, stack tracing, etc.?
> >
> > You won't find one single tool for this...
> >
> > There are several debuggers based on GDB; look for DDD, Insight FE, Code
> > Medic, kdbg, HP Wildebeast.
> >
> > There are also a number of "IDEs" somewhat in the style of that
> > introduced by Borland, including XWPE, RHIDE, Source Navigator,
> > WipeOut, Code Crusader, KDevelop.
> >
> > Vis-a-vis editing/compiling software, it is common for programmers
> > to wish not to be dependent on the availability or lack thereof of
> > a particular "IDE"; it is common for programmers to be capable of
> > coping with the lack of any graphical environment whatsoever. This
> > is quite critical if you're trying to work with the kernel; there
> > may well not be enough of the system functioning to allow you to
> > have a GUI at all, and debugging in the kernel is Rather Special...
> >
> > It is not uncommon to use GNU Emacs as an "IDE on Steroids;" combining
> > it with "etags" provides consider power in editing code...
>
>
>
> I'm trying to understand your point. I CAN develop code using a command
> line interface, with gcc, emacs as an editor, and the command line
> debugger. But I find it primitive.
so why don't you stay in emacs? emacs is a great programming
environment.
use emacs to fire off make (M-x compile). jump to
errors (M-`).
use emacs for debugging (M-x gdb). let emacs control gdb, let it
bring up source files automatically and show you stepping through code
&c.
> I don't develop code for distribution;
> I develop code to do a particular job (usually experiment control or data
> analysis) in our lab, on a particular platform. I much prefer having a
> graphical user interface like Codewarrior with a graphical debugger that
> lets me see numerous lines of code in numerous functions in many windows
> at once, with a window for multiple variables, execution tracing, analysis
> tools to determine efficiency, a very good framework, etc etc etc.
>
> Why would I NOT want this?
indeed. your answer may be emacs.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: Francesco Fondelli <[EMAIL PROTECTED]>
Crossposted-To:
comp.protocols.tcp-ip,comp.os.linux,comp.os.linux.development.apps,comp.os.linux.networking
Subject: HELP: Snoop for Linux?.Exist?
Date: Tue, 10 Oct 2000 16:49:44 +0200
Hi all,
I'm interested in studying and analysing the "Berkeley Snoop protocol"
( http://www.cs.berkeley.edu/~hari/papers/snoop.html ) and I was
wondering if there is a specific implementation for Linux (I know only
the BSD/OS one.
Thanks for your time.
Francesco
please CC the mail also to [EMAIL PROTECTED]
------------------------------
From: Kevin Holbrook <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Most popular Linux development environment(s)? Graphical?
Date: Tue, 10 Oct 2000 10:18:05 -0500
jazz wrote:
>
> I'm trying to understand your point. I CAN develop code using a command
> line interface, with gcc, emacs as an editor, and the command line
> debugger. But I find it primitive. I don't develop code for distribution;
> I develop code to do a particular job (usually experiment control or data
> analysis) in our lab, on a particular platform. I much prefer having a
> graphical user interface like Codewarrior with a graphical debugger that
> lets me see numerous lines of code in numerous functions in many windows
> at once, with a window for multiple variables, execution tracing, analysis
> tools to determine efficiency, a very good framework, etc etc etc.
>
Well I won't jump into the IDE vs. Command-line debate,
especially since I work on a graphical IDE. ;-)
There are pro's and con's for each. I use XEmacs myself,
from time to time.
But, if you want CodeWarrior there is a CodeWarrior for Linux.
We are currently in beta testing for a new release.
==============================
Kevin Holbrook
Linux Developer
Metrowerks, a Motorola Company
------------------------------
From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Re: Where do actual block device/disk read&writes end up in the kernel
Date: Tue, 10 Oct 2000 17:42:53 +0200
Hi,
You are correct,
This is what linux and bsd call the strategy routines.
It used to go through a Elevator algorithm.
(This was done to speed up slow disk access)
No processing is done on the newer linux kernels.
Most of these functions are used in a request block in a block device driver.
./include/linux/blkdev.h
also check out z2ram.c in /src/linux/drivers.
(good example)
Richard.
Albert Siersema wrote:
> After some digging around I thought that actual read/write actions for
> block devices end up in ll_rw_block() in:
> /usr/src/linux/drivers/block/ll_rw_blk.c (independant of the physical
> device).
> make_request() there probably asks the lower half (hardware dependant
> driver)
> to perform the read/write ?
> Where does returned data from a completed read get back ?
> end_that_request_first() ?
>
> Is this correct and/or could someone enlighten me on the correct flow of
> block device read/writes through the kernel ?
> I've checked up on the various documents in the kernel Documentation tree as
> well as the documents linked from there but couldn't find an alltogether
> in-depth
> description.
>
> TIA,
> Albert
> (when replying by e-mail, and please do, strip the dot and capitalized
> section please)
------------------------------
From: "John Hall" <[EMAIL PROTECTED]>
Subject: Compile Failure
Date: Tue, 10 Oct 2000 16:15:01 GMT
Have compiled 2.3.99-pre9 and others [including doing backports and the
like] without problems. however on this box I am getting an error message
during the compile of a straight "out of the box" 2.3.99-pre9. I tried
wiping the source tree out and installing a "package" of RedHat's kernel
source "2.2.16" and I got the exact same message.
make mrproper [fine]
make menuconfig [fine]
make dep [fine]
make bzImage or make zImage both give me:
make[1]: Entering directory `/usr/src/linux/arch/i386/kernel'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/linux/arch/i386/kernel'
make -C arch/i386/mm
make[1]: Entering directory `/usr/src/linux/arch/i386/mm'
make all_targets
make[2]: Entering directory `/usr/src/linux/arch/i386/mm'
make[2]: Nothing to be done for `all_targets'.
make[2]: Leaving directory `/usr/src/linux/arch/i386/mm'
make[1]: Leaving directory `/usr/src/linux/arch/i386/mm'
make -C arch/i386/lib
make[1]: Entering directory `/usr/src/linux/arch/i386/lib'
make all_targets
make[2]: Entering directory `/usr/src/linux/arch/i386/lib'
gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -traditional -c
checksu
m.S -o checksum.o
checksum.S:238: badly punctuated parameter list in #define
checksum.S:244: badly punctuated parameter list in #define
make[2]: *** [checksum.o] Error 1
make[2]: Leaving directory `/usr/src/linux/arch/i386/lib'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/arch/i386/lib'
make: *** [_dir_arch/i386/lib] Error 2
[root@localhost linux]#
Sorry about the sloppy formatting.
I have installed gcc 2.96-54 and the latest mandrake cooker binutils. The
box is a clean install of redhat 7. I have updated various other things,
libc5 etc, but only to solve the problem which hasn't changed since a virgin
RH 7 install.
Any help is much appreciated.
http://moron.shutdown.com
------------------------------
From: "Oliver Kowalke" <[EMAIL PROTECTED]>
Subject: LinuxThreads : problem with sigwait()
Date: Tue, 10 Oct 2000 18:51:43 +0200
Hi,
I'm reading "Programming with POSIX Threads" from Butenhof. I have a problem
with the function 'sigwait()'.
my program : creates a thread which waits on SIGINT. If SIGINT is 5
times signaled it terminates.
the problem : The program create 3 processes. Why? I've never called
fork()!
my system : Debian Linux 2.2
glibc 2.1.3-10
Please, can you explain me the behaviour.
thx!
with regards,
Oliver
----> sigwait.c
<---------------------------------------------------------------------------
====================
#include <sys/types.h>
#include <unistd.h>
#include <pthread.h>
#include <signal.h>
#include "errors.h"
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
int interrupted = 0;
sigset_t signal_set;
/* Wait for the SIGINT signal. */
void * signal_waiter( void * arg)
{
int sig_number;
int signal_count = 0;
int status;
while ( 1)
{
sigwait( & signal_set, & sig_number);
if ( sig_number == SIGINT)
{
printf("Got SIGINT (%d of 5)\n", signal_count + 1);
if ( ++signal_count >= 5)
{
status = pthread_mutex_lock( & mutex);
if ( status != 0)
err_abort( status, "Lock mutex");
interrupted = 1;
status = pthread_cond_signal( & cond);
if ( status != 0)
err_abort( status, "Signal condition");
status = pthread_mutex_unlock( & mutex);
if ( status != 0)
err_abort( status, "Unlock mutex");
break;
}
}
else
printf("Got othe signal.\n");
}
return NULL;
}
int main( int argc, char * argv[])
{
pthread_t signal_thread_id;
int status;
sigemptyset( & signal_set);
sigaddset( & signal_set, SIGINT);
status = pthread_sigmask( SIG_BLOCK, & signal_set, NULL);
if ( status != 0)
err_abort( status, "Set signal mask");
/* Create the sigwait thread. */
status = pthread_create( & signal_thread_id, NULL, signal_waiter, NULL);
if ( status != 0)
err_abort( status, "Create sigwaiter");
/* Wait for the sigwait thread to receive SIGINT and signal the condition
variable. */
status = pthread_mutex_lock( & mutex);
if ( status != 0)
err_abort( status, "Lock mutex");
while( !interrupted)
{
status = pthread_cond_wait( & cond, & mutex);
if ( status != 0)
err_abort( status, "Wait for interrupt");
}
status = pthread_mutex_unlock( & mutex);
if ( status != 0)
err_abort( status, "Unlock mutex");
printf("Main terminating with SIGINT\n");
return 0;
}
--> errors.h
<---------------------------------------------------------------------------
---
#ifndef __ERRORS_H
#define __ERRORS_H
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef DEBUG
#define DPRINTF( arg) printf arg
#else
#define DPRINTF( arg)
#endif
#define err_abort(code,text) \
do \
{ \
fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
strerror( code) ); \
abort(); \
} while ( 0)
#define errno_abort(text) \
do \
{ \
fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
strerror( errno) ); \
abort(); \
} while ( 0) \
#endif // __ERRORS_H
------------------------------
From: "Dan Miller" <[EMAIL PROTECTED]>
Subject: task queues: slower under kernel 2.2??
Date: Tue, 10 Oct 2000 10:04:19 -0700
I have a driver that I'm porting from kernel 2.0.36 to 2.2.12. The receive
ISR uses a task queue to schedule copying of a data buffer from our PCI card
to kernel memory.
I have a high-speed timer card that lets me take system measurements with 5
usec resolution. Under kernel 2.0, the time between calling
queue_task(&info->task, &tq_immediate) until the BH handler was called ran
from 13 to 700 usec, average 150 usec. However, under kernel 2.2, this time
runs 13 to 5200 usec, average 250!!! Why is it so much slower?? My overall
data transfer rates are about 7% slower, and this is the only difference I
can find (at least, within my driver), so I'm suspecting that this is the
cause of my problem...
Alternately, is there some other mechanism other than task queues that I can
use to signal a BH handler, without having such a delay??
Dan Miller
------------------------------
From: "Miguel Angel Rodriguez Jodar" <[EMAIL PROTECTED]>
Subject: Determining what CPU is going to execute a thread from a program
Date: Tue, 10 Oct 2000 18:48:47 +0200
Hi all!
Is possible to indicate to the kernel which CPU, in a multiprocessor system,
must accept a thread we want to launch using fork(), clone() or
phread_create() or whatever?
Does exist a system call that can return us the number of active CPU's in a
system?
Thanks in advance!
Miguel Angel
------------------------------
From: "Oliver Kowalke" <[EMAIL PROTECTED]>
Subject: LinuxThreads : problem with thread specific data
Date: Tue, 10 Oct 2000 19:05:56 +0200
Hi,
I'm reading "Programming with POSIX Threads" from Butenhof. I have a problem
with thread specific data.
my program : creates two threads which have their thread specific
data. for each thread a thread spec. data destructor is called.
the problem : main thread calls also function
identity_key_destructor(). Why? The main thread is not associated with
thread spec. data!
my system : Debian Linux 2.2
glibc 2.1.3-10
Please, can you explain me the behaviour.
thx!
with regards,
Oliver
--> tsd_destructor.c <---------------------------------------------
#include <pthread.h>
#include "errors.h"
/* Structure used as value of thread-specific data key. */
typedef struct private_tag
{
pthread_t thread_id;
char * string;
} private_t;
pthread_key_t identity_key; /* thread-specififc data key */
pthread_mutex_t identity_key_mutex = PTHREAD_MUTEX_INITIALIZER;
long identity_key_counter = 0;
/* This routine is called as each thread terminates with a value for the
thread-specific data key.
It keeps track of how many threads still have values, and deletes the key
when there are no more
referneces. */
void identity_key_destructor( void * value)
{
private_t * private = ( private_t * )value;
int status;
printf("thread \"%s\" exiting ...\n", private->string);
free( value);
status = pthread_mutex_lock( & identity_key_mutex);
if ( status != 0)
err_abort( status, "Lock key mutex");
identity_key_counter--;
printf("thread_id: %ld\n", pthread_self() );
if ( identity_key_counter <= 0)
{
status = pthread_key_delete( identity_key);
if ( status != 0)
err_abort( status, "Delete key");
printf("key deleted ...\n");
}
status = pthread_mutex_unlock( & identity_key_mutex);
if ( status != 0)
err_abort( status, "Unlock key mutex");
}
/* Helper routine to allocate a new value for thread-specific data key if
the thread doesn't already
have one. */
void * identity_key_get( void)
{
void * value;
int status;
value = pthread_getspecific( identity_key);
if ( value == NULL)
{
value = malloc( sizeof( private_t) );
if ( value == NULL)
errno_abort("Allocate key value");
status = pthread_setspecific( identity_key, ( void * )value);
if ( status != 0)
err_abort ( status, "Set TSD");
}
return value;
}
/* Thread start routine to use thread-specific data. */
void * thread_routine( void * arg)
{
private_t * value;
value = ( private_t * )identity_key_get();
value->thread_id = pthread_self();
value->string = ( char * )arg;
printf("thread \"%s\" starting ...\n", value->string);
sleep( 2);
return NULL;
}
int main( int argc, char * argv[])
{
pthread_t thread_1, thread_2;
private_t * value;
int status;
printf(" main thread_id: %ld\n", pthread_self() );
/* Create the TSD key, and set the reference counter to the number of
threads that will use it. */
status = pthread_key_create( & identity_key, identity_key_destructor);
if ( status != 0)
err_abort( status, "Create key");
identity_key_counter = 3;
value = ( private_t * )identity_key_get();
value->thread_id = pthread_self();
status = pthread_create( & thread_1, NULL, thread_routine, "Thread 1");
if ( status != 0)
err_abort( status, "Create thread 1");
status = pthread_create( & thread_2, NULL, thread_routine, "Thread 2");
if ( status != 0)
err_abort( status, "Create thread 2");
pthread_exit( NULL);
}
--> errors.h
<---------------------------------------------------------------------------
===============
#ifndef __ERRORS_H
#define __ERRORS_H
#include <unistd.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef DEBUG
#define DPRINTF( arg) printf arg
#else
#define DPRINTF( arg)
#endif
#define err_abort(code,text) \
do \
{ \
fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
strerror( code) ); \
abort(); \
} while ( 0)
#define errno_abort(text) \
do \
{ \
fprintf( stderr, "%s at \"%s\":%d: %s\n", text, __FILE__, __LINE__,
strerror( errno) ); \
abort(); \
} while ( 0) \
#endif // __ERRORS_H
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.misc,comp.os.linux.advocacy,alt.os.linux
Subject: Re: ext2 file size limit?
Date: Tue, 10 Oct 2000 18:03:38 GMT
In article <[EMAIL PROTECTED]>,
Andreas Jaeger <[EMAIL PROTECTED]> wrote:
> >>>>> jdavida writes:
>
> > I am runnign Linux 2.4 and it supports
> > files > 2GB. See /usr/include/bits/stat.h
> > and look at struct stat64, which supports file size
> > up to 1 TB (always half of max filesystem size), because
> > file size is a signed data type.
> > You will have to define
> > __USE_LARGEFILE64 when you create the file with
> Check <features.h> - __USE_LARGEFILE64 cannot be defined by user
> space
Correct. You should define
#define _LARGEFILE64_SOURCE 1
instead. This define should come before
including the header files. This will
enable the use of large files greater than
2 Gig. Unfortunately, user commands and utils
like ls(1) and stat(1) will not work: See the
following:
# ls -l
/bin/ls: BIG4GIG: Value too large for defined data type
/bin/ls: BIG4GIG2: Value too large for defined data type
total 0
Both of these files are 4gigabytes large!!
I created them by a simple program that
wrote a large buffer to the file in a loop
that brought the size to 4 gig, and exited
normally.
Cheers,
Joe
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (jazz)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Most popular Linux development environment(s)? Graphical?
Date: Tue, 10 Oct 2000 14:49:24 -0400
In article <[EMAIL PROTECTED]>, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
>
> so why don't you stay in emacs? emacs is a great programming
> environment.
>
> use emacs to fire off make (M-x compile). jump to
> errors (M-`).
>
> use emacs for debugging (M-x gdb). let emacs control gdb, let it
> bring up source files automatically and show you stepping through code
> &c.
>
I guess emacs can do a lot more than I thought. Do you know where I can
find a good book on using emacs like this, preferably with a tutorial? I
have the gnu reference somewhere but haven't looked at it in a while, as I
recall it is more like a reference, I want something that will step me
through all the features, functions, tricks, etc...
Thanks
Jazz
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: task queues: slower under kernel 2.2??
Date: 10 Oct 2000 20:45:57 +0200
"Dan Miller" <[EMAIL PROTECTED]> writes:
> I have a driver that I'm porting from kernel 2.0.36 to 2.2.12. The receive
> ISR uses a task queue to schedule copying of a data buffer from our PCI card
> to kernel memory.
>
> I have a high-speed timer card that lets me take system measurements with 5
> usec resolution. Under kernel 2.0, the time between calling
> queue_task(&info->task, &tq_immediate) until the BH handler was called ran
> from 13 to 700 usec, average 150 usec. However, under kernel 2.2, this time
> runs 13 to 5200 usec, average 250!!! Why is it so much slower?? My overall
> data transfer rates are about 7% slower, and this is the only difference I
> can find (at least, within my driver), so I'm suspecting that this is the
> cause of my problem...
>
> Alternately, is there some other mechanism other than task queues that I can
> use to signal a BH handler, without having such a delay??
First your terminology seems to be completely confused. A task queue and a
BH are different things.
If you want to make sure that IMMEDIATE_BH is executed as soon as possible
you probably need a mark_bh(IMMEDIATE_BH) in the interrupt handler.
-Andi
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Compile Failure
Date: 10 Oct 2000 15:01:34 -0500
Reply-To: [EMAIL PROTECTED]
In article <9gHE5.24352$[EMAIL PROTECTED]>, John Hall wrote:
> Have compiled 2.3.99-pre9 and others [including doing backports and the
> like] without problems. however on this box I am getting an error message
> during the compile of a straight "out of the box" 2.3.99-pre9.
> gcc -D__ASSEMBLY__ -D__KERNEL__ -I/usr/src/linux/include -traditional -c
> checksum.S -o checksum.o
> checksum.S:238: badly punctuated parameter list in #define
> checksum.S:244: badly punctuated parameter list in #define
> I have installed gcc 2.96-54
... which has a new preprocessor (among other features, and the whole thing
is as yet unreleased) that does not get along with the way that the kernel
has been written in the past. There are supposed to be some fixes in the
latest development kernel, which is 2.4.0-test9 (or -test10-pre1).
(2.4.0-test1 was available 4.5 months ago!)
Or you could use an older (gcc-2.95.* or egcs-1.1.*) version of the
compiler. They say that RH 7.0 has one (re)named "kgcc".
--
Paul Kimoto
This message was originally posted on Usenet in plain text. Any images,
hyperlinks, or the like shown here have been added without my consent,
and may be a violation of international copyright law.
------------------------------
** 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
******************************
