Linux-Development-Sys Digest #795, Volume #8 Mon, 18 Jun 01 18:13:22 EDT
Contents:
Re: where can I find the format of ELF? (Michael Kerrisk)
what is the effect of duplicate device files? (Anonymous)
Re: Module zombies (Kasper Dupont)
Re: what is the effect of duplicate device files? (Kasper Dupont)
initialization of pci_devs in drivers/pci/pci.c ? (Thomas Eschenbacher)
socket and dst addr ("Fabio Ventrone")
Re: Module zombies (Clifford Kite)
Re: where can I find the format of ELF? ("Norman Black")
Re: which are all the journaling filesystem? ("gdm")
Re: which are all the journaling filesystem? ("gdm")
pthread limitations? specificaly with fcntl and file locking? (Brian Horton)
Shared memory: sharing a specific location ("RMII News")
Re: where can I find the format of ELF? (Robert Redelmeier)
versioning /usr/include/linux ? ("citizen")
Re: PCI device register access (=?iso-8859-1?Q?Andr=E9?= David)
Re: Supervising non-child processes w/wo procfs (=?iso-8859-1?Q?Andr=E9?= David)
Re: Anjuta IDE :: Integreated Development Environment for C/C++) ::
(=?iso-8859-1?Q?Andr=E9?= David)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Kerrisk)
Subject: Re: where can I find the format of ELF?
Date: Mon, 18 Jun 2001 10:28:02 GMT
On Mon, 18 Jun 2001 14:26:01 +0800, "wordless" <[EMAIL PROTECTED]>
wrote:
>I want to write a program which manipulate the ELF excutables. While there
>is a BFD library, I have little idea of how to use it. Can anybody tell me
>where can I find some documents of ELF format or how to use BFD library?
>Thank u in advance.
Try the following:
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/ELF.doc.tar.gz
ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
Cheers
Michael
------------------------------
Date: Mon, 18 Jun 2001 07:39:17 -0400
Subject: what is the effect of duplicate device files?
From: Anonymous <[EMAIL PROTECTED]>
I am restoring several copies of my root filesystem
on my hard drive. Will the duplicate device files
cause any problems? They're not being used but
they're just there.
--------== Posted Anonymously via Newsfeeds.Com ==-------
Featuring the worlds only Anonymous Usenet Server
-----------== http://www.newsfeeds.com ==----------
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Module zombies
Date: Mon, 18 Jun 2001 12:41:38 +0000
Clifford Kite wrote:
>
> Kasper Dupont <[EMAIL PROTECTED]> wrote:
>
> > What shows up in the output from ps is not a module, it is a
> > process. Surely a module and a process is something
> > different, a module is nothing but some pieces of code. But
> > a module may create a process using the kernel_thread(),
> > only a few modules need to do this. The module may even
> > create multiple processes, in this case it seems it wants to
> > create one pr. unit. I guess the _0 in the process name is
> > the unit number.
>
> Okay.
>
> > Before the module can be unloaded the processes have to be
> > stopped. Obviously removing the code of a runing process can
> > lead to a crash. The Z in the output means that the process
>
> Nothing has crashed yet. The modules do unload after the device
> is unmounted, I guess since then nothing is using them - they are
> being used when the camera CompactFlach is mounted and the zombied
> ones won't unmount while they are in use.
Probably the module was not in use, the zombies
doesn't need the module.
>
> > is really stopped, but the parent process has not yet been
> > informed about this. If a process stays in the zombie state
> > for a very long time, it usually indicate that there is a
> > problem with the parent process. But in this particular case
>
> Would that be khubd?
Acording to the ps output it is.
>
> > I would expect that the parent process is the init process,
> > and that program is probably one of the worlds most used
> > programs, so a bug in init sounds like an unlikely
> > explanation.
>
> > Perhaps the output from "ps -fA --forest" can show something
> > interesting.
>
> root 8 1 0 Jun14 ? 00:00:00 [khubd]
> root 2590 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2591 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2601 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2602 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2660 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2661 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2670 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2671 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2686 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2687 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2719 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2720 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2759 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2760 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2791 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2792 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2802 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2803 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2847 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2848 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
> root 2863 8 0 Jun15 ? 00:00:00 \_ [usb-storage-0 <defunct>]
> root 2864 8 0 Jun15 ? 00:00:00 \_ [scsi_eh_0 <defunct>]
This looks very much like a bug in khubd.
>
> ect. There's more, but this is likely enough, especially for anyone
> who can understand what it means. I'm not in that group of people
> although I'd guess that hkubd is a thread and the parent. The core for
> USB is compiled directly into the kernel - maybe khubd comes from that?
Yes.
>
> Do you have any ideas on what process/thread or module is doing
> the wrong thing? Or how to do a workaround to prevent the zombies?
> I know they don't really hurt except to sop us process numbers but
> their continued existence and growing number are annoying.
They do hurt a litle bit, they eat 8KB of physical memory
each. And they also slow down programs like top and ps.
The best solution would be to fix the bug in khubd. I think
it would be easy to fix. Personally I don't have any USB
devices so I would have a hard time testing a bugfix.
Perhaps if USB was compiled as a module unloading and reloading
USB would remove the zombies. If khubd is stopped all the zombies
will get init as their parent, and init does care about dead
children.
>
> I understand what's happening a little better now - thanks for that.
> But if nobody here can help to cure this problem then I'll need to
> try the linux-usb-users mailing list mentioned in the usb-help.txt
> file in the kernel source tree.
>
> --
> Clifford Kite <Email: [EMAIL PROTECTED] with X=kite, Y=inetport, Z=com>
--
Kasper Dupont
------------------------------
From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: what is the effect of duplicate device files?
Date: Mon, 18 Jun 2001 12:45:54 +0000
Anonymous wrote:
>
> I am restoring several copies of my root filesystem
> on my hard drive. Will the duplicate device files
> cause any problems? They're not being used but
> they're just there.
>
They shouldn't cause any problems as
long as they are not used.
There can be a security issue if you
have users that you don't trust,
they could start using the duplicated
device special files.
If the files is stored in a directory
where only root has access you should
be perfectly safe.
--
Kasper Dupont
------------------------------
From: Thomas Eschenbacher <[EMAIL PROTECTED]>
Subject: initialization of pci_devs in drivers/pci/pci.c ?
Date: Mon, 18 Jun 2001 16:34:43 +0200
I am currently working with the mips port of kernel 2.4 and have a
problem in understanding the way how the device table of the PCI bus
should get initialized.
The platform/architecture dependent part in pci_bios.c already
successfully scans and initializes the pci bus, it finds devices,
collects them in a *local* structure and then returns. So far so good.
But then in drivers/pci/pci.c I cannot find any place where the table
"pci_devs" gets
filled. And as a consequence no pci device driver works because all
functions in pci.c look into that *empty* pci_devs table?!
any ideas what is going wrong?
--
________________________________________________________________________
Thomas Eschenbacher [EMAIL PROTECTED]
------------------------------
From: "Fabio Ventrone" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: socket and dst addr
Date: Mon, 18 Jun 2001 18:08:09 +0200
I'd like to know what is the dst address of the socket connections I accept.
In fact I'm going to accept connections routed to my host at system level
(route add...) and I need to know where they were directed.
Is it possible using the system calls [socket, bind, listen, accept ...] or
I'll need something else?
Thank you
ciao
Fabio
------------------------------
From: Clifford Kite <[EMAIL PROTECTED]>
Subject: Re: Module zombies
Date: Mon, 18 Jun 2001 13:23:14 -0500
Kasper Dupont <[EMAIL PROTECTED]> wrote:
> Clifford Kite wrote:
[Some questions with good answers omitted for brevity...]
First I'd like to thank you for this reply. It really helped me
understand what's going on and provided a guide as to what to do.
>> Do you have any ideas on what process/thread or module is doing
>> the wrong thing? Or how to do a workaround to prevent the zombies?
>> I know they don't really hurt except to sop us process numbers but
>> their continued existence and growing number are annoying.
> They do hurt a litle bit, they eat 8KB of physical memory
> each. And they also slow down programs like top and ps.
I didn't know about the 8KB of physical memory that each uses.
> The best solution would be to fix the bug in khubd. I think
> it would be easy to fix. Personally I don't have any USB
> devices so I would have a hard time testing a bugfix.
I agree that would be the best solution and I'll post to the usb
mailing list suggesting that there is a khubd bug causing the zombies.
I'm not competent enough in C (or kernel code peculiarities) to try
fixing it myself.
Of course, if you think you could fix it then I could test the patch.
No, just kidding (mostly), that's really asking too much of you.
> Perhaps if USB was compiled as a module unloading and reloading
> USB would remove the zombies. If khubd is stopped all the zombies
> will get init as their parent, and init does care about dead
> children.
I don't have a problem compiling kernels (unless there is a bug in
the kernel code or a configuration script that stops the compile),
I've done that since my first one, 1.2.13. I might try that if nobody
on the USB mailing list shows any interest in fixing khubd.
BTW I just tried "kill -HUP $(pidof khubd)", since sending SIGHUP
restarts many processes, and now it's a zombie. BUT doing that got
rid of all the other zombies!
Reinserting the modules didn't help, the camera CompactFlash card
couldn't be mounted - not a big surprise. Doing "telinit u" and
going to single user mode didn't help. The khubd process remained
a zombie and no new khubd process was created.
Thanks once again for your help.
--
Clifford Kite <Email: [EMAIL PROTECTED] with X=kite, Y=inetport, Z=com>
------------------------------
From: "Norman Black" <[EMAIL PROTECTED]>
Subject: Re: where can I find the format of ELF?
Date: Mon, 18 Jun 2001 12:25:20 -0700
Reply-To: "Norman Black" <[EMAIL PROTECTED]>
I downloaded the TIS ELF 1.2 document from the web some time ago. I do not
know where but a search for TIS ELF should suffice to find it. Note that
there are 1.1 and 1.2 documents out there. 1.2 is much better.
I have a 338k PDF file of the ELF 1.2 document if you cannot find it on the
web.
That document gave me enough information to add Linux and Solaris support to
our linker. I did have to look at BFD for some information on the symbol
version mechanism which Sun invented and Gnu/Linux also uses.
--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom
"wordless" <[EMAIL PROTECTED]> wrote in message
news:9gk6sd$npn$[EMAIL PROTECTED]...
> I want to write a program which manipulate the ELF excutables. While there
> is a BFD library, I have little idea of how to use it. Can anybody tell me
> where can I find some documents of ELF format or how to use BFD library?
> Thank u in advance.
>
>
------------------------------
From: "gdm" <[EMAIL PROTECTED]>
Subject: Re: which are all the journaling filesystem?
Date: Mon, 18 Jun 2001 22:30:26 +0200
"Zeljko Vrba" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> On Sat, 16 Jun 2001 09:04:02 +0200, gdm <[EMAIL PROTECTED]> wrote:
> > Which are all the journaling file system for linux? I have been told of
> > reiserFS. Which are the other journaling filesystem for linux?
> xfs is also one.
I want to have a journaling filesystem on redhat6.2 with a kernel2.2.14. Do
you think that it exists a version of xfs to fit with a kernel2.2.14?
gdm
------------------------------
From: "gdm" <[EMAIL PROTECTED]>
Subject: Re: which are all the journaling filesystem?
Date: Mon, 18 Jun 2001 22:32:10 +0200
"Philip Armstrong" <[EMAIL PROTECTED]> a �crit dans le message news:
9gf789$1ai$[EMAIL PROTECTED]
> In article <[EMAIL PROTECTED]>,
> Zeljko Vrba <[EMAIL PROTECTED]> wrote:
> >On Sat, 16 Jun 2001 09:04:02 +0200, gdm <[EMAIL PROTECTED]> wrote:
> >> Which are all the journaling file system for linux? I have been told of
> >> reiserFS. Which are the other journaling filesystem for linux?
> >xfs is also one.
> And the ext3 filesystem has journalling I believe. Not in the standard
> kernel yet tho' afaicr.
I want to run a journaling filesystem on a kernel2.2.14, with redhat6.2. Do
you know if ext3 can work with redhat6.2 and kernel 2.2.14 ?
gdm
------------------------------
From: Brian Horton <[EMAIL PROTECTED]>
Subject: pthread limitations? specificaly with fcntl and file locking?
Date: Mon, 18 Jun 2001 14:03:10 -0500
anyone have a pointer to some document that tells the limitations to
pthreads on linux?
my specific problem -- main does an fcntl to lock a file; then does a
pthread_create. that thread then unlocks the file w/ an fcntl; however,
the file doesn't get unlocked until after the thread dies (ie, via a
pthread_join).
any way around this?
thx.bri.
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <pthread.h>
#define LOCK_FILE "/tmp/lockedfile"
static void *unlockthread(void *);
pthread_t ult;
int file_lock_fd = -1;
int main(int argc,char *argv[]) {
struct flock lock;
pthread_attr_t ultattr;
int rc = 0;
lock.l_type = F_WRLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 2;
printf("opening file %s\n", LOCK_FILE);
file_lock_fd = open(LOCK_FILE, O_RDWR|O_CREAT, 0660);
if (file_lock_fd >= 0 ) {
printf("locking the file, %s\n", LOCK_FILE);
rc = fcntl(file_lock_fd, F_SETLKW, &lock);
if (rc != -1) {
printf(" acquired the lock spawning unlock thread \n");
pthread_attr_init(&ultattr);
pthread_attr_setdetachstate(&ultattr,
PTHREAD_CREATE_JOINABLE);
if (pthread_create(&ult, &ultattr, unlockthread, NULL)) {
printf("Trouble starting the unlockthread,
unlocking\n");
lock.l_type = F_UNLCK;
fcntl(file_lock_fd, F_SETLKW, &lock);
exit(1);
}
} else {
printf(" failed to acquire the lock, errno = %d\n", errno);
}
} else {
printf("file open failed, errno = %d\n", errno);
}
if (rc = pthread_join(ult, NULL)) {
printf("Main thread error joining unlock thread, rc = %d\n",
rc);
}
/* Check the lock state */
memset(&lock, 0, sizeof(lock));
if (fcntl(file_lock_fd, F_GETLK, &lock) != -1) {
printf("main thread after join - lock.l_type = %d, lock.l_whence
= %d, lock.l_start = %d, lock.l_len = %d lock.l_pid = %d\n",
lock.l_type, lock.l_whence, lock.l_start, lock.l_len, lock.l_pid);
} else {
printf("fcntl call failed\n");
}
printf("ALL DONE!\n");
}
static void *unlockthread(void *arg) {
struct flock lock;
int rc = 0;
/* This thread sleeps for 30 seconds and then unlocks the file */
printf("unlock thread started, sleeping 30 seconds\n");
sleep(30);
printf(" releasing the lock and sleeping 15 seconds \n");
lock.l_type = F_UNLCK;
lock.l_whence = SEEK_SET;
lock.l_start = 0;
lock.l_len = 2;
rc = fcntl(file_lock_fd, F_SETLKW, &lock);
if (rc != -1) {
printf(" unlock successful!\n");
memset(&lock, 0, sizeof(lock));
if (fcntl(file_lock_fd, F_GETLK, &lock) != -1) {
printf("locker thread - lock.l_type = %d, lock.l_whence =
%d, lock.l_start = %d, lock.l_len = %d lock.l_pid = %d\n", lock.l_type,
lock.l_whence, lock.l_start, lock.l_len, lock.l_pid);
} else {
printf("fcntl call failed\n");
}
} else {
printf(" failed to unlock the lock, errno = %d\n", errno);
}
sleep(15);
}
------------------------------
From: "RMII News" <[EMAIL PROTECTED]>
Subject: Shared memory: sharing a specific location
Date: Mon, 18 Jun 2001 14:44:37 -0600
Hi all,
I'm working on an application where I have a requirement to share memory
between processes and I'd like to use some battery backed up RAM mapped into
the address space. Is there a way to get shmget to return a segment mapped
from a specific physical address space?
Also, does anyone know of the segment size limit of shmget?
Onward,
John Bahr
------------------------------
Date: Mon, 18 Jun 2001 15:52:15 -0500
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: where can I find the format of ELF?
wordless wrote:
>
> I want to write a program which manipulate the ELF excutables. While there
> is a BFD library, I have little idea of how to use it. Can anybody tell me
> where can I find some documents of ELF format or how to use BFD library?
Try looking at Brian Raiter's work on Tiny
Executables and his ELFkickers:
http://www.muppetlabs.com/~breadbox/software/
-- Robert
------------------------------
From: "citizen" <[EMAIL PROTECTED]>
Subject: versioning /usr/include/linux ?
Date: Mon, 18 Jun 2001 21:06:04 GMT
I want to install a standard Linux 2.4.5 kernel
on a RedHat 7.1 system that is using a RedHat Linux 2.4.2 kernel.
What is the correct way to arrange things
so that a pointer to the right kernel headers
gets set in /usr/include during bootup
--
similar to the way a pointer to the right modules
gets set in /lib/modules?
I hope this question is of sufficiently
general interest to warrant its being posted
in this austere newsgroup.
--
[EMAIL PROTECTED]
The building is not the blueprint.
------------------------------
From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: PCI device register access
Date: Mon, 18 Jun 2001 23:20:03 +0200
This is a multi-part message in MIME format.
==============2886B0D7390E438A20F1660D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Do take a look at
/usr/src/linux/Documentation/IO-mapping.txt
HIH,
Andre
--
"Share the code. If you hide it ain't good."
Popular knowledge
==============2886B0D7390E438A20F1660D
Content-Type: text/x-vcard; charset=us-ascii;
name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Andr� David
Content-Disposition: attachment;
filename="Andre.David.vcf"
begin:vcard
n:David;Andr�
tel;cell:+41792013849
tel;work:+41227676147
x-mozilla-html:FALSE
org:CERN - European Centre for Nuclear Research;EP/NA60
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-16000
fn:Andr� David
end:vcard
==============2886B0D7390E438A20F1660D==
------------------------------
From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: Supervising non-child processes w/wo procfs
Date: Mon, 18 Jun 2001 23:26:54 +0200
This is a multi-part message in MIME format.
==============AC798F6E36A6CA4F778559FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Guido Ostkamp wrote:
>
> Jeremiah DeWitt Weiner <[EMAIL PROTECTED]> wrote:
> > What exactly do you mean by "supervise"?
> > [...]
> > ...because it sounds like you mean "wait for it to die".
>
> You are correct. The system is going to provide high-availability,
> therefore one feature is that applications which exited, must be
> restarted immediately. [...]
>From what I read, you might just want to use the init services:
man 5 inittab
HIH,
Andre
==============AC798F6E36A6CA4F778559FB
Content-Type: text/x-vcard; charset=us-ascii;
name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Andr� David
Content-Disposition: attachment;
filename="Andre.David.vcf"
begin:vcard
n:David;Andr�
tel;cell:+41792013849
tel;work:+41227676147
x-mozilla-html:FALSE
org:CERN - European Centre for Nuclear Research;EP/NA60
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-16000
fn:Andr� David
end:vcard
==============AC798F6E36A6CA4F778559FB==
------------------------------
From: =?iso-8859-1?Q?Andr=E9?= David <[EMAIL PROTECTED]>
Subject: Re: Anjuta IDE :: Integreated Development Environment for C/C++) ::
Date: Mon, 18 Jun 2001 23:33:03 +0200
This is a multi-part message in MIME format.
==============F37FF04F20C546B95ED2FF85
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Misha wrote:
>
> Anjuta is a very versatile Integrated development environment for c and c++
> Gnu/Linux. Written in gtk/gnome and written for gtk/gnome, it features many
> advanced programming tools and utilities. Besides many other, it has project
> management, application wizards, onboard interactive debugger, and a
> powerful source editor with source browsing.
>
> http://anjuta.sourceforge.net
...and a device driver wizard? 8^)
--
"Share the code. If you hide it ain't good."
Popular knowledge
==============F37FF04F20C546B95ED2FF85
Content-Type: text/x-vcard; charset=us-ascii;
name="Andre.David.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Andr� David
Content-Disposition: attachment;
filename="Andre.David.vcf"
begin:vcard
n:David;Andr�
tel;cell:+41792013849
tel;work:+41227676147
x-mozilla-html:FALSE
org:CERN - European Centre for Nuclear Research;EP/NA60
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
note:Geneva, Switzerland
x-mozilla-cpt:;-16000
fn:Andr� David
end:vcard
==============F37FF04F20C546B95ED2FF85==
------------------------------
** 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 by posting to the
comp.os.linux.development.system newsgroup.
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
******************************
