On 04/29/2010 08:14 PM, Andy Adamson wrote: > > On Apr 29, 2010, at 1:03 PM, Boaz Harrosh wrote: > >> On 04/29/2010 07:27 PM, Boaz Harrosh wrote: >>> On 04/29/2010 01:24 AM, andros@xxxxxxxxxx wrote: >>>> From: Andy Adamson <andros@xxxxxxxxxx> >>>> >>>> The layoutdriver_io_operations uninitialize_mountpoint function is >>>> used >>>> to free a layout driver specific device id cache. >>>> The device id cache is now shared and moved to struct nfs_client >>>> and can be >>>> removed in the generic unmount_pnfs_layoutdriver routine. >>>> >>>> Signed-off-by: Andy Adamson <andros@xxxxxxxxxx> >>> >>> What ? no. >>> >>> uninitialize_mountpoint is where the mountid private data is >>> deallocated. >>> The one that was allocated at initialize_mountpoint. >>> >>> Files layout might not currently have any, but we do and it will >>> has well. >>> Any way what kind of API has initialize call and not an >>> uninitialize call >>> Even if it's empty >>> >>> NACK >>> >> >> You are right that currently it's only device cache things. But I >> have code in >> Q that have a page pool cache for RAID5/6 IO, and other >> initialization I need. >> >> Please keep the initialize and a symmetric uninitialize and keep >> some private >> data for each sb. It does not cost any thing. You could get rid of >> the double >> indirection though. > > OK. I'll keep the uninitialize_mountpoint. A private data pointer will > be put back in the object layout driver submission. I will provide the > patches. > > -->Andy > >> >> Thanks >> Boaz > Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
