|
Replies:
4
-
Last Post:
Jan 5, 2009 4:55 AM
by: moredhel
|
|
|
Posts:
35
From:
UK
Registered:
6/14/05
|
|
|
|
[fm-discuss] When do the FMD APIs become usable outside Sun?
Posted:
Dec 5, 2008 8:40 AM
|
|
Hi, My developer customer has asked the following question of me, but
it seems here is the best place to actually get an answer:
> Currently our event management uses the traditional syslog based
> approach (monitoring the messages written to /dev/log) for OS/OEM
> error reporting and clearance. It is planned that event management
> should make use of the Fault Management facilities available in
> Solaris 10 for the same because of its many advantages. The CR
> addresses this change. For this purpose, we would require to write our
> own modules which can register with fmd, subscribe to different
> classes of events and report the received events as our own events.
> Hence we need the support for external modules from fmd and also the
> client interfaces to be exposed so that we can use them.
>
> The header file /usr/include/fm/fmd_api.h present on our nodes has a
> comment saying that these interfaces should not be used outside Sun
> until it is publicly documented.
>
> The following link lists the client interfaces of fmd. The chapter
> 2.1.3 says external modules are not currently supported and will be
> supported in future.
>
> _http://opensolaris.org/os/community/fm/files/FMDPRM.pdf_
> <http://
>
>
> I have some queries related to Solaris 10 Fault Management Daemon
> (fmd) client interfaces (present in the header file
> /usr/include/fm/fmd_api.h):
>
> 1) Are these interface exposed for applications currently? If not, by
> when Sun is expecting to do this?
>
> 2) Does fmd currently support external modules (diagnosis engines
> and/or response agents). If not, by when this support will be provided.
>
So, how close to stable are these in OpenSolaris, and when will they
become "Public" In Solaris 10?
Ta,
Mark.
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
Posts:
356
From:
AU
Registered:
3/9/05
|
|
|
|
Re: [fm-discuss] When do the FMD APIs become usable outside Sun?
Posted:
Dec 7, 2008 7:41 PM
in response to: moredhel
|
|
Hi,
Mark R. Bowyer wrote:
> Hi, My developer customer has asked the following question of me, but
> it seems here is the best place to actually get an answer:
>
>> Currently our event management uses the traditional syslog based
>> approach (monitoring the messages written to /dev/log) for OS/OEM
>> error reporting and clearance. It is planned that event management
>> should make use of the Fault Management facilities available in
>> Solaris 10 for the same because of its many advantages. The CR
>> addresses this change. For this purpose, we would require to write our
>> own modules which can register with fmd, subscribe to different
>> classes of events
Are we thinking of existing events here, or of new events to be generated
by customer-provided software? Is the intention to propogate
error report events themselves, or to propagate fault diagnoses that
may arise from that ereport telemetry stream?
>> and report the received events as our own events.
>> Hence we need the support for external modules from fmd and also the
>> client interfaces to be exposed so that we can use them.
I don't see that the above necessarily requires the use of external
modules? An external module (no support implemented as yet, as noted)
is one which is realized in a separate address space, ie process, to
the fault management daemon fmd; all our modules today are .so
objects that are dlopen'd into the fmd address space.
The above could most likely be realized as a non-external module.
The advantage to having it as an external module would be that
it could fail reasonably independently of the fault manager itself,
eg a SIGSEGV in the external module would not harm the state of fmd.
Similarly, modules that deal with notoriously badly behaved hardware,
say writing to FRUID over I2C buses, would be better housed in
external modules to try to isolate fmd from those failures.
As I said, so far we've only used non-external modules. Partly that
is because (on systems that implement DFRUID updates) the DFRUID
updates are perfomed on a service processor, and the Solaris fmd
modules are for the most part pretty clean-living and not too
dangerous to fmd itself.
>> The header file /usr/include/fm/fmd_api.h present on our nodes has a
>> comment saying that these interfaces should not be used outside Sun
>> until it is publicly documented.
>>
>> The following link lists the client interfaces of fmd. The chapter
>> 2.1.3 says external modules are not currently supported and will be
>> supported in future.
Indeed. I am just spinning up a project that may itself have a good
reason to use external modules, so that *may* lead us to implement
them in Nevada (and OpenSolaris). If implemented, there's no guarantee
at all that they'd go back to Solaris 10 unless someone makes a strong
case for it (or some new platform requires it etc).
>> _http://opensolaris.org/os/community/fm/files/FMDPRM.pdf_
>> <http://
Yes these interfaces are still all private in one form or another - Appendix A
lists the levels. They're private as in "subject to change without
notification", no as in "secret" of course. The FMD_API_VERSION
is only at 4 now (started at 1) so we're not making frequent
incompatible changes, so we could certainly look at raising the
commitment level soon. Alternatively they can of course be
used at your own risk today, but you may have to
redeliver for each S10 update etc.
>>
>> I have some queries related to Solaris 10 Fault Management Daemon
>> (fmd) client interfaces (present in the header file
>> /usr/include/fm/fmd_api.h):
>>
>> 1) Are these interface exposed for applications currently? If not, by
>> when Sun is expecting to do this?
No - as per Appendix A they're all private to the ON consolidation or
our project.
We have no schedule planned for exposing these interfaces. We're open
to raising the stability level, but we can't lock it down so tight that
future projects are restricted from making any changes. I'd
guess that we could raise it to a level that won't change incompatibly
in Solaris 10, but allows change in the next minor release (i.e, 5.11
aka Nevada & OpenSolaris).
>> 2) Does fmd currently support external modules (diagnosis engines
>> and/or response agents). If not, by when this support will be provided.
There is no schedule - nothing delivered in Solaris has really required
them as yet. As I said above I may have a need for them in a new
(as yet very vague) project.
Gavin
>
> So, how close to stable are these in OpenSolaris, and when will they
> become "Public" In Solaris 10?
>
> Ta,
> Mark.
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris dot org
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
35
From:
UK
Registered:
6/14/05
|
|
|
|
Re: [fm-discuss] When do the FMD APIs become usable outside Sun?
Posted:
Dec 8, 2008 12:33 AM
in response to: gavinm
|
|
Many thanks, Gavin =O)
Mark.
Gavin Maltby wrote:
> Hi,
>
> Mark R. Bowyer wrote:
>> Hi, My developer customer has asked the following question of me, but
>> it seems here is the best place to actually get an answer:
>>
>>> Currently our event management uses the traditional syslog based
>>> approach (monitoring the messages written to /dev/log) for OS/OEM
>>> error reporting and clearance. It is planned that event management
>>> should make use of the Fault Management facilities available in
>>> Solaris 10 for the same because of its many advantages. The CR
>>> addresses this change. For this purpose, we would require to write our
>>> own modules which can register with fmd, subscribe to different
>>> classes of events
>
> Are we thinking of existing events here, or of new events to be generated
> by customer-provided software? Is the intention to propogate
> error report events themselves, or to propagate fault diagnoses that
> may arise from that ereport telemetry stream?
>
>>> and report the received events as our own events.
>>> Hence we need the support for external modules from fmd and also the
>>> client interfaces to be exposed so that we can use them.
>
> I don't see that the above necessarily requires the use of external
> modules? An external module (no support implemented as yet, as noted)
> is one which is realized in a separate address space, ie process, to
> the fault management daemon fmd; all our modules today are .so
> objects that are dlopen'd into the fmd address space.
>
> The above could most likely be realized as a non-external module.
> The advantage to having it as an external module would be that
> it could fail reasonably independently of the fault manager itself,
> eg a SIGSEGV in the external module would not harm the state of fmd.
> Similarly, modules that deal with notoriously badly behaved hardware,
> say writing to FRUID over I2C buses, would be better housed in
> external modules to try to isolate fmd from those failures.
>
> As I said, so far we've only used non-external modules. Partly that
> is because (on systems that implement DFRUID updates) the DFRUID
> updates are perfomed on a service processor, and the Solaris fmd
> modules are for the most part pretty clean-living and not too
> dangerous to fmd itself.
>
>>> The header file /usr/include/fm/fmd_api.h present on our nodes has a
>>> comment saying that these interfaces should not be used outside Sun
>>> until it is publicly documented.
>>>
>>> The following link lists the client interfaces of fmd. The chapter
>>> 2.1.3 says external modules are not currently supported and will be
>>> supported in future.
>
> Indeed. I am just spinning up a project that may itself have a good
> reason to use external modules, so that *may* lead us to implement
> them in Nevada (and OpenSolaris). If implemented, there's no guarantee
> at all that they'd go back to Solaris 10 unless someone makes a strong
> case for it (or some new platform requires it etc).
>
>>> _http://opensolaris.org/os/community/fm/files/FMDPRM.pdf_
>>> <http://
>>>
>
> Yes these interfaces are still all private in one form or another -
> Appendix A
> lists the levels. They're private as in "subject to change without
> notification", no as in "secret" of course. The FMD_API_VERSION
> is only at 4 now (started at 1) so we're not making frequent
> incompatible changes, so we could certainly look at raising the
> commitment level soon. Alternatively they can of course be
> used at your own risk today, but you may have to
> redeliver for each S10 update etc.
>>>
>>> I have some queries related to Solaris 10 Fault Management Daemon
>>> (fmd) client interfaces (present in the header file
>>> /usr/include/fm/fmd_api.h):
>>>
>>> 1) Are these interface exposed for applications currently? If not, by
>>> when Sun is expecting to do this?
>
> No - as per Appendix A they're all private to the ON consolidation or
> our project.
>
> We have no schedule planned for exposing these interfaces. We're open
> to raising the stability level, but we can't lock it down so tight that
> future projects are restricted from making any changes. I'd
> guess that we could raise it to a level that won't change incompatibly
> in Solaris 10, but allows change in the next minor release (i.e, 5.11
> aka Nevada & OpenSolaris).
>
>>> 2) Does fmd currently support external modules (diagnosis engines
>>> and/or response agents). If not, by when this support will be provided.
>
> There is no schedule - nothing delivered in Solaris has really required
> them as yet. As I said above I may have a need for them in a new
> (as yet very vague) project.
>
> Gavin
>
>>
>> So, how close to stable are these in OpenSolaris, and when will they
>> become "Public" In Solaris 10?
>>
>> Ta,
>> Mark.
>> _______________________________________________
>> fm-discuss mailing list
>> fm-discuss at opensolaris dot org
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
35
From:
UK
Registered:
6/14/05
|
|
|
|
Re: [fm-discuss] When do the FMD APIs become usable outside Sun?
Posted:
Dec 17, 2008 7:33 AM
in response to: moredhel
|
|
Hi again,
My customer has some further questions:
> > Are we thinking of existing events here, or of new events to be
> > generated by customer-provided software? Is the intention to
> > propogate error report events themselves, or to propagate fault
> > diagnoses that may arise from that ereport telemetry stream?
> >
> <Nishanth> TSP event management wants to propagate all the error
> telemetry events and fault diagnoses generated by the existing
> components (which use Solaris 10 FMA) as well as the new components
> which will be integrated in future (which will use Solaris 10 FMA).
:
> > The above could most likely be realized as a non-external module.
> > The advantage to having it as an external module would be that it
> > could fail reasonably independently of the fault manager itself, eg a
> > SIGSEGV in the external module would not harm the state of fmd.
> > Similarly, modules that deal with notoriously badly behaved hardware,
> > say writing to FRUID over I2C buses, would be better housed in
> > external modules to try to isolate fmd from those failures.
> >
> <Nishanth> This is exactly the reason why I mentioned that we need
> external module support. I don’t think it is a good idea to write a TSP
> module which registers with fmd as a plug-in (non-external) module. It is
> not good to have internal errors of a TSP module affecting Solaris 10 fmd.
:
> > Yes these interfaces are still all private in one form or another -
> > Appendix A lists the levels. They're private as in "subject to change
> > without notification", no as in "secret" of course. The
> > FMD_API_VERSION is only at 4 now (started at 1) so we're not making
> > frequent incompatible changes, so we could certainly look at raising
> > the commitment level soon. Alternatively they can of course be used
> > at your own risk today, but you may have to redeliver for each S10
> > update etc.
> <Nishanth> So is it currently in a state to start using these interfaces
> outside Sun (for eg: in TSP) to develop a module, keeping this risk in mind?
:
> In addition, I have a further question:
>
> We could not see any fmd client API which can be used by a client
> module to interpret the different fields of a received event (error
> telemetry event and/or fault event). Are such APIs not existing? If
> not, will they be provided?
I think they're ready to start coding, but want us to say they can, as
long as they're aware of these risks? What do you think?
Ta,
--
| o o Software Support Engineering,
/v\ark R. Bowyer. SPARC House, Guillemont Park,
`-' Minley Rd, Blackwater,
Tel: +44 (0)1252 420691 Camberley, SURREY, GU17 9QG
Fax: +44 (0)1252 421658 United Kingdom __|
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
Posts:
35
From:
UK
Registered:
6/14/05
|
|
|
|
Re: [fm-discuss] When do the FMD APIs become usable outside Sun?
Posted:
Jan 5, 2009 4:55 AM
in response to: moredhel
|
|
Hi,
Can anyone add to this?
Thanks,
Mark.
On Wed, 2008-12-17 at 15:33 +0000, Mark R. Bowyer wrote:
> Hi again,
>
> My customer has some further questions:
>
> > > Are we thinking of existing events here, or of new events to be
> > > generated by customer-provided software? Is the intention to
> > > propogate error report events themselves, or to propagate fault
> > > diagnoses that may arise from that ereport telemetry stream?
> > >
> > <Nishanth> TSP event management wants to propagate all the error
> > telemetry events and fault diagnoses generated by the existing
> > components (which use Solaris 10 FMA) as well as the new components
> > which will be integrated in future (which will use Solaris 10 FMA).
> :
> > > The above could most likely be realized as a non-external module.
> > > The advantage to having it as an external module would be that it
> > > could fail reasonably independently of the fault manager itself, eg a
> > > SIGSEGV in the external module would not harm the state of fmd.
> > > Similarly, modules that deal with notoriously badly behaved hardware,
> > > say writing to FRUID over I2C buses, would be better housed in
> > > external modules to try to isolate fmd from those failures.
> > >
> > <Nishanth> This is exactly the reason why I mentioned that we need
> > external module support. I don’t think it is a good idea to write a TSP
> > module which registers with fmd as a plug-in (non-external) module. It is
> > not good to have internal errors of a TSP module affecting Solaris 10 fmd.
> :
> > > Yes these interfaces are still all private in one form or another -
> > > Appendix A lists the levels. They're private as in "subject to change
> > > without notification", no as in "secret" of course. The
> > > FMD_API_VERSION is only at 4 now (started at 1) so we're not making
> > > frequent incompatible changes, so we could certainly look at raising
> > > the commitment level soon. Alternatively they can of course be used
> > > at your own risk today, but you may have to redeliver for each S10
> > > update etc.
> > <Nishanth> So is it currently in a state to start using these interfaces
> > outside Sun (for eg: in TSP) to develop a module, keeping this risk in mind?
> :
> > In addition, I have a further question:
> >
> > We could not see any fmd client API which can be used by a client
> > module to interpret the different fields of a received event (error
> > telemetry event and/or fault event). Are such APIs not existing? If
> > not, will they be provided?
>
> I think they're ready to start coding, but want us to say they can, as
> long as they're aware of these risks? What do you think?
>
> Ta,
> _______________________________________________
> fm-discuss mailing list
> fm-discuss at opensolaris dot org
--
| o o Software Support Engineering,
/v\ark R. Bowyer. SPARC House, Guillemont Park,
`-' Minley Rd, Blackwater,
Tel: +44 (0)1252 420691 Camberley, SURREY, GU17 9QG
Fax: +44 (0)1252 421658 United Kingdom __|
_______________________________________________
fm-discuss mailing list
fm-discuss at opensolaris dot org
|
|
|
|
|
