If we're going to talk about 'health' for a machine and it's components, it
should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel).
>
> On 12-Jan-01 Mitsuru IWASAKI wrote:
> > Hi,
> >
> >> > I'll get device major number for /dev/power and commit them within a
> >> > few days if no objection.
> >>
> >> One thing that I was talking about with Mike Smith is that perhaps instead
> >> of
> >> having a /dev/power just for power management stuff we should be a bit more
> >> generic and have a /dev/health used for anything related to the machine's
> >> "health"? This could include power management, thermal zones, etc. BTW,
> >> the
> >
> > I'm not sure if /dev/health is better but I think having common API
> > for the machine's health is good thing. How about having /dev/power,
> > /dev/thermal or whatever related with machine's health as abstracted
> > layers, and creating API libraries for each subsystems like libpower,
> > then providing libhealth as full-set API for the applications?
>
> It was just an idea to think about is all. :) However you do it will probably
> be fine. I'm not really working on this code enough to make too many
> suggestions right now. :)
>
> >> battery status doesn't work on my laptop unfortunately, but that is because
> >> I
> >> have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot.
> >> :(
> >
> > Is that related with embedded controller too?
>
> Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info
> and find out where it hangs when I don't disable the SIO_ controller.
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
