Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Jan 1999 09:21:18 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Archie Cobbs <archie@whistle.com>
Cc:        freebsd-hackers@FreeBSD.ORG, Julian Elischer <julian@whistle.com>
Subject:   Re: Loading KLD from the kernel
Message-ID:  <Pine.BSF.4.01.9901190915370.40696-100000@herring.nlsystems.com>
In-Reply-To: <199901190451.UAA07575@bubba.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jan 1999, Archie Cobbs wrote:

> Doug Rabson writes:
> > > What's the correct way to request loading of a KLD module from within
> > > the kernel (but not from an interrupt handler).  I see the kldload()
> > > syscall function.. should I just call it directly?
> > > 
> > > Same question for unloading a KLD module...
> > 
> > The right thing to do is to call linker_load_file() like this:
> > 
> > 	linker_file_t lf;
> > 	int error = linker_load_file(filename, &lf);
> > 	if (error)
> > 		...;
> 
> Thanks!! That works great.
> 
> Now I have another much more minor question.. when kldload() loads
> a module, it increments "lf->userrefs" .. I assume this field is
> for the "client" code to use (eg, kld syscalls or other kernel
> entity).
> 
> If this field is zero, you can't unload the module from root shell:
> 
>   linkerunload: attempt to unload file which was not loaded by user
> 
> I'm trying to understand the exact semantics of userrefs, and how
> we can allow root to unload a KLD from the shell that was loaded
> from the kernel (after checking that it's safe, of course)?
> 
> I tried simply incrementing lf->userrefs after loading the module
> from the kernel, but somehow it went back to zero (?)

This field is a count of how many times a user has loaded the file using
kldload(2).  It is there to prevent a user from unloading a file which was
loaded explicitly by the kernel (e.g. as a dependancy).  Incrementing
userrefs should have worked though - can you watch what happens in the
debugger and find out why it is being reset?

The extra error checks added recently to kldload(2) seem to have broken
the user refcount anyway.  The intention is that if the file is already
present, kldload(2) will simply increment the refcounts.  That way two
unrelated user programs can kldload/kldunload the same file without
stepping on each other's toes.  I think instead of returning EEXIST, it
should increment the refcounts and return the file id.

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 442 9037



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9901190915370.40696-100000>