building blktap as a module

building blktap as a module

[Jan Beulich]

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

Re: building blktap as a module

[Keir Fraser]

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

Re: building blktap as a module

[Gerd Hoffmann]

  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

Re: building blktap as a module

[Keir Fraser]

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

Re: building blktap as a module

[Gerd Hoffmann]

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