On Thursday 31 January 2008 16:05:57 Andriy Gapon wrote:
> on 31/01/2008 14:39 Andriy Gapon said the following:
> > on 31/01/2008 13:07 John Baldwin said the following:
> >> On Wednesday 30 January 2008 12:39:14 pm Andriy Gapon wrote:
> >>> The problem is as follows:
> >>> 1. put udf_load="YES" in loader.conf
> >>> 2. you can mount and unmount udf filesystems
> >>> 3. you can kldunload udf if no udf filesystems are mounted
> >>> 4. now mount udf fs while udf.ko is unloaded
> >>> 5. udf is auto loaded and fs is mounted
> >>> 6. unmount fs
> >>> 7. try to kldunload udf
> >>> kldunload: can't unload file: Device busy
> >>> kernel message: kldunload: attempt to unload file that was loaded by
> >>> the kernel
> >>>
> >>> Yeah, it was loaded by kernel indeed, but WTF - what is the difference
> >>> from manual/loader.conf loading and why I can not manage my modules as
> >>> I wish?
> >>
> >> Hmm, the relevant code (vfs_init.c) hasn't changed in 6.x since 6.0.
> >> There were some changes in 7.0, but this should work in both branches.
> >> What is the previous release that this worked on?

> >
> > Maybe I was wrong when I called this regression, but this was very
> > surprising behavior for me. And in 5.X I did a lot of udf
> > debugging/experimenting and never encountered such a problem. Maybe I
> > always did kldload before mount, I can't tell now.
> > Anyway, this seems like an annoyance at the very least, pinning a kernel
> > module without any important reasons.

> Hmm, I found one difference with previous setups: in step 1 I also have
> udf_iconv_load="YES" and udf_iconv.ko module is what seems to prevent
> udf.ko from unloading in step 7. I can actually unload udf_iconv and
> then I am able again to unload udf.
> Still don't understand what is a big difference here.
> And if I had UDF_ICONV built into kernel then I wouldn't have this
> work-around.

The way I understand it, there are two different things:

1. kldload will load "child" modules on demand, but kldunload does not attempt
to unload any other modules than the one you ask for. I don't think it's
material whether the kldload was done via the loader (before the kernel kmod
gets loaded, kernel is also a kmod), or after. It's also possible to have
modules who need to access the filesystem (other than /boot partition) when
kldloaded, and such modules can obviously not be loaded via the loader at

2. There may be modules (such as bktr) that allocate memory in kernel space.
These can not be unloaded, because that memory may not be deallocated while
the kernel is up and running (the latter is my assumption).

Anyhow, unless you're very tight on RAM, it hardly matters if you have some
kmods loaded but left unused. Kmods are small, typically 10-100 kB.

If all your kmods are built into the kernel, you have the footprint of all of
them and you can't disable any at runtime.

Feel free to correct me, anyone, if you think the above is not correct or

freebsd-stable@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"