On Thu, Nov 23, 2006 at 01:23:01PM -0800, Bakul Shah wrote:
> > The problem is that kldloading a module if it's already in the kernel
> > can cause a panic.  Also if the module becomes stale with respect to
> > the running kernel, this approach can cause a lot of confusion.
> 
> I thought the following would do the trick:
> 
>     kldstat -m aio >/devnull 2>&1 || kldload aio
> 
> > Something I'd like to see is
> > 
> > a) Fixing the kldload "double load" problems
> 
> See above.  Works in -current at least.

It "should" work, but people sometimes report that it doesn't
(i.e. when they get the resulting panic).  It at least needs to be
investigated.

There's still the "stale module" problem.

> > b) That optional kernel subsystems register themselves with a sysctl,
> > so that userland can easily determine whether a feature is present in
> > the running kernel and take appropriate action (warn user, demand
> > load, etc) if not.  compat[45]x support is another such case; there's
> > no way for a port to tell whether the kernel supports running such
> > binaries, and if not then the user will just get an error when they
> > try to run it.
> 
> Isn't kldstat -v & kldstat -m good enough?

No, it only works for things that are modules:

> grep -i compat /usr/src/sys/i386/conf/XOR
options         COMPAT_43               # Compatible with BSD 4.3 [KEEP THIS!]
options         COMPAT_FREEBSD4         # Compatible with FreeBSD4
options         COMPAT_LINUX
> kldstat -v | grep -i compat

COMPAT_FREEBSD4 doesn't exist as a module so it's not registered
there.

Kris

Attachment: pgpgqatfMLQxH.pgp
Description: PGP signature

Reply via email to