Date: Mon, 01 Feb 1999 17:04:53 -0800 From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG Subject: KLD confusion.. Message-ID: <36B64F35.237C228A@whistle.com>
next in thread | raw e-mail | index | archive | help
Take the following scenario:
compiled in: module A
kldstat -v shows module 'A'
kldload A
damned thing succeeds.
e.g.
[phaser.whistle.com] 516 kldstat -v
Id Refs Address Size Name
1 2 0xf0100000 1c8198 kernel.try
Contains modules:
Id Name
1 rootbus
2 netgraph
[...]
2 1 0xf07f0000 4000 netgraph.ko
Contains modules:
Id Name
31 netgraph
this is handleable by just not loading 'A'
but what about the following:
kldload 'B' where B is defined to have a dependency on 'A'
and 'A' is already loaded..
A get's loaded again.. leading to REALLY strange behaviour
if the kernel is talking to one copy of A and B is talking
to the other.
I saw a suggestion from Peter to do something to change this,
but I didn't understand it at the time. Now I think I saw what
he was talking about.
can whatever he was suggesting be done?
as it is I can't win..
If I don't declare a dependency between A and B then I need to have
A compiled in for B to load, but if A is loaded instead of
compiled, B can't find it. If I DO declare a dependency, then
if I load B it will ALWAYS load A even if it's already compiled in.
as a result, the only way I can make it work is if either both A
and B are compiled in or A and B are both loaded.
Unfortunatly, I have some node that need to be compiled in
as the infrastructure is not quite ready for them to be loaded yet,
(e.g. interrupt hooking etc.) so ALL ofthe nodes need to be
compiled in.
Effectively, this is the same as not having KLDs.
If I can't use them, what good are they?
I've had a look at the code, but
I think this would be a 20 minute thing for the right person,
rather than a 2 day thing for me...
julian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36B64F35.237C228A>