[CRIU] Re: [PATCH] restore: Order file restoring by their type

[Cyrill Gorcunov]

On Sat, Apr 28, 2012 at 06:08:01PM +0400, Pavel Emelyanov wrote:
> > Why? I think restoration driven by enum order is better.
> 
> Why?

Because if you need to change something you'll simply
change the enum only, otherwise you need to walk over
the code and see where is particular function is called.
I find it inconvenient, but I won't insist.

> > If I do what you propose -- I'll have to add tests for
> > file not being eventpoll to restore them afetr all other
> > files. 
> 
> Exactly! And this will be self-documenting why this order matters
> at all. But just splitting the restore per-type makes code readers
> wonder why and (!) be surprised why the new fdinfo type added by them
> _after_ the eventpoll doesn't work well...

If order is not important for some fdinfo type, it doesn't matter
then where you place particular enum value, it's that simple.
In turn if order is important, you need to choose position
carefully (which reveals the fact that I forgot to add comment
in enum).

Anyway, I'll not insist and will add explicit test.

> > Moreover I need the same for inotify. Which will
> > make code uglier.
> 
> No, for inotify you don't need this. You bind inotifies to inodes,
> not to fd-s.

yeah, files get referred by file handle.

	Cyrill