Re: CVS commit: src/tests/modules
On Mon, Mar 26, 2012 at 12:10:30AM -0700, Matt Thomas wrote: doesn't modctl/modload return some error which indicate the reason of failure? EPERM which isn't really useful. Oddly enough, it actually fails with EPERM on Sparc, but with ENOSYS on Xen. Manuel pointed out that it might be kobj_load_vfs(), kobj_load_mem(), or kobj_stat() that returns ENOSYS. - Julka.
Re: CVS commit: src/tests/modules
On Mon, Mar 26, 2012 at 06:27:00PM +0300, Jukka Ruohonen wrote: ENXIO seems appropriate. Or even better: ENOSYS. ENXIO is better, it means the requested subsystem is unavailable/disabled. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/modules
On Mar 27, 2012, at 3:15 PM, David Holland wrote: On Mon, Mar 26, 2012 at 06:27:00PM +0300, Jukka Ruohonen wrote: ENXIO seems appropriate. Or even better: ENOSYS. ENXIO is better, it means the requested subsystem is unavailable/disabled. or ENOEXEC.
Re: CVS commit: src/tests/modules
On Mar 25, 2012, at 10:35 PM, YAMAMOTO Takashi wrote: hi, doesn't modctl/modload return some error which indicate the reason of failure? EPERM which isn't really useful.
Re: CVS commit: src/tests/modules
On Thu, Mar 22, 2012 at 10:25:23AM +0100, Martin Husemann wrote: I like the kern.module.supported, or perhaps kern.module.enabled, as I have systems built without module loading support yet still have a few module sysctls around under that same hierarchy, and module.modular also seems ambiguous and redundant... The question is complex, so I am for realy simple solutions. kern.module.modular = 1 means: options MODULAR was active when the kernel was built. If we go any further, it gets tricky. I wasn't suggesting going further. I'm just opposed to the word modular because it carries a bunch of baggage... baggage that has created contention and strife in the past. kern.module.supported = 1 means the same thing without this disadvantage. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/modules
hi, On Mar 25, 2012, at 10:35 PM, YAMAMOTO Takashi wrote: hi, doesn't modctl/modload return some error which indicate the reason of failure? EPERM which isn't really useful. then how about changing it so that it's more useful? YAMAMOTO Takashi
Re: CVS commit: src/tests/modules
On Mon, Mar 26, 2012 at 11:58:40AM +, YAMAMOTO Takashi wrote: hi, On Mar 25, 2012, at 10:35 PM, YAMAMOTO Takashi wrote: hi, doesn't modctl/modload return some error which indicate the reason of failure? EPERM which isn't really useful. then how about changing it so that it's more useful? ENXIO seems appropriate. To add a sysctl to check for MODULAR/non-MODULAR seems unnecessarily complicated. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: CVS commit: src/tests/modules
On Mon, Mar 26, 2012 at 06:27:00PM +0300, Jukka Ruohonen wrote: On Mon, Mar 26, 2012 at 10:17:08AM -0500, David Young wrote: ENXIO seems appropriate. Or even better: ENOSYS. Careful with that, returning ENOSYS within the kernel often ends up killing the current process with SIGSYS. Thor
Re: CVS commit: src/tests/modules
On Mon, Mar 26, 2012 at 07:35:40AM +, David Holland wrote: kern.module.supported = 1 means the same thing without this disadvantage. Maybe (from a UI perspective this is all bogus and would need tons of documentation) - but what about a modstat -e (e for enabled) instead, that returns success if modules would be loadable, and mostat -e -v that does the same but additionally explains why not if returning an error (verbously on stderr). Martin
Re: CVS commit: src/tests/modules
hi, doesn't modctl/modload return some error which indicate the reason of failure? YAMAMOTO Takashi On Thu, Mar 22, 2012 at 10:12:34AM +, Iain Hibbert wrote: sysctl doesn't need to be static of course, you could do the kauth check and return a value based on whether you may load a module or not, I don't know if that will serve to disambiguate Xen? No, this is not about XEN at all! The tests do some modload and this can fail for various reasons. The most popular ones are - kernel is !MODULAR (this is the case for all XEN kernels) - securelevel is = 1 The whole issue is wether we call any of those a failure in the tests (which clearly is wrong) or mark the tests as skipped, with a proper message. Since the tests already can easily test for securelevel, the only open question is is this kernel modular, which is why I proposed that very simple solution to a simple question. Now, if we want the sysctl to say I can load modules the water gets muddy and we may have to ask more precise questions - however, since the simple answer already is enough, IMHO we should stick to that. I don't care for the names, but don't make it sound like it answers a more complex question when it doesn't. Martin
Re: CVS commit: src/tests/modules
On Wed, 21 Mar 2012 21:47:31 + David Holland dholland-t...@netbsd.org wrote: But, how about kern.module.supported or kern.module.canload or something? I like the kern.module.supported, or perhaps kern.module.enabled, as I have systems built without module loading support yet still have a few module sysctls around under that same hierarchy, and module.modular also seems ambiguous and redundant... -- Matt
Re: CVS commit: src/tests/modules
On Thu, 22 Mar 2012, Martin Husemann wrote: On Thu, Mar 22, 2012 at 03:33:18AM -0400, Matthew Mondor wrote: I like the kern.module.supported, or perhaps kern.module.enabled, as I have systems built without module loading support yet still have a few module sysctls around under that same hierarchy, and module.modular also seems ambiguous and redundant... The question is complex, so I am for realy simple solutions. kern.module.modular = 1 means: options MODULAR was active when the kernel was built. sysctl doesn't need to be static of course, you could do the kauth check and return a value based on whether you may load a module or not, I don't know if that will serve to disambiguate Xen? iain
Re: CVS commit: src/tests/modules
On Thu, Mar 22, 2012 at 10:12:34AM +, Iain Hibbert wrote: sysctl doesn't need to be static of course, you could do the kauth check and return a value based on whether you may load a module or not, I don't know if that will serve to disambiguate Xen? No, this is not about XEN at all! The tests do some modload and this can fail for various reasons. The most popular ones are - kernel is !MODULAR (this is the case for all XEN kernels) - securelevel is = 1 The whole issue is wether we call any of those a failure in the tests (which clearly is wrong) or mark the tests as skipped, with a proper message. Since the tests already can easily test for securelevel, the only open question is is this kernel modular, which is why I proposed that very simple solution to a simple question. Now, if we want the sysctl to say I can load modules the water gets muddy and we may have to ask more precise questions - however, since the simple answer already is enough, IMHO we should stick to that. I don't care for the names, but don't make it sound like it answers a more complex question when it doesn't. Martin
Re: CVS commit: src/tests/modules
On Tue, Mar 20, 2012 at 05:50:11AM +, Jukka Ruohonen wrote: Module Name: src Committed By: jruoho Date: Tue Mar 20 05:50:11 UTC 2012 Modified Files: src/tests/modules: t_abi_uvm.sh t_modload.sh Log Message: Skip Xen. XXX: There should be a reliable way to detect MODULAR. This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). What do folks think? Martin Index: kern_module.c === RCS file: /cvsroot/src/sys/kern/kern_module.c,v retrieving revision 1.86 diff -u -r1.86 kern_module.c --- kern_module.c 4 Dec 2011 19:24:59 - 1.86 +++ kern_module.c 21 Mar 2012 12:23:46 - @@ -428,6 +428,17 @@ SYSCTL_DESCR(Enable verbose output), NULL, 0, module_verbose_on, 0, CTL_CREATE, CTL_EOL); + sysctl_createv(module_sysctllog, 0, node, NULL, + CTLFLAG_PERMANENT | CTLFLAG_IMMEDIATE | CTLFLAG_READONLY, + CTLTYPE_BOOL, modular, + SYSCTL_DESCR(The kernel is compiled to allow loading + of modules), NULL, +#ifdef MODULAR + true, +#else + false, +#endif + NULL, 0, CTL_CREATE, CTL_EOL); } /*
Re: CVS commit: src/tests/modules
On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Martin
Re: CVS commit: src/tests/modules
On Wed, Mar 21, 2012 at 03:15:14PM +, Martin Husemann wrote: On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Not from me :) module tests are also failing for e.g. sparc. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/tests/modules
looks good to me... On Wed, 21 Mar 2012, Martin Husemann wrote: On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote: This (untested) would add one (sysctl kern.module.modular would say 0 for non-modular kernels, or 1 otherwise). I had to fix other parts of the kernel, but the patch now works as expected. Any objections? Martin !DSPAM:4f69f0a61987340033397! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
