Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Aug 2000 20:46:20 +0100
From:      Ian Dowse <iedowse@maths.tcd.ie>
To:        Bosko Milekic <bmilekic@dsuper.net>
Cc:        David Malone <dwmalone@maths.tcd.ie>, Archie Cobbs <archie@whistle.com>, freebsd-net@FreeBSD.ORG
Subject:   Re: Proposal to clarify mbuf handling rules 
Message-ID:   <200008282046.aa01881@salmon.maths.tcd.ie>
In-Reply-To: Your message of "Mon, 28 Aug 2000 14:06:08 EDT." <Pine.BSF.4.21.0008281340570.7945-100000@jehovah.technokratis.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0008281340570.7945-100000@jehovah.technokratis.com>, 
Bosko Milekic writes:

>	#define M_RDONLY	0x0x2000
>
>2)	The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is
>  equal to or greater than 2. This is unfortunate because an additional
>  check would have to be introduced. <INPUT ALTERNATIVE HERE>
>
>3)  	The flag should be removed in _MEXTFREE only if that first
>  MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(),
>  the new ref_cnt is exactly 1.
>
>	I'm pretty sure that this way, the subsystem will take care of the
>  read-onlyness itself pretty transparently, so that relevant code can
>  simply check for the M_RDONLY bit. (2) is questionable.

This is good, but the M_RDONLY flag should only be used as an
indication that the underlying ext_buf must never be written to.
Hence the mbuf system should never modify this flag (except of
course to clear it when the mbuf is returned to the free pool).

Point (3) above would clear the M_RDONLY flag on a sendfile sf_buf
when the reference count becomes 1; this is not the desired effect.

Another way of looking at the M_RDONLY flag is as an indication
that the underlying ext_buf does _not_ follow cluster semantics;
cluster semantics being defined as 'it is safe to write if the
reference count is exactly 1'.

However, the idea of caching the value of the expression:

	if (m->m_flags & M_EXT) != 0 &&
	    (MEXT_IS_REF(m) || (m->m_flags & M_RDONLY))) {
		/* data is read only */
	}

in a flag is nice, but if implemented, that would have to be a
separate flag to the above M_RDONLY.

Ian


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200008282046.aa01881>