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

[James Smart <James.Smart@Emulex.Com>]

Mike,

So I'm converting this over, and I really don't like using attributes.

My first major hurdle is that I have to update the netlink library to support a
new "binary blob" attribute, that may be of arbitrary length, similar to the
"string" attribute.

My second hurdle is dealing with arbitrary-sized messages. Due to their existence
and their rarity, I punted on creating fixed size mempools. Headache I have now
is trying to size the skb payload. It has to be large enough for the
variable-length payload, plus large enough for all the attribute overhead for
each field element, and any padding. Yech!

Coding-wise, the format and understanding of what message has what data is
more confusing. It pushes for a flat "attribute" space for all message
elements.  Minimally, it requires a lot more formality of data structures to
impose "structure" on the elements. Pure overhead and less clarity.

I started using your dm patch as a reference and came away scratching my head.
It uses both a packed structure (for a header) followed by attribute-based
data (actual message elements). Seemed real odd that we would use both, and if
we trust it for one, why not the other ?

Also, there was one other "pro" where you dinged the implementation that
wasn't fully true...
 > 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.
As implemented, we could always add elements, but never reorg or subtract,
and the app would continue to work fine. This is due to the msglen field
being in place.


So, I currently want to update the patch only to optimize allocations on
the send sequence.  Would you buy into this ?

-- james