[igt-dev] Scripting language for igt

[Paulo Zanoni]

Em Qua, 2018-08-22 às 15:17 +0300, Joonas Lahtinen escreveu:
> 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.

That is something we can also try to achieve with C in parallel. IMHO
having a sane set of display abstractions/tools is mostly orthogonal to
the language, since the hard decisions are on how the interface should
look like, and we'll have this problem regardless of language. Of
course, an easier language could probably be an extra improvement on
top of that, but the main problem you're complaining about is IMHO
independent of JS vs C.

> 
> 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
> 
> _______________________________________________
> igt-dev mailing list
> igt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev