Justin,
> On Wed, May 17, 2006 at 12:25:18AM +0200, Michael Kerrisk wrote:
> > Justin,
> >
> > > On Mon, May 15, 2006 at 10:06:29PM +0200, Michael Kerrisk wrote:
> > > > > > > changes:
> > > > > > > make mmap.2 reference mincore
> > > > > >
> > > > > > Done, for 2.33.
> > > > > >
> > > > > > > explicitly state that a read-only MAP_PRIVATE is equivalent
> > > > > > > to MAP_SHARED
> > > > > >
> > > > > > *why?* You do not explain what benefit this serves.
> > > > > Because, upon reflection, it isn't immediately clear from the
> > > > > wording of the page as it exists now. In particular:
> > > > >
> > > > > Create a private copy-on-write mapping
> > > >
> > > > Umm -- we were talking about read-only mappings?
> > > Yes; I wish to make it clear that, for a read-only map, the behaviour
> > > is the same.
> > >
> > > > > This could be interpretted as meaning "create a new mapping, even
> > > > > if the file is already mapped", which isn't what people usually >
> > > > want, and isn't what it does anyway..
> > > > >
> > > > > > > An alternative would be to take the commented-out Linus quote
> > > > > > > embedded
> > > > > > > in mmap.2 which says precisely what I want and create a NOTES
> > > > > > > section out of it.
> > > >
> > > > Let me put things another way: why should a programmer care
> > > > about whether read-only mappings are done the same way
> > > > internally for both MAP_SHARED and MAP_PRIVATE?
> > > A programmer should care whether using MAP_PRIVATE uses extra
> > > resources than a MAP_SHARED (both maps presumably have some
> > > overhead, for the initial mapping and for each additional mapping). >
> > I
> > > question whether this is presently as clear as it should be.
> >
> > But:
> >
> > -- you have not demonstrated that there is any significant
> > difference?
> Do you mean differences between MAP_{PRIVATE,SHARED}? It is my
> understanding that there is no (behavioural) difference for the case
> of a read-only mapping. But I want this to be more obvious.
You supply absolutely no good reason for doing so.
The fact that things currently happen to be done a certain
way does not mean that it won't change in the future
or be different on other systems. Therefore, don't
document it, unless there is a compelling reason to do
so -- otherwise it is simply misleading information.
<alert>
You persist in arguing this point, but so far, I have
seen no evidence that you have a deep understanding
of mmap(), or what the performance issues are.
You are wasting my time with too many bogus
bug reports, and I am beginning to get rather
irritated by it. Each time you submit a
false or poorly researched bug report means time taken
away from other work that I do on man-pages. Of course,
there is another choice: I can ignore your reports.
I don't want to do that -- most of your reports are
useful. But I do not want to waste time sorting
out the good from the bad. I want you to do it.
</alert>
> > -- whether there is a difference on other Unix systems
> > (if they show different perfomance characteristics,
> > then the man-pages should not make recommendations).
> I haven't a clue; but I'm surprised that you think it shouldn't make a
> recommendation, instead of documenting the differences.
Well, *if* the differnt implementations happen to show different
performance results, then it would be misleading simply
to recomment the route to give best performance on Linux.
Bad for portability...
Enough.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
ftp://ftp.win.tue.nl/pub/linux-local/manpages/,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
