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

Reply via email to