Re: [igt-dev] Scripting language for igt

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Aug 23, 2018 at 01:09:28PM -0700, Paulo Zanoni wrote:
> 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.

Indeed. There are 2 different things here.

> 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.

I fully agree. We should be doing igt display lib in C already to make
the operations easy enough even in C native igt tests.

> 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.

Yep. IGT shell on top would be good for experiments and quickly checks
and validators don't needing to touch the C code themselves.

But it is good that we are at least already touching one of the issues
somehow.

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