James Carlson wrote:
> Garrett D'Amore writes:
>
>> One significant problem with mcopymsg() is that it freemsg()'s the
>> source mblk. This is an unexpected (and previously undocumented) side
>> effect. (I filed a man page bug, which was fixed, to get the side
>> effect documented.)
>>
>
> As I mentioned first in my message:
>
>
>>> 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.
>>>
>
> In other words, the real answer depends on what you're actually trying
> to do. Designing this thing without a clear target usage (and, no, I
> do *NOT* consider "simply copying to and from a static buffer" to be
> such a target) is going to be hard.
>
> We've all got clearly different assumptions.
>
>
>> I wouldn't complain if something like mcopymsg() were created that
>> lacked the side effect, mcopydata() or somesuch.
>>
>
> But is that exactly what's needed here? It's impossible to tell from
> the information given.
>
I've needed such a function in my own work. So in the past I've either
restructured my code to make use of the side effect, or implemented my
own version of mcopymsg. mcopymsg is useful when copying tx mblks into
a DMA buffer, where you know you can toss the mblk when its done, but
there are cases that come up where you can't or don't want to do that.
For example, you may wish to copy the msg into an aligned DMA region,
and need to do that (for performance) *before* acquiring the locks
associated with a tx ring. After acquiring such locks, you might find
that the ring itself is full, so you need to re-queue the msg for later
delivery (in Nemo, this is done by m_tx() returning the original
message.) mcopymsg()'s side effect here is toxic.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
