772 replies to this topic

[Huevos]

And BTW, this is not about slots. The image being tested should not need to be in a slot.

Edited by Huevos, 6 December 2020 - 23:12.

[WanWizard]

Do you now understand why I gave up and why I didn't want to go into details?

 

This last page or so proves that its moot. Some of you don't understand it, some of you suffer from "not invented here", some think their way is the right way, and so on.

 

And you completely miss the difference between the API (the interface you talk to, which obviously must be standardized) and the implementation (the code that makes the API, which is totally not relevant).

 

In this case the list of proc nodes and their values IS the API, and that should be fixed. How they are implemented, where they get their data from, who cares?

 

I hate to say it (again), but I am very disappointed by the level of theoretical expertise with the different developers here. This is basic software engineering. I find it very frustrating...

 

Oh, and I have never said "it should be a proc". I said:

• there should be a governming body with representatives of all images to safegard and version the API
• the API should be easily accessable from Python, C and Bash shell
• the same solution should be shought for active and non-active multiboot slots (so there is one interface, no matter from which slot the data comes)
• data should be immutable, no user action should be able to change it

A proc node solution fits these points, as it is all very low level file reads without applying any logic.

 

Other solutions I've seen are either not immutable, are differerent between active and non-active image, and require parsing, shelling or other logic.

[Huevos]

 

 

What is wrong with a simple text file and allow each team to decide how to read it?

 

What is wrong with a proc node that anyone can read? That requires no parsing, and is therefore a lot easier to process in Bash, Python and C? And is immutable and therefore trustworthy, which a file is definitely not, as it can be altered, it can be removed, it can be overwritten by a restore, ....

 

https://github.com/O...envision-module now compiles even for dm800 (kernel 2.6.18) so it works for all, I hope I can come up with something good for multiboot detection.

 

Where is the bb for this?

[Persian Prince]

 

 

 

What is wrong with a simple text file and allow each team to decide how to read it?

 

What is wrong with a proc node that anyone can read? That requires no parsing, and is therefore a lot easier to process in Bash, Python and C? And is immutable and therefore trustworthy, which a file is definitely not, as it can be altered, it can be removed, it can be overwritten by a restore, ....

 

https://github.com/O...envision-module now compiles even for dm800 (kernel 2.6.18) so it works for all, I hope I can come up with something good for multiboot detection.

 

Where is the bb for this?

 

 

https://github.com/O...ision-module.bb

 

[IanSav]

Hi Littlesat,

 

There are two things here.... some comments multiboot can show in a description field (under the pig) and something that gives technical info about the hardware the image is running on (the proc or so aka branding stuff). I would say keep them apart.

 

YES!

 

This started as a hardware information discussion and now we seem to have brought in MultiBoot to confuse the issue.  Can we please keep these two very separate things separate.  The hardware items should be common without regard to the build or image running.

 

The MultiBoot information will, by definition, need to access each boot slot to get information pertaining to that slot.  It may be possible to automate the slot number processing by knowing the hardware and slot support for that hardware.  I think that the MultiBoot processing is different enough for this to be delayed and considered later.

 

I still think that the /proc proposal for the hardware information appears to be the best solution so far and appears to address all issues found with all other solutions.  This may not be the best solution for MultiBoot but let's worry about that later.

 

Regards,

Ian.

[Huevos]

And again we got to the starting point

 

Remember that I told you we use /etc/openvision/ ?

 

We even have more detailed image-version file in /etc

 

Our branding module has more details also.

 

Everyone said it's not good to use those "files" and here we go again.

 

I'm not sure which direction this discussion is going anymore.

I can't see any reason that you can't have the text file and the proc output... as long as the source of the data is the same. In the case of openvision the data is the same because in both cases it comes from the bitbake env.

[Huevos]

Hi Littlesat,

 

There are two things here.... some comments multiboot can show in a description field (under the pig) and something that gives technical info about the hardware the image is running on (the proc or so aka branding stuff). I would say keep them apart.

 

YES!

 

This started as a hardware information discussion and now we seem to have brought in MultiBoot to confuse the issue.  Can we please keep these two very separate things separate.  The hardware items should be common without regard to the build or image running.

 

The MultiBoot information will, by definition, need to access each boot slot to get information pertaining to that slot.  It may be possible to automate the slot number processing by knowing the hardware and slot support for that hardware.  I think that the MultiBoot processing is different enough for this to be delayed and considered later.

 

I still think that the /proc proposal for the hardware information appears to be the best solution so far and appears to address all issues found with all other solutions.  This may not be the best solution for MultiBoot but let's worry about that later.

 

Regards,

Ian.

No, we cant keep them separate. They both need dealing with at the same time, and if both are built at the same time by the same recipe the data will be identical.

 

Also as I already said it is nothing to do with slots. It must be possible to identify the image even if it is not loaded in a slot, and not running.

Edited by Huevos, 7 December 2020 - 08:48.

[littlesat]

No, we cant keep them separate. They both need dealing with at the same time, and if both are built at the same time by the same recipe the data will be identical.

 

I think it is a good idea to put hardware info in procs...

I think it is a bad idea to put image and software related things in procs...

But both can still be designed within the same API telling 'where and how' the data is stored.

 

Please note the method I currently determine the image name is a work-a-round.

Edited by littlesat, 7 December 2020 - 09:01.

[Huevos]

So if you don't want to use procs for software info, what do you suggest instead?

[littlesat]

For multi boot info just somewhere a text that will be shown... and also can be used in eg a (sub) about screen and included in the json file that read the download list.

When you put hardware info in procs I just suggest not to put software/image info there.

Edited by littlesat, 7 December 2020 - 14:39.

[Huevos]

So where do you suggest we put stuff such as distro?

[littlesat]

Now I retreive the image somehow from /etc/issue.... probably /etc/imageinfo?.... it could just hold text one row with an abbreviation and other rows with a description

 

openpli release candidate 8.0
This is a release candidate from openpli 8.0. We do not guarantee this image is stable blalbla
Please post commants to forums.openpli.org blablabla

[IanSav]

Hello Huevos,

 

No, we cant keep them separate. They both need dealing with at the same time, and if both are built at the same time by the same recipe the data will be identical.

 

Also as I already said it is nothing to do with slots. It must be possible to identify the image even if it is not loaded in a slot, and not running.

 

The two items are quite separate and unrelated.  One aims to profile the hardware in use to allow the firmware to operate by abstracted hardware information.  The other deals with optional alternate firmware images.  How does knowing *ANYTHING* about an alternate boot image help you know anything about the hardware upon which the current image is running.

 

Trying to force both concepts into the single project will probably lead to no progress being made.  Even worse it can result in a terrible solution being found and forced on everyone that tries to treat the two scenarios using the same solution.  I don't know where or when the image and slot management became important but it is most certainly off topic and unrelated to when this thread began.  I would like to see the hardware abstraction issue not be lost, buried under or behind slot management.

 

Regards,

Ian.

[WanWizard]

The two items are quite separate and unrelated.  One aims to profile the hardware in use to allow the firmware to operate by abstracted hardware information.  The other deals with optional alternate firmware images.  How does knowing *ANYTHING* about an alternate boot image help you know anything about the hardware upon which the current image is running.

 

I do not agree with this.

 

If you boot slot 1, slot 2 is the "other image", if you boot slot 2, then slot 1 becomes the "other image".

 

Using two different methods of storing data means double maintenance for ALL images, why use a separate system if all information is already there?

[IanSav]

Hi WanWizard,

 

What does the firmware loaded into any slot have to do with the hardware description of the box?  Are you saying the the type and resolution of a front panel will change based on the boot image?  Will the box suddenly grow a DVI output connector depending on what firmware you select to boot?  How about the resolution of the HDMI connector, is that going to change?  How about the presence of the network interface hardware, or WiFi hardware?

 

As I commented, this discussion started with a requirement for abstracting the hardware specifications.  This primary aim should not be lost or confused in scope bloat.  Remember we are trying to remove code like "Is this a brand X, model Y box?" and use code like "Does this box have a 4K HDMI output?" or "Initialise the output display."  That is, the abstraction layer will interpret the generalised request from Enigma2 and apply the hardware specifics required by the hardware.  This has little / nothing to do with what image do you want to boot.

 

Regards,

Ian.

Edited by IanSav, 9 December 2020 - 15:46.

[WanWizard]

Fine, but then ALL non-hardware related info should be removed, and TWO API's should be designed, one for hardware related data, and one for all other data.

 

Which I have to say is silly as it means a complete duplication of code, as both will serve exactly the same purpose, but with a different dataset.

 

My objection is having to maintain the same data or code in two places.

[Huevos]

Fine, but then ALL non-hardware related info should be removed, and TWO API's should be designed, one for hardware related data, and one for all other data.

 

Which I have to say is silly as it means a complete duplication of code, as both will serve exactly the same purpose, but with a different dataset.

 

My objection is having to maintain the same data or code in two places.

+1. This should be done together. And data for both parts should come from a single source.

[IanSav]

Hi,

 

The point of my comment was not to have two distinct APIs or code if they two concepts are compatible.  My point was can we please get the primary objective of this thread done first before moving on to other projects.  That is, we started talking about hardware abstraction then lets get the hardware abstraction done.  Then look at the image / slot data management.

 

I am particularly concerned about feature creeping the image/slot management into this scope as this has always been a significant issue and difference between images and I don't want the complications of this element to bog down the hardware abstraction.

 

Regards,

Ian.

[WanWizard]

image/slot management is logic, this is about data, it should not contain any logic.  Those two should indeed never be mixed.

 

My point was more that there is already data included that isn't directly hardware related. Things like distro, skin dimensions, etc. I don't have an issue to add things like distro type and distro version to it.

 

I don't think anything more was needed, it is only to properly display what is installed in a slot (i.e. "distro - type - version" or whatever).

[Persian Prince]

Hi,

 

The point of my comment was not to have two distinct APIs or code if they two concepts are compatible.  My point was can we please get the primary objective of this thread done first before moving on to other projects.  That is, we started talking about hardware abstraction then lets get the hardware abstraction done.  Then look at the image / slot data management.

 

I am particularly concerned about feature creeping the image/slot management into this scope as this has always been a significant issue and difference between images and I don't want the complications of this element to bog down the hardware abstraction.

 

Regards,

Ian.

 

That's why I left this topic as it gets to nowhere.

 

I started to solve a real problem and now it's about multiboot (something I never use and even for PC dual boot I use two SSDs) and GOD knows about tomorrow.

 

If you all agreed on something we'll follow.

 

Regards,

Persian Prince