[igt-dev] Scripting language for igt

[Joonas Lahtinen]

Quoting Rodrigo Vivi (2018-08-21 22:14:09)
> On Tue, Aug 21, 2018 at 02:43:21PM +0300, Joonas Lahtinen wrote:
> > Quoting Chris Wilson (2018-08-20 13:11:15)
> > 
> > <SNIP>
> > 
> > > In both cases it was easy to extend the test beyond the original. Joonas
> > > who is more familiar with the later declarative ECMAScript, says he can
> > > reduce the boilerplate code even further. (Some of the verbosity is on
> > > purpose, since these tests are negative tests and so want to need to dig
> > > beneath the usual layers of convenience api, but still the plan should
> > > be to autogenerate as much of the ioctl breaking as possible.)
> > > 
> > > TLDR; I want to rewrite BAT and use a script interpreter for speed of
> > > execution, ease of test writing, and for automating test generation. 
> > > I would like to drop duktape into igt/shell, but the initial code drop
> > > may be too big to post/review... So I would like to present it as fait
> > > accompli and then work on the smaller patches to make the magic happen.
> > 
> > We exchanged some further ideas about this, and my suggestions:
> > 
> > Use v8, for the sake of having a large user base (and the modern
> > language features) and JIT for speed.
> 
> On the engine side I have no idea what is the best one and honestly
> I liked the duktape that Chris found. Seems easy and straighforward...

It is, until you start actually using the new language features. It's really
either v8 or SpiderMonkey, I don't consider other implementations mature.

> > 
> > The igt shell code only really needs to expose IOCTLs and then maybe
> > some debugfs derived values. This helps in having a very clearly defined
> > interface for the tests to the system (you simply can't poke unintended
> > holes through the meant interface, as you are writing all the testing
> > code inside the interpreter). On top of which we can add abstractions on
> > the ECMAScript files themselves for things like spin batches etc.
> 
> Well, I agree that we need a clear separation of what is standard uapi
> from what are helpers and abstraction on top of that, but I don't believe
> that we necessarily need to do this on top of the engine itself.
> 
> Well, I'm not sure how exactly to do this differentiation, maybe function
> names standards?
> 
> Anyway I'd like to state that specially on display I'd like to see many helpers.
> 

All these helpers will be written as abstractions (with javascript), the
idea is that the calls from outside the shell are just really IOCTls,
and can be used to for example build apitrace style traces (in this
case, of IOCTLs) that can be compiled into .c file. So we effectively
use javascript as a meta language for describing the tests.

> The end goal on display side should be simple calls that give planes
> with certain colors on certain position/rotation already committed on
> screen, without developer/validator needing to create a framebuffer,
> promote to a plane, do a commit, etc.

Yes, this is exactly the purpose :)

Regards, Joonas

> 
> Thanks a lot for starting this prospection Chris!
> 
> Thanks,
> Rodrigo.
> 
> > 
> > Regards, Joonas
> > _______________________________________________
> > igt-dev mailing list
> > igt-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev