From bmilekic@jehovah.technokratis.com  Mon Sep 18 10:20:06 2000
Return-Path: <bmilekic@jehovah.technokratis.com>
Received: from jehovah.technokratis.com (modemcable136.203-201-24.mtl.mc.videotron.ca [24.201.203.136])
	by hub.freebsd.org (Postfix) with ESMTP id 245FA37B424
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Sep 2000 10:20:00 -0700 (PDT)
Received: (from bmilekic@localhost)
	by jehovah.technokratis.com (8.11.0/8.11.0) id e8IHNa618503;
	Mon, 18 Sep 2000 13:23:36 -0400 (EDT)
	(envelope-from bmilekic)
Message-Id: <200009181723.e8IHNa618503@jehovah.technokratis.com>
Date: Mon, 18 Sep 2000 13:23:36 -0400 (EDT)
From: Bosko Milekic <bmilekic@jehovah.technokratis.com>
Reply-To: bmilekic@technokratis.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: [PATCH] mbuf M_RDONLY flag: to be continued... 
X-Send-Pr-Version: 3.2

>Number:         21362
>Category:       kern
>Synopsis:       Adds M_RDONLY to external storage mbufs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bmilekic
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 18 10:30:00 PDT 2000
>Closed-Date:    Fri Nov 17 18:58:04 PST 2000
>Last-Modified:  Fri Nov 17 18:58:42 PST 2000
>Originator:     Bosko Milekic
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
N/A 
>Environment:

	FreeBSD 5.0-CURRENT

>Description:

	Here is a working pre-SMPng patch adding M_RDONLY flag and macro to
  mbufs that have an ext_buf attached. It is pre-SMPng and should probably
  just be left sitting here (with this PR) until we're finished threading
  this area of the code, and then merged, possibly modified, and committed,
  if deemed necessary. The diff can be found here:

	http://www.technokratis.com/code/mbuf/mbuf_rdonly.patch

	Idea for this is in part from dwmalone, in part to Ian Dowse. They
  should review/add to this before it's committed. Due to the SMPng delay,
  let it just sit for now.

	The M_RDONLY flag and the macro, by the way, allow for us to
  determine uniformally whether the external storage in question is
  safe to be tampered with/written to, or not. See code and list archives
  (-net, specifically) for details. 

>How-To-Repeat:

	Not applicable.

>Fix:

	Not applicable.


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Tue Sep 19 00:10:30 PDT 2000 
Responsible-Changed-Why:  
I'll look at this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21362 

From: David Malone <dwmalone@maths.tcd.ie>
To: bmilekic@technokratis.com
Cc: FreeBSD-gnats-submit@freebsd.org, iedowse@maths.tcd.ie,
	archie@freebsd.org
Subject: Re: kern/21362: [PATCH] mbuf M_RDONLY flag: to be continued...
Date: Tue, 19 Sep 2000 08:18:37 +0100

 On Mon, Sep 18, 2000 at 01:23:36PM -0400, Bosko Milekic wrote:
 
 > 	http://www.technokratis.com/code/mbuf/mbuf_rdonly.patch
 
 I've had two quick looks at the patch, and have one or two questions
 about it. I'll try to have a careful read later today.
 
 > 	Idea for this is in part from dwmalone, in part to Ian Dowse. They
 >   should review/add to this before it's committed. Due to the SMPng delay,
 >   let it just sit for now.
 
 Archie will probably want to look at this too - maybe he could
 review it too? Myself and Ian have some patches to sbcompress which
 could make use of this readonly stuff - though that should probably
 be a seperate commit.
 
 	David.
 

From: Archie Cobbs <archie@whistle.com>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: bmilekic@technokratis.com, FreeBSD-gnats-submit@freebsd.org,
	iedowse@maths.tcd.ie
Subject: Re: kern/21362: [PATCH] mbuf M_RDONLY flag: to be continued...
Date: Tue, 19 Sep 2000 10:16:11 -0700 (PDT)

 David Malone writes:
 > > 	http://www.technokratis.com/code/mbuf/mbuf_rdonly.patch
 > 
 > I've had two quick looks at the patch, and have one or two questions
 > about it. I'll try to have a careful read later today.
 > 
 > > 	Idea for this is in part from dwmalone, in part to Ian Dowse. They
 > >   should review/add to this before it's committed. Due to the SMPng delay,
 > >   let it just sit for now.
 > 
 > Archie will probably want to look at this too - maybe he could
 > review it too? Myself and Ian have some patches to sbcompress which
 > could make use of this readonly stuff - though that should probably
 > be a seperate commit.
 
 I would really like to see an mbuf(9) man page. Maybe this would
 be a good time to add one... I'm willing to help.
 
 In my experience writing a good, technical, and complete man page
 forces you to clarify exactly what is going on and often causes
 you to think of bug-potential cases that you hadn't before. Or,
 if you've already thought of everything, then writing the man
 page should be very easy :-)
 
 -Archie
 
 ___________________________________________________________________________
 Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com
 

From: Bosko Milekic <bmilekic@dsuper.net>
To: Archie Cobbs <archie@whistle.com>
Cc: David Malone <dwmalone@maths.tcd.ie>,
	FreeBSD-gnats-submit@freebsd.org, iedowse@maths.tcd.ie
Subject: Re: kern/21362: [PATCH] mbuf M_RDONLY flag: to be continued...
Date: Tue, 19 Sep 2000 17:17:09 -0400 (EDT)

 On Tue, 19 Sep 2000, Archie Cobbs wrote:
 
 > I would really like to see an mbuf(9) man page. Maybe this would
 > be a good time to add one... I'm willing to help.
 > 
 > In my experience writing a good, technical, and complete man page
 > forces you to clarify exactly what is going on and often causes
 > you to think of bug-potential cases that you hadn't before. Or,
 > if you've already thought of everything, then writing the man
 > page should be very easy :-)
 
 	Yes, I was also thinking about the man page. We should probably wait
   it out a bit, though. Along with the SMP changes, I'm slightly modifying
   certain things, so we should wait until that's done and committed before
   anything, really. Otherwise, we will be duplicating the workload. We
   should also eventually split out cluster allocation to a more appropriate
   layer (parallel to other external buffer layers). We may also find it
   interesting to investigate collapsing sendfile(2) sf_bufs allocations as
   well as 1/2 page cluster allocations to one single zone allocator. We
   should investigate following the SMP stuff.
 	If you want to begin on documenting, go right ahead. I'm prepared to
   support you with it immediately, but just be sure to leave space for easy
   expandability/additions.
 
 > -Archie
 > 
 > ___________________________________________________________________________
 > Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com
 
   Cheers,
 
   Bosko Milekic
   bmilekic@technokratis.com
 
 
 
Responsible-Changed-From-To: dwmalone->bmilekic  
Responsible-Changed-By: bmilekic 
Responsible-Changed-When: Thu Sep 21 20:13:27 PDT 2000 
Responsible-Changed-Why:  
I'll take care of this for now... dwmalone is busy at this instant, but we 
do expect to see related commits come in from his end as well... (dwmalone 
mentionned making some mods to related code)... 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21362 
State-Changed-From-To: open->suspended  
State-Changed-By: bmilekic 
State-Changed-When: Thu Sep 21 20:16:17 PDT 2000 
State-Changed-Why:  

Suspending until we're done with related SMPng modifications. Will be 
merged and reviewed thereafter. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=21362 
State-Changed-From-To: suspended->closed  
State-Changed-By: bmilekic 
State-Changed-When: Fri Nov 17 18:58:04 PST 2000 
State-Changed-Why:  
Code has been committed... finally. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=21362 
>Unformatted:
