Date: Sat, 25 Jul 1998 00:59:08 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: wjw@IAEhv.nl Cc: robert+freebsd@cyrus.watson.org, dfr@nlsystems.com, hackers@FreeBSD.ORG Subject: Re: SYSCTL ....... Message-ID: <199807250059.RAA19097@usr06.primenet.com> In-Reply-To: <199807241631.SAA28948@surf.IAE.nl> from "Willem Jan Withagen" at Jul 24, 98 06:31:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> There are 2 possibilities:
> Deleting the whole oid.
> (What to do on the implicitly created intermediates)
> Deactivating the reference to which the OID-value pointed.
>
> If you chose for the last one, you'll always have "prove" of the fact that
> the LKM was at any loaded.
I dislike any implementation which implies that the kernel must do
dynamic scoping and grabage collection to get rid of unused objects;
this is one of my primary objections to the way JAVA implements
variables, or for that matter, the way EMACS uses ELISP.
If I want proof that an LKM was loaded at some time in the past,
I will look at my kernel logs.
> The solution for this is to be able to hand of part of the tree virtually
> to a routine which can generate the requested information.
> So your router-module should have a/more function(s) which allow it
> to extend the tree once this proc-node is hit.
> This tree can then be constructed or the answers could be returned on the
> fly by the current data.
Yes. In other words, the MIB is a nodal hierarchy with a single root,
and realms of responsibility can be appended at edges.
In other words, you mount the things just like you mount FS's.
In terms of accessing the data structures, I'm against providing a
VOP-like functionality for MIB data (unless you are planning on exposing
it via procfs, and then you expose it exactly once, using the procfs
code, not code in each LKM).
This means that there is an "oid" registration mechanism for claiming
an area of the tree.
If you are going to allow "submounts", then you will need to imply
"module B depends on module A" if B exports a subtree of A, theis is
the only method by which A and B are related, and you are trying to
unload module A.
This is a dependency interaction, and since there can be others
("module C depended on Module A because module C imports function X
and module A exports function X"), it would be best to resolve them
in one place.
The easiest implementation would be a simple reference count, where
each dependency does an "addref" and when removed, does an "unref".
When the reference fall to 0, the module can be unloaded.
The "easiest way" is probably not the right way, since you would
have to say "module A cannot be unloaded because it is being referenced"
instead of "module A can not be unloaded because module B is using it".
To get the useful information that you need to unload B to unload A,
you need to keep a pointer to the referencing module, ie:
struct _modref;
typedef struct _modref modref_t;
struct _modref {
modref_t *mr_next;
uint32_t mr_count;
mod_t mr_by;
} modref_t;
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?199807250059.RAA19097>