James Carlson wrote: > Darren Reed writes: >> A pair of convenience functions that I'd like to eventually >> see make their way into OpenSolaris is to copy data from a >> static buffer into an mblk and to copy data from an mblk >> into a static buffer. > > A lot depends on context: exactly what is that "static buffer" and why > isn't the existing b_rptr sufficient? Depending on what you're trying > to do, there may well be multiple possible answers. > > If it's just one mblk (and not a chain), then why doesn't bcopy() > itself work?
*If* the packet fits in a single mblk, there isn't a problem. But there is no guarantee that will always be the case and nor is there any guarantee that a pullupmsg/msgpullup will succeed. So in the interest of having fewer errors to deal with, being able to easily copy an entire dblk chain into a static buffer can make life a bit easier. In addition, if I've got a 2k buffer and I copy in 1.5k of packet data, I know I've got .5k of overhead to play with. With an mblk, I may need to add another mblk or I may need to fiddle with b_wptr or perform other exercises that increase the risk of something going astray. So, if I get a 1400 byte packet from IP, using these two convenience functions, I can copy the entire packet into my 2000 byte buffer, massage it, maybe extend it out to 1500 bytes, and copy it back again. i.e. len = msgdsize(m); buffer = kmem_alloc(len + 200); msgcopydata(m, 0, len, buffer); ... len += 23; ... msgcopyback(m, 0, len, buffer); kmem_free(buffer); At no point do I need to worry about whether or not I am going to push b_wptr past db_lim or whether or not there's more than one dblk present. In short, there are fewer worries (no need to check for all of the "problem" scenarios) and the programming is what I'd consider to be safer, even though it does have a performance cost. Darren _______________________________________________ networking-discuss mailing list [email protected]
