Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Jan 2003 13:12:15 +0100
From:      Martin Kaeske <Martin.Kaeske@Stud.TU-Ilmenau.DE>
To:        freebsd-hackers@freebsd.org
Subject:   status of kld in 5.0
Message-ID:  <20030108121215.GA1849@walnut.hh59.local>

next in thread | raw e-mail | index | archive | help
Hello,
Since PR kern/24392 it is not possible to panic the system by
loading and unloading a module that is statically compiled into
the kernel. I looked into the source (kern_linker.c, kern_module.c,
kern_sysctl.c) that is involved in the kld-system to find out
where the panics come from. I think i found the problem but no
good solution yet. Since 5.0 seems to be released in the near
future and the commit-log for kern_linker.c tells that the problem
doesn't exist in -current i want to ask wether it is worth trying
to fix it for 4-stable or not.

Furthermore i wonder if it is a good idea to let kldload return
successfully (error==0) if the module is already loaded. If an
application loads a module it want some functionality to be
present in the system (e.g. ppp), if the required module is
already loaded (compiled into kernel or by kldload) it is not an
error (the app wants ppp and kldload says "okay, ppp is loaded").
So you can write:
  if(!(id=kldload(file))) {
    /* do stuff */
    kldunload(id);
  }
wether the module is already present or loaded expicitly by kldload.

Thanks in advance
Martin


PS: for those who are interested, i think the panics come from
    linker_file_unregister_sysctls calling sysctl_unregister_set
    and sysctl_unregister_set itself calls sysctl_unregister_oid
    that removes the oid no matter who loaded it, i think this
    can be fixed with the help of "struct sysctl_oid"s oid_refcnt

-- 
"At the beginning of the week, we sealed ten BSD programmers into a
 computer room with a single distribution of BSD Unix. Upon opening
 the room after seven days, we found all ten programmers dead,
 clutching each others throats, and thirteen new flavors of BSD."

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?20030108121215.GA1849>