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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
