> So sort this out, any mechanism that requires prepending stuff is > probably not the best. Also adding the constraints that mblks are in > use by loads of things and is exposed externally for decades, you need > to maintain backward compatibility as well. One such idea that we have > kicked around during fireEngine timeframe was creating something called > mblk_ext_t which has mblk_t embedded. So code that only knows about > mblks still works but more information (attributes) can be added at the > end and transport through layers transparently. The issue being do we > put a flag for each attribute in b_flag? If yes, it does help the > paths which don't care about any attribute but if you are expecting > something, you need to still check the flags. Plus do we allocate > a mblk with space for each possible attribute type or do we do lazy > allocate etc etc.
Why not flesh out M_MULTIDATA further? It has a nice programming API, and already has support for attributes. -- meem _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
