Maksim Yevmenkin wrote this message on Mon, May 02, 2005 at 09:38 -0700:
i think we have few options here:
1) revert back original tapwrite function that was changed in v. 1.48 and set offset to 2 bytes in top mbuf
2) change current version of tapwrite so it would m_prepend and m_pullup mbuf after m_uiotombuf
3) change m_uiotombuf to accept one more parameter - mbuf offset at which data should be copied. there are not that many users of m_uiotombuf
please find and review the attached patch (untested) that implements option (3) above.
any objections to the attached (revised) patch? can i commit it?
thanks, max
Index: sys/kern/uipc_mbuf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.147 diff -u -r1.147 uipc_mbuf.c --- sys/kern/uipc_mbuf.c 17 Mar 2005 19:34:57 -0000 1.147 +++ sys/kern/uipc_mbuf.c 2 May 2005 16:33:41 -0000 @@ -1333,7 +1333,7 @@ #endif
struct mbuf * -m_uiotombuf(struct uio *uio, int how, int len) +m_uiotombuf(struct uio *uio, int how, int len, int align) { struct mbuf *m_new = NULL, *m_final = NULL; int progress = 0, error = 0, length, total; @@ -1342,12 +1342,15 @@ total = min(uio->uio_resid, len); else total = uio->uio_resid; - if (total > MHLEN) + if (align >= MHLEN) + goto nospace; + if (total + align > MHLEN)
I kinda noticed this a bit ago, but didn't think much of it till now... do we want to allow align >= MHLEN if total requires a cluster? since if we use a cluster, we'd have enough space for a larger align...
well, you got me here :) MHLEN is 200+ bytes, so i can not imagine why one would want to align something on 200+ bytes. i was kind of hoping that no one would ever need to align on anything greater then 128 bytes. perhaps i'm wrong here?
thanks, max
_______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
