Linux-Development-Sys Digest #837, Volume #7 Tue, 9 May 00 14:13:21 EDT
Contents:
Re: sourcecode of ps command ([EMAIL PROTECTED])
Race conditions in driver select and poll methods ("Peter A. Kroon")
Re: rise amount of file descriptors (Ratz)
Re: pid vs. thread question (Mikko Rauhala)
Re: pid vs. thread question (Zoran Cutura)
Re: How to get currently open tcp connections (Zoran Cutura)
Re: sourcecode of ps command (Paul Kimoto)
Timeout on Mutex (Colin Ford)
Kernel compilation of RH 6.2 gives same major, minor numbers to hda, and (Rohit
Samson Dean)
Re: How to get currently open tcp connections (Dr H. T. Leung)
Re: Real Time Programming in Linux (Rene van Paassen)
Re: pid vs. thread question (James Cownie)
What cockheads you are ("www.homepagewizard.com")
Re: Kernel compilation of RH 6.2 gives same major, minor numbers to (David Weis)
Re: Sys Calls from Device Drivers (Marc SCHAEFER)
Apply the dvd-cd Patch. (jesper)
Re: Race conditions in driver select and poll methods (Kaz Kylheku)
Re: DNS problem (Steve)
Re: Timeout on Mutex (Kaz Kylheku)
** gdb Question ("Quang Nguy��")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: sourcecode of ps command
Date: Tue, 09 May 2000 09:09:05 GMT
In article <[EMAIL PROTECTED]>,
Allin Cottrell <[EMAIL PROTECTED]> wrote:
> Paul Kimoto wrote:
>
> > This is only marginally topical for c.o.l.d.system.
>
> Nice try. But since when has that stopped anyone from posting
> here?
Thanks for Pauls and Allins information.
I thought this would be a suitable place to ask, as here are the people,
who take part in developping the system.
Sorry,
Irgei
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Peter A. Kroon" <[EMAIL PROTECTED]>
Subject: Race conditions in driver select and poll methods
Date: Tue, 9 May 2000 11:58:46 +0200
In the Linux Device Drivers book of Rubini, the problem of avoiding race conditions is
discussed.
In the section "Going to Sleep Without Races" (pages 203-210) two methods are given to
avoid the problem that between testing if
data is available, and calling interruptible_sleep_on () an interrupt may occur,
causing a race condition.
The methods given there, work fine in the driver's read and write methods, but we
don't see how they can be applied to the select or
poll methods.
Rubini's approach is, instead of calling interruptible_sleep_on(), the code in this
function is written out, and the sequence of
testing, adding ourselves to a wait queue, setting TASK_INTERRUPTIBLE and calling
schedule() is slightly re-ordered so that the race
condition is avoided.
But in select or poll, there is no such call to a sleep or schedule routine; instead
if none of the files specified in the select
mask has data available, it is the kernel who calls schedule. In our opinion this can
also lead to the same race condition as in
read and write.
We have the feeling that calling cli() before the race condition could occur, is not a
good thing to do here.
Any idea if we are right or wrong, and if right, how such a race condition can be
avoided in the select or poll methods?
Thanks,
Peter Kroon.
------------------------------
From: Ratz <[EMAIL PROTECTED]>
Subject: Re: rise amount of file descriptors
Date: Tue, 09 May 2000 12:20:42 +0200
Hi Irgei,
> In article <[EMAIL PROTECTED]>,
> Ratz <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > I need to raise the amount of file descriptors under kernel 2.2.x.
> > I tried to play with the sysctrl variables /proc/sys/fs/file-max,
> > /proc/sys/fs/file-nr but I can't get more than 4096 open file-
> > descriptors. I guess this is defined somewhere in the kernel sources
> > but I couldn't find it, nor am I sure if I'm looking at the right
> > place. Could someone be so kind to point me to the right source
> > or docu?
>
> For using IBM MQSeries the following is suggested:
> echo 32768 > /proc/sys/file-max
> echo 65536 > /proc/sys/inode-max
> So I wonder, why it doesn't work in your case...
>
Thanks for your reply, however, I made a bad mistake. I was looking
for a 2.0.x system and /not/ 2.2.x. I remember having seen a patch
from the apache mailing list. The problem is actually to focus a
little bit (might be offtopic), that apache forks for each virtual
hosts entry. Unfortunately I've got a configuration which has some
thousands of such entries. I know there was a patch somewhere, but
I couldn't find it anymore. I also don't really see the rapport
between a change of file-max and it's impact on the inodes.
Thank you anyway for your reply!
ratz
------------------------------
From: [EMAIL PROTECTED] (Mikko Rauhala)
Subject: Re: pid vs. thread question
Date: 9 May 2000 11:04:09 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 May 2000 23:09:49 -0700, Eric Taylor <[EMAIL PROTECTED]> wrote:
>I've read that 2 or more processes can have the
>same pid. If this is true, then does this mean
>that everything I might try to do that is pid
>based, like signals, affect all processes with
>the same pid?
It's not. Well, the kernel uses that feature for something, I don't quite
recall what, but anyway, for user processes, a process always has a unique
pid. The same applies for those processes that happen to share their file
descriptors and virtual memory and such (that is, threads).
>Is the reason for the same pid feature to support
>threads?
It was, iirc, proposed at some point that separate tids would be
used to identify threads so that a multithreaded process would be
identifiable as a single pid, but that never caught wind.
>If threads are implemented as a group of processes
>that share resources, I wonder how it handles
>opening files, or mallocs (if it needs to extend
>memory) getting propogated to all the other
>processes (threads?).
They are. I don't know how they work, precisely, but I would assume
that the processes simply share the same memory mappings and open file
tables and such.
>When sending a signal from one proc to another on
>a "kernel supported thread" model, does the signal go to all
>threads or just one thread (if so which one)? How would
>that map into the linux implementation?
It goes to the thread which was referenced, since all the threads have
their unique pids. This behaviour is non-standard according to the
posix thread spec. There have been some proposals, I believe, to correct
this situation, but this is how it is now.
>Is there any other kernel support for threads,
>is pthreads really just a posix library magic trick that
>makes it look like linux has a kernel supported thread
>model?
Linux has a kernel supported thread model. Threads are just treated like
any other processes, they just happen to share some resources. As a model,
imo, it's cleaner than treating threads and processes separately.
The LinuxThreads library does do some trickery to stick the posix api on
top of that as best it can, though, but that's another story.
--
Mikko Rauhala - [EMAIL PROTECTED] - http://www.iki.fi/mjr/
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: pid vs. thread question
Date: Tue, 09 May 2000 13:36:36 +0200
Eric Taylor wrote:
>
> I've read that 2 or more processes can have the
> same pid. If this is true, then does this mean
> that everything I might try to do that is pid
> based, like signals, affect all processes with
> the same pid?
I suspect this wording is not merrily explicit.
One process is attached to one pid! There can be
processes running more than one thread, which is
probably what you meant. These threads get thread id's
ideally. There are differnt sorts of threading
implementations!
>
> Is the reason for the same pid feature to support
> threads?
>
> If threads are implemented as a group of processes
> that share resources, I wonder how it handles
> opening files, or mallocs (if it needs to extend
> memory) getting propogated to all the other
> processes (threads?).
>
> When sending a signal from one proc to another on
> a "kernel supported thread" model, does the signal go to all
> threads or just one thread (if so which one)? How would
> that map into the linux implementation?
>
> Is there any other kernel support for threads,
> is pthreads really just a posix library magic trick that
> makes it look like linux has a kernel supported thread
> model?
As much as I know, in Linux there is a implementation
for threads with the clone system call, which is used
by the pthread calls!
>
> thanks
> eric
Z
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: How to get currently open tcp connections
Date: Tue, 09 May 2000 13:38:23 +0200
[EMAIL PROTECTED] wrote:
>
> Hello,
>
> I would like to know the number or info of the currently opend tcp
> connections through kernel space..Is there any api to retrieve this ?
>
> Bhagyashree
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Have you considered to look at the netstat utility?
Z
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: sourcecode of ps command
Date: 9 May 2000 07:42:41 -0500
Reply-To: [EMAIL PROTECTED]
In article <8f8kja$hep$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I thought this would be a suitable place to ask, as here are the people,
> who take part in developing the system.
For the purpose of Linux, the "system" means the kernel and things directly
connected to it. And these days only the occasional kernel developer posts
here.
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: Colin Ford <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Timeout on Mutex
Date: Tue, 09 May 2000 13:17:37 +0100
Hi There,
is there anyway to implement a timeout call
on a mutex get?
All I could think of was to start a kill alarm
before the call. Would this work and if so is
it safe?
Col.
------------------------------
From: Rohit Samson Dean <[EMAIL PROTECTED]>
Subject: Kernel compilation of RH 6.2 gives same major, minor numbers to hda, and
Date: Tue, 09 May 2000 10:56:06 -0400
Hi,
I tried to compile Linux Kernel 2.2.14-5.0 which came on the RH 6.2
distribution, and then when I tried to boot the machine, it coudn't
mount my fat32 partition at boot time or even later. The error it gave
is that the device is using a major/minor number combination which is
already in use. After lookiing at ls /dev, I found out that /dev/ttyp2
had a major, minor device number combination of 3, 2 which is the same
as /dev/hda2 (which is where my fat32 resides).
In fact /dev/ttyp? has a major device number of 3 which is the same as
the major device number of /dev/hda?.
This doesn't seem to be the case with the pre-compiled kernel shipping
with this distribution.
I have 2 questions
Questtion #1.
Why is this error coming up only when trying to mount the fat32
partition (because other ext partitions /dev/hda[1,3-7] are getting
mounted properly even though they have the same major/minor device
number combinations as /dev/ttyp[1-7]).
Question #2.
What can I do to avoid this? Is there an environment variable or #define
which I can set to tell the kernel makefile the major device numbers for
the tty/hda device?
Thanx in advance
Rohit Samson Dean
P.S. If replying to me directly - remove NOSPAM from the reply-to
address.
------------------------------
From: [EMAIL PROTECTED] (Dr H. T. Leung)
Subject: Re: How to get currently open tcp connections
Date: 9 May 2000 15:11:10 GMT
I have no idea whether there is any api for that, but I know
(1) "netstat -n -a" gives exact that info away
(2) the information is also all under /proc, somewhere, probably /proc/net/*.
In article <8f8eqq$bhh$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
|> Hello,
|>
|> I would like to know the number or info of the currently opend tcp
|> connections through kernel space..Is there any api to retrieve this ?
|>
|> Bhagyashree
|>
|>
|> Sent via Deja.com http://www.deja.com/
|> Before you buy.
--
--------------------------------------------------
"What you don't care cannot hurt you." Chap. 7a, AMS-NS
------------------------------
From: Rene van Paassen <[EMAIL PROTECTED]>
Subject: Re: Real Time Programming in Linux
Date: 09 May 2000 17:46:32 +0200
Simon Wakley <[EMAIL PROTECTED]> writes:
> Thanks Erik,
>
> I tried using pthread_attr_setschedpolicy et al as in the following
> code. That did not work, and my thread still got de-scheduled for 300ms
> which is pretty bad! Did I do sthg wrong, or do I have to use rtlinux
> (or QNX).
>
> I started my code as a thread sharing the same code space and did not
> want to start it as a totally separate process. (Am I losing out here??)
>
>
> void make_thread(void)
> {
> int code;
> pthread_attr_t attr;
> int policy = SCHED_RR;
> void *tick_tock_arg;
> pthread_t thread;
> pthread_attr_init(&attr);
> attr.__schedpolicy = 99; // Tried 30, 50, 90 - none work
^^ better use the supplied calls
> pthread_attr_setschedpolicy(&attr, policy);
OK, you could also use SCHED_FIFO
>
> code = pthread_create(&thread, &attr, tick_tock, tick_tock_arg);
> //code = pthread_create(&thread, NULL, tick_tock, tick_tock_arg);
>
> if (code == 0)
> printf("Thread creation OK \n");
> else
> {
> printf("Thread creation failed %d - ", code);
> switch (code)
> {
> case 1 : printf("Not enough resources ? Not root? \n");
> break;
> default : printf("No idea %d \n", code);
> }
> }
> }
>
Some remarks:
2) You should also specify the priority,
sched_param schedpar;
schedpar.sched_priority = (sched_get_priority_max(SCHED_FIFO) -
sched_get_priority_min(SCHED_FIFO))/2;
pthread_attr_setschedparam(&attr, &schedpar);
1) did you check the scheduling policy and priority in the
new thread?
3) Did you run the code as root?, if you don't, you won't get
real-time priority
p.s. You don't have to be root to create threads, but you
do if you want them to run real-time.
20 ms shoud be no problem on a stock Linux and a reasonable machine.
Greetings,
Ren�
------------------------------
From: James Cownie <[EMAIL PROTECTED]>
Subject: Re: pid vs. thread question
Date: Tue, 09 May 2000 15:52:04 GMT
Mikko Rauhala wrote:
>
> On Mon, 08 May 2000 23:09:49 -0700, Eric Taylor <[EMAIL PROTECTED]> wrote:
> >I've read that 2 or more processes can have the
> >same pid. If this is true, then does this mean
> >that everything I might try to do that is pid
> >based, like signals, affect all processes with
> >the same pid?
>
> It's not. Well, the kernel uses that feature for something, I don't quite
> recall what,
I believe it is used so that each CPU in an SMP machine can have its own idle process
while letting all of them have the same pid.
Since the idle process is rather special having more than one of them with
the same pid doesn't cause a problem.
-- Jim
James Cownie <[EMAIL PROTECTED]>
Etnus, Inc. +44 117 9071438
http://www.etnus.com
------------------------------
From: "www.homepagewizard.com" <[EMAIL PROTECTED]>
Subject: What cockheads you are
Date: Wed, 10 May 2000 02:05:49 +1000
You cocksuckers couldn't afford a fucking windows environment....poor cunts
probably couldn't afford a mouse or a 500meg hard drive. fuck it would be a
cunt to live like you low life scum, and you have the nerve to call yourself
fucking developers......SUCK MY DICK you low life fuckwits.
------------------------------
From: David Weis <[EMAIL PROTECTED]>
Subject: Re: Kernel compilation of RH 6.2 gives same major, minor numbers to
Date: Tue, 9 May 2000 11:15:11 -0500
On Tue, 9 May 2000, Rohit Samson Dean wrote:
> I tried to compile Linux Kernel 2.2.14-5.0 which came on the RH 6.2
> distribution, and then when I tried to boot the machine, it coudn't
> mount my fat32 partition at boot time or even later. The error it gave
> is that the device is using a major/minor number combination which is
> already in use. After lookiing at ls /dev, I found out that /dev/ttyp2
> had a major, minor device number combination of 3, 2 which is the same
> as /dev/hda2 (which is where my fat32 resides).
If you found this out using ls -l, take a look at the first character in
the line. There will be either a 'b' or a 'c'. The b is a block device,
like a hard drive or cdrom. The c is a character device like a tty or a
serial port.
> In fact /dev/ttyp? has a major device number of 3 which is the same as
> the major device number of /dev/hda?.
> This doesn't seem to be the case with the pre-compiled kernel shipping
> with this distribution.
> I have 2 questions
>
> Questtion #1.
> Why is this error coming up only when trying to mount the fat32
> partition (because other ext partitions /dev/hda[1,3-7] are getting
> mounted properly even though they have the same major/minor device
> number combinations as /dev/ttyp[1-7]).
They aren't related to fat32 at all. Perhaps there is a bug in the fat32
support in the kernel?
> Question #2.
> What can I do to avoid this? Is there an environment variable or #define
> which I can set to tell the kernel makefile the major device numbers for
> the tty/hda device?
No need.
dave
--
David Weis | 10520 New York Ave, Des Moines, IA 50322
[EMAIL PROTECTED] | Voice 515-278-0133 Ext 231
| http://www.perfectionlearning.com/
When they took the Fourth Amendment, I was quiet because I didn't deal drugs.
When they took the Fifth Amendment, I was quiet because I was innocent.
When they took the Second Amendment, I was quiet because I didn't own a gun.
Now they've taken the First Amendment and I can't say anything.
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: Sys Calls from Device Drivers
Date: 9 May 2000 13:30:02 GMT
ELSID Software Systems LTD. <[EMAIL PROTECTED]> wrote:
: I would like to be able to open a socket from within a device driver to
One way would be to have your driver communicate with a user-space process
which would do ioctl(), get the data packet, then communicate with the
socket, and send the results back with ioctl().
Advantage: main code in user space, no tricks, maybe even portable between
UNIX systems.
: a data resource on another system and use it to communicate with that
You can always use the sys_() stuff *provided you are running in a task
context* (thread, user process. Certainly not from interrupts).
Also you could generate low-level skb buffers ... but I really strongly
suggest you the user-space solution.
NB: you might want to look at the `network block device'.
------------------------------
From: jesper <[EMAIL PROTECTED]>
Subject: Apply the dvd-cd Patch.
Date: Tue, 09 May 2000 17:30:07 GMT
I'm having kernel 2.2.15, and i want to be able to play DVD. Then I found
out that i should patch my kernel, the file patch for the 2.2.15 kernel
that i downloaded was in bz2 format by uncompressing it is a *.diff file.
How should i apply this patch.
I have already read the kernel-howto, but that did not helped me
Thanks for any help
Jesper
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Race conditions in driver select and poll methods
Reply-To: [EMAIL PROTECTED]
Date: Tue, 09 May 2000 17:34:31 GMT
On Tue, 9 May 2000 11:58:46 +0200, Peter A. Kroon <[EMAIL PROTECTED]> wrote:
>But in select or poll, there is no such call to a sleep or schedule routine;
>instead if none of the files specified in the select mask has data available,
>it is the kernel who calls schedule. In our opinion this can also lead to the
So where is the problem? Whether you call scheduler, or whether the kernel does
it later, what matters is that it gets called.
>same race condition as in read and write.
That is not true. Have a look at the code for the poll system call. Firstly, it
changes the state to TASK_INTERRUPTIBLE. Then it calls the various poll
virtual functions throughout the kernel, passing each one the poll table
structure. These poll functions can avoid losing a wakeup from an interrupts
by enqueuing the task *first* and *then* checking the polled conditions. The
enqueuing is done by using poll_wait() which grabs a free entry from the poll
table and sticks it onto a given wait queue.
So the race avoiding logic is the same as you described, except that it is
broken up into mutliple functions: sys_poll() manages the sleep state of the
task and the call to the scheduler. The poll functions manage the enqueuing and
testing of the conditions.
>We have the feeling that calling cli() before the race condition could occur,
>is not a good thing to do here.
cli is obsolete, you should use spinlocks.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Steve)
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: Re: DNS problem
Reply-To: [EMAIL PROTECTED]
Date: 9 May 2000 18:45:02 GMT
On Tue, 09 May 2000 00:35:06 +0800, chris wrote:
>
>--------------BBBAE3211C557E98E280F3DF
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
> Hi,
>I have configure two dns servers, the servers seem working fine for
>quite a few week except there are errors in /var/log/message:
>Apr 9 12:11:21 server01 named[458]: sysquery: findns error (SERVFAIL)
>on ?
>Can any suggest what's the problem with my dns server, does this error
>message casue harm ?
You need to know what IP or Name it failed on, it could just be soeone
trying to get to an unreachagle network.
--
Cheers
Steve email mailto:[EMAIL PROTECTED]
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.ndirect.co.uk/~sjlen/
or http://start.at/zero-pps
9:40am up 12 days, 11:41, 2 users, load average: 1.08, 1.02, 1.00
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Timeout on Mutex
Reply-To: [EMAIL PROTECTED]
Date: Tue, 09 May 2000 17:48:46 GMT
On Tue, 09 May 2000 13:17:37 +0100, Colin Ford
<[EMAIL PROTECTED]> wrote:
>Hi There,
>
>is there anyway to implement a timeout call
>on a mutex get?
Timing out mutex gets is a bad idea. A mutex should be held only for a brief
critical region and unlocked quickly. If it takes so long to get a mutex that
you want to implement a timeout, there is a bug in your program.
Of course, this rationale would not prevent the POSIX people from adding mutex
timeouts. A late draft of POSIX adds the brain-damaged function
int pthread_mutex_timedlock(pthread_mutex_t *,
const struct timespec *abstime);
Also introduced is a lower level locking primitive called pthread_spinlock_t
which doesn't support timed out waits. So POSIX programmers who thought that
mutexes were the simplest, fastest primitive for locking a critical region have
sort of been duped.
The pthread_mutex_timedlock function will not be available in glibc until
release 2.2; not that that will be any excuse to start using it.
My suggestion is: if you need a ``long lock'' that supports timed out waits,
write one using a mutex, a flag, and a condition variable. A timed out wait is
then done using pthread_cond_timedwait().
>All I could think of was to start a kill alarm
>before the call. Would this work and if so is
>it safe?
It's not safe, and it won't work anyway. Once the pthread_mutex_lock function
goes to sleep, it blocks all signals except for the special internal wakeup
signal.
--
#exclude <windows.h>
------------------------------
From: "Quang Nguy��" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: ** gdb Question
Date: Tue, 9 May 2000 11:08:02 -0700
>From virtual terminal 1, I want to debug my program and redirect its
input/output to terminal 2. With gdb, I can using: gdb -tty=/dev/tty2
myprog
However, from terminal 2 I can only see its output, but it doesn't accept
any keystrokes at all. When I hit enter from tty2, I'm still in the bash
prompt.
Is there anything I have to do on terminal 2? minicom? getty?
Hooking a dump terminal to my box should work, but it's not an option for
me.
Thanks,
Quang
------------------------------
** 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
******************************
