772 replies to this topic

[betacentauri]

It’s a little bit too fast.

First is smallflash, middleflash really needed? Does a team want to use it? I have no idea for what? If someone needs it, can we make it optional? And what would optional mean here? Proc nodes doesn’t have to be there or can it return nothing?

Second but much more important. We need to write down a few things. Why? Because with the current informations it’s impossible to write an implementation for e.g. OpenPLi.
smallflash seems to return True/False. But there is no definition when to return what. multitranscoding I don’t know what that means? Does it mean that the box can transcode more than one stream? And so on....
Only possible way to find that out at the moment, would be to read your implementation.

We should make a short list with all proc nodes, their possible return values and a short description what should be returned.

And one other thing we should think about is versioning. At least add a api-version (or similar) field.

Edited by betacentauri, 17 December 2020 - 19:46.

[WanWizard]

I'm not a fan of optional data, that will lead to (compatibility) issues, sooner or later.

 

I think a part of the work of the governmance group will be to properly spec a proc node, and that can/may/should include an example of how to obtain the value (if relevant).

 

It should be taken up as if you were documenting functions or class methods, exactly describing its function, and its return value.

 

Proc nodes like "smallflash" and "middleflash: should be avoided. They are subjective, and don't really serve a purpose.

 

If flash size is relevant, the node should indicate its size, and return a value in MB (for example). Wether some value is deemed small or large depends on its use, and is therefore a task of the client code, not of the module.

[Persian Prince]

As I said before some proc nodes are for us.

 

We define them with if conditions or a different branch so the code won't compile for you, I don't understand why you worried about our proc nodes.

[WanWizard]

I'm not worried about image specific things, as long as they stay our of the spec.

[betacentauri]

Because I don’t know which proc nodes are “your” image specific nodes.
I wanted to do some other things tomorrow, but I try to start writing a small text file with name of the proc file, description and return values (with examples).

[Huevos]

Yes, but branding is going to disappear, that is the idea of this entire excersize.

LOL, branding is not going to disappear. Branding is a lot more than the ".so". That is just one part.

[betacentauri]

This is only an example!

While writing this we should think about the proc names. Current OE-A branding e.g. use getHaveCI. Persian Prince use ci. We can remove the get, but maybe hasCi is more readable...

This describes API version 1

Proc nodes will be created in /proc/<to de defined>.

Proc nodes

- apiversion
  Returns the API version number which is used for creating the proc nodes.
  Return value: 1  (fix value)

- model
  Returns the model
  Return value: String max 100 characters
  Example: h9s

- driverdate
  Returns the date when the drivers were made.
  Return value: String in the format YYYYMMDD
  Example: 20201201 for the first of December 2020.

- ci
  Returns whether a CI is available
  Return value: True/False

....

[WanWizard]

LOL, branding is not going to disappear. Branding is a lot more than the ".so". That is just one part.

 

So we'll still be stuck with plugins requiring the OE-A specific branding module? Then we should stop now.
 

[littlesat]

So we'll still be stuck with plugins requiring the OE-A specific branding module? Then we should stop now.

+1.... our 'fake' boxbranding module may work-a-round it in that case...

[WanWizard]

I don't care what another image builder does in their image.

 

I do care that they create or keep something that kills all hope of more compatibility between images.

[littlesat]

Omg

Edited by littlesat, 18 December 2020 - 18:46.

[Persian Prince]

I'm not worried about image specific things, as long as they stay our of the spec.

 

Yep I'll take care of that as we have lots of specific nodes, example of using the module: https://github.com/O...3b11124b6db0b8f

 

I just removed the bootlogo package from OV permanently as we have bootvideo (mp4) on our feeds too: https://github.com/O...go/bootlogo.mp4

 

Because I don’t know which proc nodes are “your” image specific nodes.
I wanted to do some other things tomorrow, but I try to start writing a small text file with name of the proc file, description and return values (with examples).

 

It's ok, general and familiar nodes are global and the rest is for Open Vision.

 

This is only an example!

While writing this we should think about the proc names. Current OE-A branding e.g. use getHaveCI. Persian Prince use ci. We can remove the get, but maybe hasCi is more readable...
 

This describes API version 1

Proc nodes will be created in /proc/<to de defined>.

Proc nodes

- apiversion
  Returns the API version number which is used for creating the proc nodes.
  Return value: 1  (fix value)

- model
  Returns the model
  Return value: String max 100 characters
  Example: h9s

- driverdate
  Returns the date when the drivers were made.
  Return value: String in the format YYYYMMDD
  Example: 20201201 for the first of December 2020.

- ci
  Returns whether a CI is available
  Return value: True/False

....

That could be good to start hardware features with "has" but please never use mixed case and just use everything in lowercase.

 

If you take a look at the results only True/False are mixed (as the output of bitbake) and that could be converted in lowercase too.

 

Why driver date is needed? Do we use it for something?

[betacentauri]

Driver date is shown in About -> Info in several images.

I think mixed case is easier to read especially when it is a concatenation of 2 words like hasCi. But it’s only my opinion and I don’t care very much.

@Huevos: Which other parts are included?
I think the remote and box pictures and the rc_model.py. Right? More?

[Huevos]

Yes it has the image libraries and the RC stuff.

[Huevos]

I don't care what another image builder does in their image.

 

I do care that they create or keep something that kills all hope of more compatibility between images.

LOL. So I a have a PHP server running on my PC. And now I have loaded Python... Does that mean I have to uninstall PHP?

 

TBH, I really don't think you guys have had your hearts in this from the get go.

[WanWizard]

I don't see any reason to laugh. On the contrary.

 

We're very busy here trying to get a common base for all images, and you seem to find it normal to say "whatever, we'll still keep our branding in OE-A"? Which means all plugins using OE-A branding still won't work on non-OE-A images?

 

And then have the bloody nerve to lay the blame of this not moving forward on the doorstep of others?

[Huevos]

So whose job do you think it is to convert all those plugins?

[WanWizard]

I didn't write "now" or "immediate" or "day 1".

 

But there has to be a migration path, because if that doesn't happen, it removes the entire point behind this excersize.

 

There will probably be a few plugin writers who will be intrested in a broader user base or in no longer having to maintain multiple versions (take for example OWIF), and others will probably not bother, and those will remain to be catered for by OE-A who will keep the old interface maintained.

 

We as teams will also have a lot of work, dealing with the changes in E2 and the plugins maintained by the team.

 

For OpenPLi that probably means as a first step we will change the current environment (SystemInfo et al) to use the module, and then bit by bit change the rest of the code.

[Huevos]

For us the main benefit would be being able to access these values from c++ and scripts. Not much more.

 

As far as the plugins go, biggest problem for us is the PLi Setup code needs updating, not branding.

[IanSav]

Hello Huevos,

 

As far as the plugins go, biggest problem for us is the PLi Setup code needs updating, not branding.

 

That process is well in hand.  My latest generation of Setup based code is being reworked and tested on OpenVision at the moment.  It will be using these new /proc values and is being specifically designed to also go straight into OpenPLi as well as OpenVision.  Other images will be free to take the latest updates.

 

Regards,

Ian.