This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: dlopen/dlclose behaviour - real reloading from disk required.
- From: Charles Coldwell <coldwell at gmail dot com>
- To: PrzemysÅaw Firszt <przemo at firszt dot eu>
- Cc: libc-help at sourceware dot org
- Date: Wed, 9 Dec 2009 20:20:26 -0500
- Subject: Re: dlopen/dlclose behaviour - real reloading from disk required.
- References: <1260388032.3122.13.camel@pldmachine>
On Dec 9, 2009, at 2:47 PM, PrzemysÅaw Firszt wrote:
Hi,
I'm working on an input driver for xorg. Xorg server uses dlopen/
dlclose
from glibc to load module driver. I want to modify/update to driver
module without shutting down xorg.
Currently situation looks like that:
1. xorg started
2. load the input driver module (using whole xorg mechanism, but it
goes
down to dlopen)
3. test the driver
4. unload the driver module (as above, but dlclose)
5. modify the driver
6. reinstall the driver module (or remove from disk/reinstall -
doesn't
make any difference)
7. load the input driver
I'm expecting to see _new_ version of the driver loaded at point 7,
but
instead the old version is loaded.
So, in general if a file is unlinked in the filesystem by one process
while another one still has it open, the associated pages remain in
the page cache and the blocks continue to be allocated in the
filesystem until the last process with an open file descriptor on
that file has closed it. I wonder if the xorg server continues to
hold an open file descriptor on the driver file after the dlclose?
--
Charles M. Coldwell, W1CMC
"Turn on, log in, tune out"
Somerville, Massachusetts, New England (FN42kj)
GPG ID: 852E052F
GPG FPR: 77E5 2B51 4907 F08A 7E92 DE80 AFA9 9A8F 852E 052F