While drivers/xen/Kconfig has been changed to allow blktap to be a module, its Makefile doesn''t and, if fixed, it needs a symbol not currently exported (zap_page_range). I thought I saw discussion of this on the list, but wasn''t able to find it in the archives. So - does anyone care to fix this (i.e. replace the calls to zap_page_range() by exported functionality) or should I just post a patch fixing the Makefile and exporting zap_page_range? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/10/06 10:48, "Jan Beulich" <jbeulich@novell.com> wrote:> While drivers/xen/Kconfig has been changed to allow blktap to be a module, > its Makefile doesn''t and, if fixed, it needs a symbol not currently exported > (zap_page_range). I thought I saw discussion of this on the list, but wasn''t > able to find it in the archives. So - does anyone care to fix this (i.e. > replace > the calls to zap_page_range() by exported functionality) or should I just > post a patch fixing the Makefile and exporting zap_page_range?The uses of zap_page_range look dubious to me. 1. The one in blktap_release() - why? Standard semantics is for mmap regions to exist beyond the closing of the mapping device. Doesn''t make much sense to do that here, but then again not really any need to explicitly disallow it (and add extra code to enforce). 2. Blktap_mmap() -- the mm subsystem will zap the range anyway on failure. No need to do it in the driver. 3. The loop unmaps the pages the proper way (unmap_grant). The zap_page_range() here is entirely unnecessary afaics. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi,> 1. The one in blktap_release() - why? Standard semantics is for mmap > regions to exist beyond the closing of the mapping device. Doesn''t make much > sense to do that here, but then again not really any need to explicitly > disallow it (and add extra code to enforce).The linux kernel does call the drivers release() method when the last reference is gone. If you call close() with mappings still being active, then ->release() is _not_ called when you close the file handle but when the last mapping is unmapped. Thus there is no point in trying to handle active mappings there ;) cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 16/10/06 12:45, "Gerd Hoffmann" <kraxel@suse.de> wrote:>> 1. The one in blktap_release() - why? Standard semantics is for mmap >> regions to exist beyond the closing of the mapping device. Doesn''t make much >> sense to do that here, but then again not really any need to explicitly >> disallow it (and add extra code to enforce). > > The linux kernel does call the drivers release() method when the last > reference is gone. If you call close() with mappings still being > active, then ->release() is _not_ called when you close the file handle > but when the last mapping is unmapped. Thus there is no point in trying > to handle active mappings there ;)I.e., they''ll have been unmapped already? As you say, either way the zap is not needed... -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> > > On 16/10/06 12:45, "Gerd Hoffmann" <kraxel@suse.de> wrote: > >> The linux kernel does call the drivers release() method when the last >> reference is gone. If you call close() with mappings still being >> active, then ->release() is _not_ called when you close the file handle >> but when the last mapping is unmapped. Thus there is no point in trying >> to handle active mappings there ;) > > I.e., they''ll have been unmapped already?Yes.> As you say, either way the zap is > not needed...Yep, I just wanted to fill in some more background info ... cheers, Gerd -- Gerd Hoffmann <kraxel@suse.de> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel