Subject: Re: Further mbuf adventures
To: Jason Thorpe <thorpej@wasabisystems.com>
From: Darren Reed <avalon@caligula.anu.edu.au>
List: tech-net
Date: 05/02/2004 15:24:06
In some mail from Jason Thorpe, sie said:
> On May 1, 2004, at 4:44 PM, Darren Reed wrote:
> 
> > Now, I have another problem...M_ROMAP & M_READONLY.  M_ROMAP appears:
> >
> > /usr/src/sys/kern/uipc_socket.c
> > /usr/src/sys/arch/arm/arm32/bus_dma.c
> > /usr/src/sys/sys/mbuf.h
> > /usr/src/sys/nfs/nfs_vnops.c
> > /usr/src/sys/nfs/nfs_serv.c
> > /usr/src/sys/nfs/nfs_subs.c
> >
> > ...and so one might surmise that its purpose is to mark external mbuf
> > data as being mapped read-only.  I'm curious as to why only arm32's
> > bus_dma consider's this significant.
> 
> The purpose is to mark that the mbuf data is mapped read-only at the 
> MMU level.  This is not quite the same as an mbuf that must not be 
> modified, which does not reflect MMU state... it is possible for an 
> mbuf to be M_READONLY and *not* M_ROMAP.

Yes, this much I gathered and had a vague grasp of the rest of what
your email said.  I suppose the question I was really asking, and I
don't think you answered is, can an mbuf be M_ROMAP and not M_READONLY ?

Darren