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 with
[ 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 to or
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
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
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, 27 Aug 2000 14:25:55 -0700 (PDT), Archie Cobbs [EMAIL PROTECTED] 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
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
