[igt-dev] [PATCH v24 02/14] lib/i915: add gem_engine_topology library and for_each loop definition
Andi Shyti
andi.shyti at intel.com
Wed May 22 11:39:31 UTC 2019
> > + p->size = (p->size - sizeof(struct i915_context_param_engines)) /
> > + (offsetof(struct i915_context_param_engines,
> > + engines[1]) -
> > + sizeof(struct i915_context_param_engines));
>
> So param.size starts with number of bytes, but then becomes number of
> engines? It's a bit evil and non-obvious, because a line below confused me:
this was a review from Chris and later on I use indeed size as
engine count.
I understand it's a bit unclear given that in the kernel it has a
slightly different meaning.
> > + igt_assert_f(p->size <= GEM_MAX_ENGINES, "unsupported engine count\n");
[...]
> > + if (!param.size) {
> > + query_engine_list(fd, &engine_data);
> > + ctx_map_engines(fd, &engine_data, ¶m);
> > + } else {
> > + for (i = 0; i < param.size; i++)
>
> This one. It is an apparent mismatch between indices and bytes.
>
> Put a comment with this block saying in what case we get here and the trick
> with param.size you play.
I will add a few comments to make it more clear.
> > +int gem_context_lookup_engine(int fd, uint64_t engine, uint32_t ctx_id,
> > + struct intel_execution_engine2 *e)
> > +{
> > + DEFINE_CONTEXT_PARAM(engines, param, ctx_id, GEM_MAX_ENGINES);
> > +
> > + if (!e || gem_topology_get_param(fd, ¶m) || !param.size)
> You expect a NULL e here and to what purpose?
just to be a bit paranoic, besides I wouldn't like a segfault in
my function :)
> Best to just disallow it I think.
isn't 'return -EINVAL' enough? igt_assert?
> Also param.size == 0? It can't be possible due how you define the structure
> a line above it.
yes, but before I call 'gem_topology_get_param()' where size
might get overridden.
[...]
> And please put a follow up to add API docs on your TODO list shortly after
> we merge this.
OK.
Andi
More information about the igt-dev
mailing list