First, I should say that what m_pulldown() does is somewhat ok, I think.
Whilst at first I thought its role was meant to be analogous to m_pullup,
what it really does deserves the name more like m_contiguousbytes().
Only when called with off=0 does its behaviour resemble m_pullup().

On to the topic of m_pullup(), at some point in time it has been changed
such that it will not do a pullup of data large than a single mbuf.
Looking quickly, I found a comment in the CLNP code that expected the
pullup to work for larger packets - as I would - by putting it in a
cluster.  This could, I believe, be accomplished with a simple change:

*** uipc_mbuf.c Thu Apr 29 05:46:42 2004
--- uipc_mbuf.c.v3      Thu Apr 29 16:48:23 2004
***************
*** 796,802 ****
                len -= m->m_len;
        } else {
                if (len > MHLEN)
!                       goto bad;
                MGET(m, M_DONTWAIT, n->m_type);
                if (m == 0)
                        goto bad;
--- 796,802 ----
                len -= m->m_len;
        } else {
                if (len > MHLEN)
!                       return m_pulldown(n, 0, len, NULL);
                MGET(m, M_DONTWAIT, n->m_type);
                if (m == 0)
                        goto bad;

Now, I have another problem...M_ROMAP & M_READONLY.  M_ROMAP appears:

/usr/src/sys/kern/uipc_socket.c
/usr/src/sys/arch/arm/arm32/bus_dma.c
/usr/src/sys/sys/mbuf.h
/usr/src/sys/nfs/nfs_vnops.c
/usr/src/sys/nfs/nfs_serv.c
/usr/src/sys/nfs/nfs_subs.c

...and so one might surmise that its purpose is to mark external mbuf
data as being mapped read-only.  I'm curious as to why only arm32's
bus_dma consider's this significant.

Strangely, the M_ROMAP flag does not directly imply M_READONLY, but
by virtue of how mbufs are setup for M_ROMAP, M_READONLY should always
be true.  I'm not 100% sure if this is satisfactory - a more explicit
relationship between these two wouldn't be missed.

Darren