Scott Davenport @ Sun: (Mainly) Fault Management

After a few false starts getting dmidecode promoted to the /contrib repo, yesterday's refresh finally pulled the package in. I talked about my reasons for porting this utility in my prior blog on dmidecode.

So fire up package-manager and install it - or use the groovy install link from the repo directly.

:wq

In a Nehalem whitepapter dated roughly to mid-2008, there's a bullet point on Page 7 under the Intel® QuickPath Architecture Performance that while brief speaks volumes. It reads:

Intel® QuickPath Architecture Performance
...
- Hot plug capability to support hot plugging of nodes, such as processor cards.

The implication here is far-reaching. Systems will be designed that allow for dynamically adding processor nodes (and assumedly the memory and IOH that go with the socket, too). I can see such a feature being used for dynamically growing capacity as application demands rise. Or as a RAS feature, bringing in new hardware to backfill for components that have been faulted and/or isolated (e.g. via Solaris FMA's CPU retire functions).

As Intel's engagement in the OpenSolaris community has continued, the first step toward readying Solaris for the hot-add capabilities of Nehalem hits build 123. This first round of changes lay down the ACPI infrastructure future phases of support will rely upon. Kudos out to Gerry Liu at Intel for getting the code into OpenSolaris. Places to get more details:

• PSARC/2009/104 Hot-Plug Support for ACPI-based Systems
• 6846944Device tree creation and acpi virtual nexus driver for acpi based x86 systems
• 6849408 Device matching rule in ppm.conf is not flexible enough

And of course me in my FMA world will get more excited as Solaris continues to be able to fault manage newly added resources. More to come on that I'm sure...

:wq

A few weeks ago, I blogged about my initial port of dmidecode into the SourceJuicer (SJ). Since then, I've been working on getting the package "promoted" to the /contrib repository. While doing this, I learned a bit about the %attr directives.

One of the comments I'd gotten was to tighten up the permissions on the binaries and man pages. In the initial port, the spec file did this for the packaging:

%files %defattr (-, root, bin) %doc AUTHORS CHANGELOG README %dir %attr(0755, root, bin) %{_sbindir} %{_sbindir}/* %dir %attr(0755, root, bin) %{_mandir} %{_mandir}/*/*

While the directory attributes were explicitly set, the file attributes weren't. So I tried this:

%files %defattr (-, root, bin) %doc AUTHORS CHANGELOG README %dir %attr(0755, root, bin) %{_sbindir} %attr(0555, root, bin) %{_sbindir}/* %{_sbindir}/* %dir %attr(0755, root, bin) %{_mandir} %attr(0444, root, bin) %{_mandir}/*/* %{_mandir}/*/*

Wonderful. Now the permissions are tighter on the binaries and man pages. However, the SJ build was quite unhappy.

pkgbuild: Creating packages... pkgbuild: pkgbuild: File listed twice: usr/sbin/biosdecode pkgbuild: pkgbuild: File listed twice: usr/sbin/dmidecode pkgbuild: pkgbuild: File listed twice: usr/sbin/ownership pkgbuild: pkgbuild: File listed twice: usr/sbin/vpddecode pkgbuild: pkgbuild: File listed twice: usr/share/man/man8/biosdecode.8 pkgbuild: pkgbuild: File listed twice: usr/share/man/man8/dmidecode.8 pkgbuild: pkgbuild: File listed twice: usr/share/man/man8/ownership.8 pkgbuild: pkgbuild: File listed twice: usr/share/man/man8/vpddecode.8

After quite a bit of trial and error, I realized that when the %attr directive is used for a file or set of files, the files the directive references are included in the package. So the final %files section is:

%files %defattr (-, root, bin) %doc AUTHORS CHANGELOG README %dir %attr(0755, root, bin) %{_sbindir} %attr(0555, root, bin) %{_sbindir}/* %dir %attr(0755, root, bin) %{_mandir} %attr(0444, root, bin) %{_mandir}/man8/*

The moral of the story is that when using %attr you don't need (and don't want :) individual lines listing the sames files for inclusion in the package.

:wq