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
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.
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
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 retu
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.
Tho
On Mon, Mar 26, 2012 at 10:17:08AM -0500, David Young wrote:
> ENXIO seems appropriate.
Or even better: ENOSYS.
- Jukka.
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 a
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
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
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.
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 mo
On Thu, 22 Mar 2012, Martin Husemann wrote:
> 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 disa
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
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 s
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 ambigu
On Wed, 21 Mar 2012 21:47:31 +
David Holland 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 a
On Wed, Mar 21, 2012 at 12:25:25PM +, Martin Husemann wrote:
> > 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?
Definitely a
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 pa
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 kerne
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
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 dete
21 matches
Mail list logo
