[tbot] [Discussion] Calling tbot from within the source directory

Wed Dec 5 09:05:48 UTC 2018

Hi Harald,

while Stefano and Wolfgang covered most points I would make as well
already. I do have my own spin on a couple of your statements.

Quoting Harald Seiler (2018-12-03 17:48:06)
> Hi Stefano,
> [disclaimer: long!]
> 
> On Mon, 2018-12-03 at 12:39 +0100, Stefano Babic wrote:
> > Hi Harald,
> > 
> > thanks for your clarifications:
> > 
> > On 03/12/18 10:27, Harald Seiler wrote:
> > > Hello Claudius,
> [...]
> > > > My problem here I think is that lab-specific configuration, user specific
> > > > configuration and project specific configuration are sort of orthogonal and
> > > > all of them come together at the command line of tbot.
> > > 
> > > Don't get me wrong, I can also see this issue.  But as you mentioned before,
> > > bloating the commandline isn't really a nice solution ...
> > 
> > I agree that this should not be done extending the command line - and
> > board, lab, project *are* configuration file.
> > 
> > But as Claudius says they are orthogonal - that means they should not
> > have any dependencies. I am unsure which is the best way to derive from
> > base class.
> 
> Hmm, I am not so sure about that.  There is quite a complicated net of
> dependencies between the different "configs", which is why this question
> is so difficult.  If they were completely orthogonal, we wouldn't be
> talking about this ...

Orthogonal doesn't mean they don't have some points were they touch. You
have to think about of each to figure out where they have a different
perspective of some problems.

> 
> Examples:
> - Power is both lab AND board dependent.  You can't put it just into one
>   of the two, because it is different for each combination.

As Wolfgang and Stefano already mentioned, power control and the
schemata in which the boards are connected should come from the lab. The
Board instance just fills in its identifier.

The problem I see here that its difficult to talk about these things,
because we mix board-classes and board configuration or instances of those
classes. A board instance has an identifier associated in the lab
context. The board class itself does not, since it doesn't care about
the lab in particular at all, just about its common interface.
The identifier should be part of a lab instance like:

    map(board-id, board-instance).

So as I understand it they are orthogonal conceptionally in OOD. How it
is implemented in tbot is another issue.

> - Toolchains are definitely lab-specific, but a board requires the
>   right toolchain to be available.

The board class describes which architecture it supports, and the lab
instance map architectures to toolchain directories. So IMO they are
orthogonal here as well.

> Now, this will "break down" in the following scenario:  You have done your work
> and want to give a customer your tbot config so he can use it as well.  The
> customer doesn't have access to pollux, they have their own lab.  Now I'd say
> this means the customer needs to write their own lab-config, not dependent on
> pollux but their own stuff.  To make tbot notice if they forget something, we
> can make use of pythons multiple-inheritance:
> 
> We define an abstract base class for our project lab that requires all custom
> lab-host definitions we have as well:
> 
>         #lab_base.py
>         class BaseMyProjectLab(linux.LabHost):
>             @abc.abstractmethod
>             def tftp_folder(self, board: str) -> linux.Path:
>                 ...
> 
> Now we make this another base in our "pollux-project" config:
>         class MyProjectLab(pollux.PolluxLab, lab_base.BaseMyProjectLab):
>             ...
> 
> This would enforce a correct lab-config ... As a diagram:
> 
>         [project lab base class]
>                 A
>                 |
>         [pollux project lab] <- [possibly a developer specific lab config]
>                 |
>                 V
>         [pollux generic lab]
> 
> The paradigm here is to keep base classes generic and specialize them in each
> level ...
> 
> Although ... This is quite a complex case.  We should wait and see how often
> these situations actually arise before deciding on a best practice.

I think this might be quite common though if tbot wants to be a tool
where multiple people can work together to automate testing. IMO having to
jump through that many hoops might a bit to much in the use-case.

> > and this does not scale well because everyone has its own lab that must
> > be imported. I do not know if this is the only case, but the "poweron"
> > and "poweroff" methods are bound to the board - should they not be bound
> > to the lab ?
> 
> Hmm, good point ... Well, I'd argue "poweron" is sort of difficult, because
> it depends on both the board and the lab.  Making it a lab-only thing is bad,
> because you now need to edit your lab-config when adding a new board.  Making
> it only board-dependent is also not good, because in different labs, toggling
> power looks very different ... See my above approach for a suggestion on how
> to solve this ...
> 
> My issue with just making it a lab-function is the following:  Not everyone has
> a setup as tidy as ours, where every board is powered on and off in the same way.
> 
> By making poweron a lab thing, we would make this sort of setup mandatory.

Lets say we have a lab where each board has a custom command that needs
to be executed. Then it should still be decided by the lab (which hosts
all of those board) how each board instance should be switched. If you
put this information into a board class, then how do you handle multiple
identical boards in one lab?`

With OOD the lab would instanciate each board and could give them
parameters, which then can be used in board.poweron() functions etc. if
those are needed (callback into lab etc. would be preferable IMO)

> One more thing:  I think we are seeing a few different use-cases for tbot here.

You now are anwsering the question you raised before. It is quite
possible that I and maybe Stefano have a different use-case in mind that
tbot currently doesn't cover as well we would have liked.

> 
> On the one hand the way I use tbot right now:  To support me while hacking on some
> customer issue.  In this "mode", tbot just supports me by automating eg compile+flash+run_test.
> The config and testcases I create during working like this are all "throw-away" code, I don't
> intend it to be pretty or used later on for anything else.  A lot of it is copy pasted between
> different projects for the quickest way to solving whatever the issue is.  I really hack
> into tbot to get solutions quick and dirty.  I try, however, to find acceptable solutions
> that don't require internal knowledge of tbot and if I can't, I will come up with upstream
> solutions ...

For me the quickest solutions would be not having to write any code and
just use what is already there ;)
<irony> Not needing to write any code anymore would be my very modest use-case
and this coincidentally also my plan for pension. </irony>

Hacking code and then throwing it away, just to hack some more code,
doesn't seem so quick as just writing once and using it henceforth.

And I always feel stupid when having to copy-paste stuff around and
while I do tend to look stupid quite often, I do my best to avoid it :)

kind regards,
Claudius

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.denx.de/pipermail/tbot/attachments/20181205/42d642b2/attachment.sig>