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 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
