Specification update for Pluggable fwflash [PSARC/2009/163 FastTrack timeout 03/16/2009]
James Carlson
james.d.carlson at sun.com
Wed Mar 11 06:24:34 PDT 2009
James C. McPherson writes:
> > Reading the existing header file, it seems that plugins must define a
> > uint32_t variable (not a struct) that has the name "fwplugin_version",
> > and that's what's used for the versioning, not "plugin_version" as
> > above.
> > Is that correct, or are there other changes here? Does the integer
> > change to a structure? Is there a new variable?
>
> Reviewing the existing header file, I see that there are
> extraneous comments about versioning left over from a very
> early version of the original spec.
Ah, ok. I was trying to match up this proposal with what I thought
was implemented in that file ... that's obviously a mistake.
> The existing comments are wrong, not only are plugins not required
> to define any version-related element in any structure, but even
> if they did (now), we have no way of using that information.
>
> We are proposing to add the integer plugin_version (or fwplugin_version,
> I'm not wedded to the exact name). There is no new structure.
OK. In that case, if there's no existing code, I don't care what you
use. The "plugin_version" you proposed is fine.
> For the teardown part, that's pretty much how I've got it implemented
> (except for the #define name) in my prototype.
The differences are:
- I'm suggesting it's not an error to leave out [leave as NULL]
fw_cleanup in a newly compiled plug-in. (The spec here seems to
say it is an error, but perhaps it's actually referring to
truncating the structure in some way -- which seems like it should
be a logical impossibility, and impossible to detect as well.)
- Having a neutrally-named #define means you can get source level
compatibility. (That is, you can recompile on a new system, get
whatever structure is in the header file on that system, and get a
properly matching version number for the new structure without
having to change your source.)
They're attempts to smooth out future changes, but they're minor nits,
and regardless of the direction you go, +1.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
More information about the opensolaris-arc
mailing list