[Devel] Re: [PATCH 04/11] checkpoint: introduce device vma type

[Nathan Lynch]

On Mon, 2011-01-10 at 21:29 -0500, Oren Laadan wrote:
> Hi,
> 
> Thanks for bringing up the issue.
> 
> We clearly will need device-specific vma types (in plural!),
> and I suspect that the way it will work is that devices will
> register their vma types at boot time or dynamically (for
> kernel modules).
> 
> On 10/20/2010 02:56 PM, Nathan Lynch wrote:
> > This is intended to be used by drivers that allow userspace to map
> > hardware resources via mmap(2).  The mapping is restored but we don't
> > worry about the contents.  This is pretty much how we treat shared
> > file mappings, where it is the user's responsibility to ensure file
> > (device) availability and integrity for restart.  I think this is a
> > reasonable approach for the timer implementations in drivers/char as
> > well as the bsr driver (for which a patch follows).
> 
> The given use case is for a specific device, and assumes special
> userspace behavior and awareness (if not the application, at 
> least the admin that runs the c/r).
> 
> A similar solution will also apply for memory regions marked by
> the process as "scratch" - a way for programmers to tell the kernel
> that certain memory need not be saved/restored beyond the mapping.
> 
> I'm a bit concerned about tying this behavior permanently to a
> drivers. (Although, it may make sense for some drivers). What do
> you think ?
> 
> Otherwise, the patch looks correct. Perhaps modify the types to
> something more generic, like CKPT_VMA_VANILLA ?

My use case has disappeared in the interim and I've moved on to other
matters, so I'm inclined to defer c/r of device mappings until another
user comes along.


_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers