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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message