As part of
4761239 Customer requests a method to clear IOSTAT statistics
a kstat_delete_persistent(9F) interface was proposed.
I wrote up a fasttrack for this, and had discussed this with the
sd target driver group. This got pushed down on the stack, and has
not poped back up yet. There may
> The second question I have is, where is this most useful? If it is only
> for DEBUG kernels, I can imagine that we could create a DEBUG behavior
> where kstat_delete() doesn't really delete the stat, but stat, but puts
> it into some kind of historical archive. (Keeping the most recent,
Correction:
On Tue, 2007-05-08 at 17:09 +0100, Darren J Moffat wrote:
> Garrett D'Amore wrote:
> > Does the HAL run independent of the desktop environment? I've not
> > looked at it, but somehow I was under the impression that the HAL was a
> > gnome-ish thing that got started with the rest of
Garrett D'Amore wrote:
Does the HAL run independent of the desktop environment? I've not
looked at it, but somehow I was under the impression that the HAL was a
gnome-ish thing that got started with the rest of the desktop startup.
YES.
HAL != GNOME
HAL !=> any window system at all.
Likewi
Darren J Moffat wrote:
Garrett D'Amore wrote:
FYI, I've been working with the battery team. I'm hoping to support
battery management on SPARC mobile platforms as well. One of the
consequences of this is that the specific ioctls/kstats/sysevents may
be subject to change in the future. I woul
On 05/08/07 16:38, Garrett D'Amore wrote:
[snip]
This sounds like an "edge" case to me. I.e. using kstats to attempt to
locate a kernel bug. (Kstats are unlikely to explain the "why" for a
failure-to-detach, or at least, they are for a driver that is detaching,
since the kstats of interest
Garrett D'Amore wrote:
FYI, I've been working with the battery team. I'm hoping to support
battery management on SPARC mobile platforms as well. One of the
consequences of this is that the specific ioctls/kstats/sysevents may be
subject to change in the future. I wouldn't start depending on
Gavin Maltby wrote:
On 05/08/07 16:11, Garrett D'Amore wrote:
Gavin Maltby wrote:
On 05/03/07 20:04, Garrett D'Amore wrote:
If the device isn't in use, then probably the historical data
simply is not interesting.
They could be useful in post-mortem debugging where they represent
a small han
FYI, I've been working with the battery team. I'm hoping to support
battery management on SPARC mobile platforms as well. One of the
consequences of this is that the specific ioctls/kstats/sysevents may be
subject to change in the future. I wouldn't start depending on them,
just yet. :-) Th
On 05/08/07 16:11, Garrett D'Amore wrote:
Gavin Maltby wrote:
On 05/03/07 20:04, Garrett D'Amore wrote:
If the device isn't in use, then probably the historical data simply
is not interesting.
They could be useful in post-mortem debugging where they represent
a small handle on past history r
James Carlson wrote:
> Thomas De Schampheleire writes:
>> No, I am not designing a CPU. What I am doing is a research project, in
>> which I will attempt to implement adaptive shutdown of processors in
>> OpenSolaris. I think I will try to use a simple module, which can possibly
>> use register_cpu
Gavin Maltby wrote:
On 05/03/07 20:04, Garrett D'Amore wrote:
If the device isn't in use, then probably the historical data simply
is not interesting.
They could be useful in post-mortem debugging where they represent
a small handle on past history relative to the snapshot-in-time
which the s
Joerg Schilling wrote:
Darren J Moffat <[EMAIL PROTECTED]> wrote:
BTW: could you point me to the new program?
The new stuff integrated into ONNV 63
http://opensolaris.org/os/community/on/flag-days/pages/2007041401/
Unfortunately, I cannot see any CLI program that supports the battery.
Unf
Paul Durrant wrote:
On 07/05/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote:
There some things I would like to make sure first: can I use all kernel
functions from a module? In Linux, modules can only use those
functions from
the kernel which are exported by the EXPORT_SYMBOL macro.
I
Darren J Moffat <[EMAIL PROTECTED]> wrote:
> > BTW: could you point me to the new program?
>
> The new stuff integrated into ONNV 63
>
> http://opensolaris.org/os/community/on/flag-days/pages/2007041401/
Unfortunately, I cannot see any CLI program that supports the battery.
This looks like a bug
On 05/08/07 10:38, Thomas De Schampheleire wrote:
But see cmi_load_module(), where we load up per-vendor CPU modules,
and the existing files under /platform/i86pc/kernel/cpu/.
I should mention that I am using UltraSPARC, and there doesn't seem to be
such cmi_* functions there. Are there oth
Thomas De Schampheleire writes:
> No, I am not designing a CPU. What I am doing is a research project, in
> which I will attempt to implement adaptive shutdown of processors in
> OpenSolaris. I think I will try to use a simple module, which can possibly
> use register_cpu_setup_func() to register a
On 5/8/07, James Carlson <[EMAIL PROTECTED]> wrote:
It's currently all bound up together, as best I understand it, because
there's no separate "CPU driver."
The entry point is cpu_setup(), which is present in each of the
per-CPU modules.
Are you designing your own SPARC CPU? If not, then I *
Joerg Schilling wrote:
Darren J Moffat <[EMAIL PROTECTED]> wrote:
Joerg Schilling wrote:
I am trying this a second time as I did not receive any
reply. I did enhance batstat again
Try the laptop community which is where batstat lives.
batstat is effectively EOF (my personal opinion anywa
Thomas De Schampheleire writes:
> > But see cmi_load_module(), where we load up per-vendor CPU modules,
> > and the existing files under /platform/i86pc/kernel/cpu/.
>
>
> I should mention that I am using UltraSPARC, and there doesn't seem to be
> such cmi_* functions there. Are there other equiv
On 05/03/07 20:04, Garrett D'Amore wrote:
If the device isn't in use, then probably the historical data simply is
not interesting.
They could be useful in post-mortem debugging where they represent
a small handle on past history relative to the snapshot-in-time
which the system crash dump repr
Hi Jiri,
> 3.0.25rc1 was released 2 days ago so the "final
> version" will be available soon. vfs_zfsacl.c module
> was tested soon so I think it is a question of 2-3
> weeks.
3 weeks after you posted this...can I ask you to update the community about the
availability of vfs_zfsacl.c module? Eve
Darren J Moffat <[EMAIL PROTECTED]> wrote:
> Joerg Schilling wrote:
> > I am trying this a second time as I did not receive any
> > reply. I did enhance batstat again
>
> Try the laptop community which is where batstat lives.
>
> batstat is effectively EOF (my personal opinion anyway but I'm
Joerg Schilling wrote:
I am trying this a second time as I did not receive any
reply. I did enhance batstat again
Try the laptop community which is where batstat lives.
batstat is effectively EOF (my personal opinion anyway but I'm fairly
sure Casper would agree) now since we have battery
Hi
On 05/07/07 21:48, Peter Tribble wrote:
[cut]
So there is a small chance that back in sfmmu_shadow_hcleanup we could
still see the hblk_cnt and hblk_hmecnt non-zero, which is the comment
you have highlighted. In that case we do not remove the block from
the hash chain, and proceed on to the
On 07/05/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote:
There some things I would like to make sure first: can I use all kernel
functions from a module? In Linux, modules can only use those functions from
the kernel which are exported by the EXPORT_SYMBOL macro.
I suppose there is a sim
Hi,
On 5/7/07, James Carlson <[EMAIL PROTECTED]> wrote:
Thomas De Schampheleire writes:
> > Right. So, you have your service method just touch the driver to have
> > it loaded.
>
>
> Does this mean that the _init functions *will* be called?
Those are always called as the module is brought int
27 matches
Mail list logo
