772 replies to this topic

[Persian Prince]

Well, you are implying that the image details should be in /etc/openvision and you also say you have an /etc/image-version with more details

Having image details in a varyiing name 

 

To me, using /etc/image-version or any other path/filename identical across images and accessible by python/c and using the same variable names is a solution and move forward.

 

When did I did that?

 

I said those are just our examples and any name could be used for the final solution.

 

We have them all to show all the possible ways.

 

We have /etc/openvision/ like proc entries.

 

We have /etc/image-version

 

We have branding module.

 

We have the new kernel module.

 

And all of those have more details compare to others.

 

Forget about us/our name please and focus on the solution which I'm confused if there's any.

 

Using only 1 file for keeping all the details is a complete mistake as we're not just talking about python.

[Huevos]

 

There is no big problem, just tweaks needed.

 

ViX has a file called image-version in /etc

Creator = OpenViX
Version = 5.4
Build = 004
Dev = 003
Type = developer
Machine = gbue4k
URL = http://www.world-of-satellite.com

ViX also has a Python file (/usr/lib/enigma2/python/ImageIdentifier.py):

def getBoxType(): return 'vuultimo4k'
def getImageDistro(): return 'openvix'
def getImageVersion(): return '5.4'
def getImageBuild(): return '004'
def getImageDevBuild(): return '016'
def getImageType(): return 'experimental'
def getMachineBrand(): return 'Vu+'
def getImageBuildDate(): return '20201201'

This means no Python 2/3 compatibility problem that the .so file is subject to. And no need to parse the file to get the data, just import it.

Edited by Huevos, 3 December 2020 - 20:13.

[Abu Baniaz]

Whatever file is used to determine/record image details needs to be:

• Same location
• Same filename
• Same variable names (distro name, date built, distro type, etc.... Not every image has all of them.)
• Accessible whether image is active or not

 

For discussion's sake:

Do you want to flash image X?

Do you want to boot image Y?

 

Just look at lack of consistency here. I have replaced the image names with xxxx

https://github.com/oe-alliance/oe-alliance-core/blob/4.4/meta-oe/recipes-distros/xxxx/image/xxxx-version-info.bb

https://github.com/o...recipes-distros

[WanWizard]

That is what I mean with governance.

 

We need a group with one person from every team, who together make sure everything is and stays in sync, and who will decide with variables will be added, with what specification.

[WanWizard]

ViX also has a Python file (/usr/lib/enigma2/python/ImageIdentifier.py)

 

I have no problem with that interface, add

if __name__ == '__main__':
    globals()[sys.argv[1]]()

to the bottom and you can do

VAR=`python ImageIdentifier.py getImageBuildDate` in bash.

Remains the question how to access the data from C (either in enigma or in a standalone binary.
 

[littlesat]

And eg to retreive more image info for multiboot it would be helpfull to have one standard method here

[Huevos]

 

ViX also has a Python file (/usr/lib/enigma2/python/ImageIdentifier.py)

 

I have no problem with that interface, add

if __name__ == '__main__':
    globals()[sys.argv[1]]()

to the bottom and you can do

VAR=`python ImageIdentifier.py getImageBuildDate` in bash.

Remains the question how to access the data from C (either in enigma or in a standalone binary.
 

 

Write a bit of cpp to read a python module.

[IanSav]

Hi,

 

The questions about where to store the data seemed to be resolved by having /proc entries such that shell, C++ and Python could all equally access the data from /proc.  We now seem to have gone back to the beginning and trying to work out where to store the data so it is available at all layers.  What was wrong with the /proc proposal?

 

Regards,

Ian.

[littlesat]

From cpp as well shell script you can execute python code...

[WanWizard]

The questions about where to store the data seemed to be resolved by having /proc entries such that shell, C++ and Python could all equally access the data from /proc.  We now seem to have gone back to the beginning and trying to work out where to store the data so it is available at all layers.  What was wrong with the /proc proposal?

For the running image, nothing.

 

For the installed images in multiboot, it means the data isn't accessable. And having two differerent methods to fetch the data isn't my preferred way of doing things. So that still needs to be solved.

 

I think it will be difficult for the C code that creates the nodes, to check the multiboot partitions, and create something like /proc/<something>/multiboot/slot1, /proc/<something>/multiboot/slot2, etc.

[littlesat]

A python executable file within an image slot can be executed as command and give back information.... the same a Static txt file can do... as far I know procs can’t be parsed.

Edited by littlesat, 4 December 2020 - 12:40.

[WanWizard]

Yes, but that means two solutions carrying the same data. Once in the C code (for when the image is booted) and once in he Python code (for when the image is in a non-active multiboot slot).

 

What if we turn it around?

 

Say we create /proc/<rootnode> as the root.

 

Then we have a binary that creates the proc nodes for the installed image. Have that binary accept a slot number as argument, and an optional argument to indicate the slot number is the current/active slot.

 

With this information the binary creates /proc/<rootnode>/slotX/<nodes>, and if current, it also creates /proc/<rootnode>/current = "slotX".

 

This way you have all information of all installed images available in proc nodes, in a uniform way.

[Erik Slagter]

I would like to suggest to move distro specific nodes to a subdirectory, so "/proc/openvision/version" instead of "/proc/visionversion". to keep it clean and generic.

 

And we still need a body to govern over the generic proc nodes, to make sure they are consistent, not image specific, and everyone implements them (versioning, want to do when new nodes are needed?)

 

Also don't create them under the root anyway. Actually I think you won't even be allowed to do that. Create a directory with a compelling name

[WanWizard]

Yes, see my previous post

[Erik Slagter]

Yes, but that means two solutions carrying the same data. Once in the C code (for when the image is booted) and once in he Python code (for when the image is in a non-active multiboot slot).

 

What if we turn it around?

 

Say we create /proc/<rootnode> as the root.

 

Then we have a binary that creates the proc nodes for the installed image. Have that binary accept a slot number as argument, and an optional argument to indicate the slot number is the current/active slot.

 

With this information the binary creates /proc/<rootnode>/slotX/<nodes>, and if current, it also creates /proc/<rootnode>/current = "slotX".

 

This way you have all information of all installed images available in proc nodes, in a uniform way.

 

Even better, use the same mechanism that is already used for /proc itself (process information), set a symlink, don't duplicate.

[Erik Slagter]

Yes, see my previous post

 

And then a parent above that.

 

Something like

 

/proc/stbconfig/current -> /proc/stbconfig/slot/0

/proc/stbconfig/slot/0

/proc/stbconfig/slot/1

[IanSav]

Hi littlesat,

 

From cpp as well shell script you can execute python code...

 

There is a significant memory and processor cost launching Python to run Python code.  Accessing a text file is significantly easier.

 

Regards,

Ian.

[littlesat]

When it is one txt file....

[WanWizard]

And then a parent above that.

 

Something like

 

/proc/stbconfig/current -> /proc/stbconfig/slot/0

/proc/stbconfig/slot/0

/proc/stbconfig/slot/1

 

I didn't mean a replication of data, but using a pointer. But yes, a symlink is a better idea.

[Huevos]

Hi,

 

The questions about where to store the data seemed to be resolved by having /proc entries such that shell, C++ and Python could all equally access the data from /proc.  We now seem to have gone back to the beginning and trying to work out where to store the data so it is available at all layers.  What was wrong with the /proc proposal?

 

Regards,

Ian.

It can only be accessed in a running image.