Bug 21362

Summary:	Adds M_RDONLY to external storage mbufs
Product:	Base System	Reporter:	Bosko Milekic <bmilekic>
Component:	kern	Assignee:	bmilekic
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	5.0-CURRENT
Hardware:	Any
OS:	Any

Description Bosko Milekic 2000-09-18 18:30:00 UTC

	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.

Fix: 

Not applicable.
How-To-Repeat: 
	Not applicable.

Comment 1 dwmalone freebsd_committer

2000-09-19 08:10:30 UTC

Responsible Changed
From-To: freebsd-bugs->dwmalone

I'll look at this one.

Comment 2 dwmalone 2000-09-19 08:18:37 UTC

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.

Comment 3 Archie Cobbs 2000-09-19 18:16:11 UTC

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

Comment 4 bmilekic@dsuper.net 2000-09-19 22:17:09 UTC

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

Comment 5 bmilekic freebsd_committer

2000-09-22 04:13:27 UTC

Responsible Changed
From-To: dwmalone->bmilekic

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)...

Comment 6 bmilekic freebsd_committer

2000-09-22 04:16:17 UTC

State Changed
From-To: open->suspended


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

Comment 7 bmilekic freebsd_committer

2000-11-18 02:58:04 UTC

State Changed
From-To: suspended->closed

Code has been committed... finally.