Re: [PATCH] SCSI and FC Transport: add netlink support for posting of transport events

[Mike Anderson <andmike@us.ibm.com>]

James Smart <James.Smart@Emulex.Com> wrote:
> Mike Anderson wrote:
> >What about using netlink attributes? The attributes do have more overhead,
> >but it would seem that using attributes instead of sending out a
> >whole structure would make it easier on the user space side to support
> >different kernel versions without syncing the tools with the kernel.
> 
> Yeah, I guessed you were going to raise this.
> 
> I just didn't see any advantage to it. The macros really didn't help with
> anything really interesting, such as endianness. I guess they do help with
> some potential structure packing issues. I saw them as just ensuring that
> you walked on the path right - which for most intents and purposes, you
> will as you really are not self-discovering data. As long as you use
> well-defined types and watch the structure alignments, it should be fine.
> The overhead didn't seem worthit. Enlighten me if I'm taking them too 
> lightly.

Packing issue avoidance was a feature of attributes that got me to start
using them.

It also allows better organization of the data through nested attributes or
even just straight attributes. Allowing for a single large allocation and
then multiple users can add to the payload prior to the send.

While attributes are not the only solution it appears right now in the
patch that we could optimize the send sequence. Currently for an event we
allocate an event only to allocate a skb shortly after to copy the event
data into and then free the previous allocated event.

> 
> I'm assuming your "syncing the tools with the kernel" statement infers the
> use of a version element in place of the attributes above. I don't see how
> you lose the version. It's the key for the later structure decode regardless
> of whether it's attribute-ized or not. Am I missing something ? I'm also
> (obviously) a proponent of the version so that a tool can provide backward
> compatibility, or spot new un-recognized data.

Since an attribute is not exposing the data as a fixed structure it leads
to more options in the future of reorganizing the data. An old program
running on a new kernel would be able to pick up known attributes while
ignoring others. One could never reorg the structure and always add to the
end of the structure which would address the issue also without using
attributes.



-andmike
--
Michael Anderson
andmike@us.ibm.com