On Fri, 29 Dec 2017, Matthew Wilcox wrote: > Is this the right approach? I could imagine there being more ops in > the future. I suspect we should bite the bullet now and do: > > struct kmem_cache_operations { > void (*ctor)(void *); > void *(*isolate)(struct kmem_cache *, void **objs, int nr); > void (*migrate)(struct kmem_cache *, void **objs, int nr, int node, > void *private); > }; Well yes but that would mean converting the existing call sites. > Not sure how best to convert the existing constructor users to this scheme. > Perhaps cheat ... One of the prior releases of slab defragmentation did this. We could do it at some point. For now the approach avoids changing the API. > > @@ -4969,6 +4987,20 @@ static ssize_t ops_show(struct kmem_cach > > > > if (s->ctor) > > x += sprintf(buf + x, "ctor : %pS\n", s->ctor); > > + > > + if (s->isolate) { > > + x += sprintf(buf + x, "isolate : "); > > + x += sprint_symbol(buf + x, > > + (unsigned long)s->isolate); > > + x += sprintf(buf + x, "\n"); > > + } > > Here you could print the symbol of the ops vector instead of the function > pointer ... Well yes if we had it and thne we could avoid printing individual fields. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>