On Fri, Feb 01, 2013 at 06:25:24PM -0600, David Young wrote:
There was no use case, when I added it. Can you describe your use case?
Usually we iterate all CPUs with CPU_INFO_FOREACH() anyway (which should
also be replaced with a MI interface, but that requires non-trivial
invasion into
On Fri, Dec 28, 2012 at 10:05:36AM +0100, Marc Balmer wrote:
If, however, existing software is to use Lua as part of its
implementation, it needs to be made lua(4) aware, because it is going to
use the lua(4) API. If the existing software is a kernel module, it needs
to record a dependency on
On Fri, Dec 28, 2012 at 10:05:36AM +0100, Marc Balmer wrote:
Using a kernel module is not possible in all cases.
By a closer look, you have:
+#ifdef LUA
+MODULE(MODULE_CLASS_DRIVER, gpiosim, gpio,lua);
+#else
MODULE(MODULE_CLASS_DRIVER, gpiosim, gpio);
-
On Sat, Jul 07, 2012 at 08:57:10PM +0100, Mindaugas Rasiukevicius wrote:
Regarding the PR/38724, I propose to change the path to /kernel/.
Can we reach some consensus quickly for netbsd-6?
I'd vote for /lib/modules noted in the PR (or maybe under /libdata?)
simply because in my opinion the root
On Tue, May 29, 2012 at 03:00:58PM -0700, Paul Goyette wrote:
Well, at least for sysctl's SYSCTL_SETUP() stuff, you probably don't
want to use the same initialization call for modules as is used for
built-ins. The built-ins are initialized with an explicit NULL argument
passed for the
On Mon, Apr 16, 2012 at 07:49:28PM +0100, Iain Hibbert wrote:
I'm kind of with David Young, surely this is what the softc is for.. so
that the parent can keep track of which resources it has allocated (and by
inference, not reallocate them to another device)
I agree with this too; numerous
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 Wed, Mar 14, 2012 at 09:55:21AM +, Martin Husemann wrote:
This seems to cause deadlocks in the *fs_rename_dir tests.
Also the page residency check written by thorpej years ago now fails for the
first time.
- Jukka.
On Fri, Sep 30, 2011 at 11:27:46AM -0500, David Young wrote:
I don't think that the division of responsibility for power management
between kernel userland is obvious.
It may not be, but the arguments against kernel-level implementation are
largely practical. There is no one size fits all. The
On Thu, Sep 29, 2011 at 03:36:03PM -0500, David Young wrote:
What's the difference in power savings between changing C-state and
changing frequency? Do the power savings from every change in C-state
dominate the savings from any change in frequency?
Depends on the machine. But generally on
On Mon, Sep 26, 2011 at 10:03:06AM -0500, David Young wrote:
Instead, provide an API routine for finding out the number of states
(nstates) and a routine for selecting a state [0, nstates - 1].
The code is ready and it is available in [1]. However, I can not complete it
because when trying to
On Mon, Sep 26, 2011 at 05:51:13PM +, Christos Zoulas wrote:
Why advertise uint16_t, are we trying to save memory? I would just do
them uint32_t...
While few things are certain in computing, I don't think we are going to
see a 65535 MHz processor any time soon. But sure, uint32_t is fine
for the first iteration with the cpuctl(8). If there
are issues, speak now, otherwise I'll proceed with something based on this.
- Jukka.
/* $NetBSD$ */
/*-
* Copyright (c) 2011 Jukka Ruohonen jruoho...@iki.fi
* All rights reserved.
*
* Redistribution and use in source and binary forms
On Sun, Sep 25, 2011 at 10:50:44AM +0200, Alan Barrett wrote:
On Sun, 25 Sep 2011, Jukka Ruohonen wrote:
So here is a quick draft for the first iteration with the cpuctl(8). If
there
are issues, speak now, otherwise I'll proceed with something based on this.
You forgot to include
On Sat, Sep 24, 2011 at 06:10:46AM +, Michael van Elst wrote:
Pick one low and one high value and select these when the core/cpu/machine
is idle vs. when the machine is busy. Selecting the low and the high
value is much easier for a human when you label it in terms of the
specific platform
On Sat, Sep 24, 2011 at 04:33:07PM +1000, matthew green wrote:
i think that joerg's point is that the kernel-user API is the
wrong place to be making these sorts of humanisations.
You all miss the point that these humanisations (a.k.a. abstractions) are
primarily targeted for the use in
On Sat, Sep 24, 2011 at 10:14:13AM +0200, Joerg Sonnenberger wrote:
For the in-kernel use it should be completely irrelevant what the
property is.
Sigh. Answer my question then.
Any automatic mechanism should only care about the associated properties
(latency, reduction in power consumption
On Sat, Sep 24, 2011 at 08:35:11AM +, Michael van Elst wrote:
What is wrong with the abstraction of having a number of ordered
performance states? Hiding the states behind something pretending to
be a continuum (wether this is a MHz value or a percentage doesn't matter)
causes confusion.
On Sat, Sep 24, 2011 at 10:14:13AM +0200, Joerg Sonnenberger wrote:
For the in-kernel use it should be completely irrelevant what the
property is. Any automatic mechanism should only care about the
associated properties (latency, reduction in power consumption etc). I
don't see any of that
On Sat, Sep 24, 2011 at 07:53:47PM +0200, Joerg Sonnenberger wrote:
It's not relevant what the exact clock rate is. It's an approximation.
Just like the TSC frequency won't be measured the same on every boot.
It would be relevant if the interval would be guaranteed to be uniform.
Ignoring
On Sun, Sep 25, 2011 at 07:06:35AM +1000, matthew green wrote:
(FWIW, ultrasparcIIIi has cpufreq features, iirc, it allows the freq
to run at 1/2 and 1/16th normal. i'm sure that the modern fijitsu
SPARC64 also has it, but i don't know much about it.)
When one thinks about the modern world
Hello.
The kernel needs a MI interface for CPU frequency scaling. Below is a draft
that is deliberately as simple as possible.
This is NOT about frequency scaling done by the kernel as a governor
(although the long-term goal should point to that direction). The present
goal is just to add a
On Thu, Sep 22, 2011 at 08:35:02PM +0100, David Laight wrote:
I think that by MODULAR with built-in modules, you mean a barebones
kernel linked with some .kmod's? I would love to see that. What has to
happen to make it so?
Probably just some 'round tuits'.
Mostly in the area of
On Fri, Sep 23, 2011 at 08:42:16PM +0200, Joerg Sonnenberger wrote:
On Fri, Sep 23, 2011 at 01:02:52PM +0300, Jukka Ruohonen wrote:
[2] Note that even in the x86 land it is no longer necessarily known which
is the exact MHz at which the CPU currently runs (cf. TurboBoost, etc
On Sat, Sep 24, 2011 at 07:20:16AM +0200, Joerg Sonnenberger wrote:
You can not avoid providing a list of available states. Such an
interface is inherently and completely broken.
Heh, right. Why?
Nor do I see any real difference whether an user sets the CPU frequency to
{ 16 %, 35 %, 100 %
On Tue, Sep 06, 2011 at 01:39:14PM +0200, Jean-Yves Migeon wrote:
Is there a way to know what functions are available from libkern, and
those only found in userland libs? Except by looking at libkern.h?
No. While there are memcpy(9) etc., I think we should have a single
libkern(3) with
On Sun, Aug 07, 2011 at 03:10:29AM +, David Holland wrote:
So I just had an idea: since cleaning /tmp on a live system is very
dangerous unless done so (and even then somewhat dangerous), plus
there are other possible uses for automatically disappearing files:
How hard would it be to add
On Sun, Aug 07, 2011 at 07:09:14AM +, David Holland wrote:
Sounds like a job for the userland and cron(8).
uh no.
See: since cleaning /tmp on a live system is very dangerous
So care to elaborate what is dangerous about it?
I do clean /tmp daily, but it needs to be done selectively.
On Mon, Aug 01, 2011 at 08:59:57PM +0200, Matthias Drochner wrote:
I think it is OK to attach the PCI buses which are defined by ACPI
at acpi. The attachment frontend can install hooks to get interrupt
routing right. This would also help wakeup support for eg USB
and ethernet devices.
On Sat, Jul 23, 2011 at 09:35:43PM +0300, Aleksey Cheusov wrote:
* Exec logging within chroot
What's this?
It has been quite a while since I used Grsecurity, but it logs a message
every time a program is executed within a chroot. This may be useful to
audit chroot'ed daemons, but if I
On the X30 I got NetBSD-5.1 and there is no nl
keymap. Google pointed me to NetBSD problem report
number 35473.
Could Spanny patch be included into NetBSD-current ?
Yes, I will commit it shortly.
- Jukka.
On Thu, Jul 14, 2011 at 12:07:56AM +0300, Aleksey Cheusov wrote:
So what is the security policy you mean to enforce by blocking paths
into the kernel with kauth? For every `destructive modification' that
can be done to the system, what is every path into the kernel that
leads to that
On Sun, Jul 03, 2011 at 10:49:59PM +0100, Alexander Nasonov wrote:
BTW, intr/nointr is not documented in cpuctl(8).
One possible reason for this is that per-CPU intr/nointr is not yet
supported on e.g. x86, AFAIK.
- Jukka.
On Sun, Jul 03, 2011 at 07:27:00PM +0200, Manuel Bouyer wrote:
it's not only about Xen, it's about all kernels for any port which
already have DIAGNOSTIC and want to keep it even for release
(e.g. i386 ALL).
As far as I understand, i386/ALL is just for testing the compilation of
various
On Wed, Jun 15, 2011 at 09:30:17PM +0200, Manuel Bouyer wrote:
I fear so, sadly. I think DIAGNOSTIC should be back in x86 GENERIC
kernels on HEAD (this can be switched off in release branches)
Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at
least) should be enabled in
On Tue, May 31, 2011 at 10:15:36PM +0100, Mindaugas Rasiukevicius wrote:
Unless anyone objects, I will merge rmind-uvmplock branch. The technical
objectives of the branch are described here:
Indeed, and as usual, extraordinary work!
- Jukka.
On Sat, May 07, 2011 at 09:03:42PM +0200, Jean-Yves Migeon wrote:
- sysmon_pswitch(9) can still be used to register power switch events,
these events being modeled following a switch functionality e.g. when
a threshold is passed.
Yes. Although I don't know what you mean by thresholds.
-
On Fri, May 06, 2011 at 04:45:55PM +0100, Jean-Yves Migeon wrote:
1 - I shall patch sysmon_pswitch_event and add a callback for sleep
that MD code can register,
2 - or register a pmf(9) event handler during hypervisor attachment,
and just use pmf_event_inject() in the /* XXX */ sleep path
On Fri, May 06, 2011 at 10:35:30AM +0100, Jean-Yves Migeon wrote:
Yes. However, in the Xen domU case, it is quite unacceptable. Anyone
willing to suspend a domain would launch xm save from dom0. If
powerd(8) is not running, the xm save will wait ~forever for the domU
to signal it's ready
On Thu, May 05, 2011 at 05:56:43PM +0100, Jean-Yves Migeon wrote:
i am experiencing some difficulties regarding the somewhat duplicity of
functionality provided by sysmon_*(9) and pmf(9) APIs, for everything that
has to deal with power management event.
The duplicity is a known and unfortunate
On Sun, Apr 03, 2011 at 05:09:55PM +0200, Frank Wille wrote:
Did somebody already try to implement it? If not, I would suggest the
following code for src/sys/lib/libkern:
[...]
Any comments? Then please speak now. :)
Just a footnote: wouldn't sys/bitops.h be a better place logically?
-
On Sun, Apr 03, 2011 at 06:12:03PM +0200, Frank Wille wrote:
Don't know about others, but my goal was to eliminate double code from
the kernel. The use of the new functions should also be restricted
to the kernel.
While I have no real opinion for or against, I can certainly imagine finding
use
On Mon, Mar 28, 2011 at 01:33:45PM +0100, Jean-Yves Migeon wrote:
1 - modify sysmon_pswitch_event prototype so it can return an error
(therefore leaving the possibility for the caller to fix the event by
itself), OR
2 - add a MD system_suspend() routine, define it to NULL by default,
and
On Wed, Mar 23, 2011 at 05:24:12PM -0400, Thor Lancelot Simon wrote:
All cores spend well over 50% time in 'sys', even when all or almost
all are running cc1 processes. The kernel is amd64 -current GENERIC
from about 1 week ago -- no DIAGNOSTIC, DEBUG, KMEMSTATS, LOCKDEBUG,
etc.
Does
On Wed, Feb 09, 2011 at 04:47:12PM -0800, Cliff Wright wrote:
Bios is correct, and ACPI wrong, I have seen this on other
machines. And as I said in the 2007 email, even if ACPI had
been the correct one, it still was not going to setup the
interrupt.
In this area, and with the current code
On Wed, Feb 09, 2011 at 10:54:08PM -0800, Brian Buhrow wrote:
I note that at the time, I received strong objections to my patch on
the grounds that it didn't account for bioses which didn't setup the
interrupts and reported that they had. That's true, but in my patch, you
had to build a
On Mon, Oct 25, 2010 at 07:28:56PM -0500, David Young wrote:
The chief difference I see between a process limited by Capsicum and
a process limited by Systrace is that the Capsicum-limited process
has only the privileges that the parent process grants it, while the
Systrace-limited process has
On Sat, Oct 16, 2010 at 05:45:51PM -0500, David Young wrote:
Another thing is the actual device tree. For instance, currently, even with
the fine work done with pmf(9), in some corner cases we may power off a
device before its children are turned off because the device tree is
partially
On Fri, Oct 15, 2010 at 07:53:53PM -0500, David Young wrote:
OK, what this code is doing is essentially attach a device to the acpi
tree that really refers to a PCI device. Can we please get this to
attach as child of vga0 by checking for a device matching the PCI
address of vga0, that
On Fri, Oct 15, 2010 at 08:29:57AM -0400, der Mouse wrote:
ACPI may be the source of the information, but that doesn't mean it has
to be how the autoconf tree is constructed.
Compare and contrast with how NetBSD/sparc uses the OF (or is it OBP?
I'm not sure) device tree to drive autoconf,
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
The task is not trivial. On modern x86, practically *everything* that
attachs has an ACPI counterpart. In a way we are thinking this backwards:
the attachment should perhaps be done via ACPI that has information about
the natural
On Fri, Oct 15, 2010 at 10:10:18AM +0200, Martin Husemann wrote:
On Fri, Oct 15, 2010 at 08:26:34AM +0300, Jukka Ruohonen wrote:
This was discussed during the development process.
Where?
Already when this was first presented in 2008:
http://mail-index.netbsd.org/tech-kern/2008/12
On Thu, Oct 14, 2010 at 06:50:30PM -0500, David Young wrote:
Rather than attaching new nodes at acpi0, the system should let ACPI
BIOS inform the autoconfiguration process, which should attach one or
more instances of a new, MI device, display(4). For example:
vga0 at pci0 device ...
On Sun, Sep 26, 2010 at 08:48:45PM -0400, Perry E. Metzger wrote:
They did Chrome in the paper, and it required very few lines of code
(under 100). They did other tests too. It appears that they've had
quite a bit of success in creating a very usable API here. I'm not
entirely surprised, given
On Tue, Aug 31, 2010 at 04:06:16PM +1200, Mark Davies wrote:
Any suggestions on whats broke
This is again the so-called Enhanced SpeedStep (EST).
how to fix?
Disable options(4) ENHANCED_SPEEDSTEP.
- Jukka.
On Sun, Jul 25, 2010 at 09:22:53PM +, Quentin Garnier wrote:
bridges (mostly on x86). An even older idea of mine is to finally see
legacy devices listed in the ACPI tables attached to the PCI-ISA bridge
where they logically belong, and device flavours can be used for that,
too.
I am not
On Mon, Jul 26, 2010 at 06:41:11AM +1000, matthew green wrote:
it seems to me the root problem is that module_mutex is held while
calling into the module startup routines.
Here is one related question: is it ensured that the module lock is dropped
immediately after a modular device driver
On Mon, Mar 08, 2010 at 10:54:13AM -0500, der Mouse wrote:
Linux had a devfs and [dropped] it. Now it has udevd(8). Most
likely the penguins had a reason for this.
Surely there are mailing list messages or something that outline that
reason? (Not that I have any idea where they'd be,
On Sun, Mar 07, 2010 at 08:18:15PM +, Quentin Garnier wrote:
As an example: one thing that holds back the ACPI CPU code I am working on
is that I need to be sure that e.g. cpu3 that attaches to acpi0 is the same
cpu3 that has attached to mainbus0. So:
Well, the answer to that is
On Sat, Feb 06, 2010 at 01:07:08PM -0800, Paul Goyette wrote:
If it matches a device, and there is also a native driver for the
underlying i2c controller, then there'll be two devices accessing the
same bus. Bad things (tm) will happen. This is noted in the BUGS
section of the
On Sun, Feb 07, 2010 at 08:30:27AM +0100, Joerg Sonnenberger wrote:
On Sun, Feb 07, 2010 at 09:04:54AM +0200, Jukka Ruohonen wrote:
* The following sensors should be removed: technology,
low capacity, and warning capacity. These are not really
something that should be sensed
On Thu, Feb 04, 2010 at 10:15:03PM +0100, Matthias Drochner wrote:
p...@whooppee.com said:
Since the charge value was not updating, it might be that the ACPI
Notify isn't working here.
Since this involved running on battery power, I doubt it is about the
removal of the refresh routine in
62 matches
Mail list logo
