> Quoth Michael Shapiro on Sat, Nov 25, 2006 at 01:16:23PM -0800: > > ipmievd listens for IPMI events over the BMC device, and then can syslog > > some of the results (e.g. if an IPMI event is posted saying that some > > h/w failed). Aside: this is an opensource thing; the actual Solaris > > functionality here should be done using FMA, but that's another story ... > > Why would anyone want to enable or disable it?
Two reasons: (a) because you don't want it whining in syslog because you want to use some other interface for management e.g. snmp, or (b) because we have something better integrated in fmd. When (b) shows up we will likely have ipmievd disabled by default, as it will be obviated by FMA. > ... > > One final comment here: although the above mechanism could be used for > > ipmievd > > and definitely is needed for a few other things, it's also worth noting that > > ipmievd's needs could be expressed in a different way: namely as a device > > dependency. That is, another potential missing mechanism in SMF which we > > had > > discussed long ago was a dependency on a /dev path, which is really what > > ipmievd is trying to express. This is even more conducive to the kind of > > reporting I mention above, because svcs -x would then be able to produce > > a message of the form "disabled because /dev/bmc isn't present on your > > system" > > This doesn't sound like a bad idea, but it's not clear to me how it > would work: Would this only work for paths which are absent when the > underlying hardware is absent? Has devname made this the case for all > devices? Should svc.startd somehow listen for device changes? Or would > it suffice to support hot-pluggable devices later? You have to listen for device events. As an example, if I don't have the driver, then the service won't start. But if I add_drv it and it attaches, that should start the service. All of the necessary devfs events already exist, so this shouldn't be a problem. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
