Re: [uml-devel] Re: [RFC] [patch 0/18] remap_file_pages protection support (for UML), try 3

[Blaisorblade]

On Wednesday 07 September 2005 14:00, Hugh Dickins wrote:
> On Sun, 4 Sep 2005, Blaisorblade wrote:
> > On Friday 02 September 2005 23:02, Hugh Dickins wrote:
> > > On Fri, 26 Aug 2005, Blaisorblade wrote:
> > > > * The first 2 patches modify the PTE encoding macros and start
> > > > preparing the VM for the new situation (i.e. VMA which have variable
> > > > protections, which are called VM_NONUNIFORM. I dropped the early
> > > > VM_MANYPROTS name).

> If it's something pervasive, like such naming, then yes you should redo
> the patches.  Minor local corrections can be appended as an additional
> patch, so long as they don't make the original patch ridiculous.
>
> I don't understand your "(at least when not changing behaviour)":
> if you mean that significant changes of behaviour should be done as extra
> patches at the end, no: surely they should be patches of the main sequence.
Perfectly fine.
> All of this supposes that my opinion is to be followed.
> I've given my opinions, Andi gave his, I don't remember others.
> It doesn't mean any one of us is right.  Did you agree with mine?
For me it's no problem renaming, I see your point, have no particular reason 
to insist with mine.

> > > "Inherit" is about parents and children, this is not;
[...]

> > MAP_CHGPROT? MAP_CHANGEPROT? MAP_REPROT?
> > VM_MANYPROTS is internal name, so there's no reason to have the same name
> > either.

> It doesn't have to be the same name, true, but I find it a lot easier
> to follow the trail of functionality when similar naming is used.
> Perhaps the "PROT" part is enough: MAP_SETPROT or MAP_CHGPROT or
> MAP_CHANGEPROT if you don't like MAP_MANYPROTS.
MAP_CHGPROT is perfectly ok...
> > It's just what you remarked above. But we'd have separate macros and code
> > paths (not hugely separate): use the old macro version if VM_MANYPROTS
> > clear, use the new one if VM_MANYPROTS set.

> I think those macros are grotesque enough already.
That change wouldn't be in the macro themselves. We'd have a slightly 
different path in the caller to handle that.
> But I don't have a constructive suggestion.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/