[ note: trimming -current from the CC: list ]
Bosko Milekic writes:
> 1)The mbuf should be marked read-only explicitly with a single
> additional M_FLAG.
>
> #define M_RDONLY0x0x2000
>
> 2)The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is
> equal
On Sun, 27 Aug 2000, David Malone wrote:
[...]
> (This is why the flag I was talking about in the other mail
> would be useful for spotting other cases where the storage
> may be writable, even if it's not a cluster).
Thoughts:
1) The mbuf should be marked read-only explicitly wit
David Malone writes:
> We were thinking it might be a good idea to have a flag associated
> with mbufs which means they are writable, providing the reference
> count is 1. Then we can provide a macro for checking writability.
> This flag could be set on jumbo ethernet buffers, but not sendfile
> b
< said:
> However, many routines that take an mbuf parameter assume that the
> mbuf given to them is modifiable and proceed to write all over it.
s/assume/require as a necessary precondition/
It's not a coding error, it's part of the specification. No, it's not
documented -- but it's pretty cl
On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote:
> Each mbuf may be either a normal mbuf or a cluster mbuf (if the
> mbuf flags contains M_EXT). Cluster mbufs point to an entire page
> of memory, and this page of memory may be shared by more than one
> cluster mbuf (see m_copypacket(
On Sun, Aug 27, 2000 at 02:25:55PM -0700, Archie Cobbs wrote:
> What do people think? If this is generally agreeable I'll try to
> work on putting together a patch set for review.
Myself and Ian Dowse have been talking about almost this issue
recently in relation to sbcompress. At the moment sbc
In looking at some of the problems relating to divert, bridging,
etc., it's apparent that lots of code is breaking one of the rules
for handling mbufs: that mbuf data can sometimes be read-only.
Each mbuf may be either a normal mbuf or a cluster mbuf (if the
mbuf flags contains M_EXT). Cluster mb
