> From: Minchan Kim [mailto:minchan@xxxxxxxxxx] > > Okay. Now it works but zcache coupled with zsmalloc tightly. > User of zsmalloc should never know internal of zs_handle. > > 3) > > - zsmalloc.h > void *zs_handle_to_ptr(struct zs_handle handle) > { > return handle.hanle; > } > > static struct zv_hdr *zv_create(..) > { > struct zs_handle handle; > .. > handle = zs_malloc(pool, size); > .. > return zs_handle_to_ptr(handle); > } > > Why should zsmalloc support such interface? > It's a zcache problem so it's desriable to solve it in zcache internal. > And in future, if we can add/remove zs_handle's fields, we can't make > sure such API. Hi Minchan -- I'm confused so maybe I am misunderstanding or you can explain further. It seems like you are trying to redesign zsmalloc so that it can be a pure abstraction in a library. While I understand and value abstractions in software designs, the primary use now of zsmalloc is in zcache. If there are other users that require a different interface or a more precise abstract API, zsmalloc could then evolve to meet the needs of multiple users. But I think zcache is going to need more access to the internals of its allocator, not less. Zsmalloc is currently missing some important functionality that (I believe) will be necessary to turn zcache into an enterprise-ready, always-on kernel feature. If it evolves to add that functionality, then it may no longer be able to provide generic abstract access... in which case generic zsmalloc may then have zero users in the kernel. So I'd suggest we hold off on trying to make zsmalloc "pretty" until we better understand how it will be used by zcache (and ramster) and, if there are any, any future users. That's just my opinion... Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href