772 replies to this topic

[Huevos]

So are those procs going to work when enigma is not running?

[Persian Prince]

So are those procs going to work when enigma is not running?

 

Yes

 

They're not writable, they have static values and they're being managed by kernel so as long as kernel works the module works too.

 

I removed the cleanup function and once it loaded you can't even rmmod it so it's reliable.

 

It could be integrated to the kernel instead of a module but not good for build process.

[WanWizard]

It could be integrated to the kernel instead of a module but not good for build process.

 

Especially not if the code is generated. That means that with every change, the kernel gets recompiled, bad idea...

[Persian Prince]

It could be integrated to the kernel instead of a module but not good for build process.

 
Especially not if the code is generated. That means that with every change, the kernel gets recompiled, bad idea...

Yes exactly because of that, but what if user deleted the .ko file? He's fucked

[betacentauri]

Same like when user deletes enigma2 or better busybox binary. We can't prevent all.

[WanWizard]

"As soon as you think you''ve made it fool proof, a bigger fool comes along."

[Persian Prince]

Can you put an example from the resulting content of the proc here? Maybe better to have one proc called branding that contains all ‘fixed’ values....
I would consider one proc with consistent labels.... that can be readed in e2 at once and the image builder can choose how to read it, store it etc in enigma2.... it only gets box name and those stuff from the proc...

-r--r--r--    1 root     root             0 Dec  3 05:14 architecture cortexa15hf-neon-vfpv4
-r--r--r--    1 root     root             0 Dec  3 05:14 blindscanbinary blindscan
-r--r--r--    1 root     root             0 Dec  3 05:14 brand airdigital
-r--r--r--    1 root     root             0 Dec  3 05:14 developername Petr Kracik
-r--r--r--    1 root     root             0 Dec  3 05:14 distro openvision
-r--r--r--    1 root     root             0 Dec  3 05:14 feedsurl http://openvision.yacp.net/feeds/openvision-develop
-r--r--r--    1 root     root             0 Dec  3 05:14 forcemode no
-r--r--r--    1 root     root             0 Dec  3 05:14 imagedir h9
-r--r--r--    1 root     root             0 Dec  3 05:14 imagefs  ubi
-r--r--r--    1 root     root             0 Dec  3 05:14 kernel 4.4.35
-r--r--r--    1 root     root             0 Dec  3 05:14 kernelfile uImage
-r--r--r--    1 root     root             0 Dec  3 05:14 mediaservice enigma2-plugin-systemplugins-servicehisilicon
-r--r--r--    1 root     root             0 Dec  3 05:14 middleflash False
-r--r--r--    1 root     root             0 Dec  3 05:14 mkubifs -m 2048 -e 126976 -c 8192
-r--r--r--    1 root     root             0 Dec  3 05:14 model h9
-r--r--r--    1 root     root             0 Dec  3 05:14 mtdbootfs
-r--r--r--    1 root     root             0 Dec  3 05:14 mtdkernel mtd6
-r--r--r--    1 root     root             0 Dec  3 05:14 mtdrootfs mtd7
-r--r--r--    1 root     root             0 Dec  3 05:14 multilib False
-r--r--r--    1 root     root             0 Dec  3 05:14 oe master
-r--r--r--    1 root     root             0 Dec  3 05:14 platform zgemmahisi3798mv200
-r--r--r--    1 root     root             0 Dec  3 05:14 python 2.7.18
-r--r--r--    1 root     root             0 Dec  3 05:14 rcidnum 1
-r--r--r--    1 root     root             0 Dec  3 05:14 rcname zgemma6
-r--r--r--    1 root     root             0 Dec  3 05:14 rctype 28
-r--r--r--    1 root     root             0 Dec  3 05:14 rootfile rootfs.ubi
-r--r--r--    1 root     root             0 Dec  3 05:14 smallflash False
-r--r--r--    1 root     root             0 Dec  3 05:14 socfamily hisi3798mv200
-r--r--r--    1 root     root             0 Dec  3 05:14 ubinize -m 2048 -p 128KiB
-r--r--r--    1 root     root             0 Dec  3 05:14 visionlanguage extralanguage
-r--r--r--    1 root     root             0 Dec  3 05:14 visionrevision 10.2
-r--r--r--    1 root     root             0 Dec  3 05:14 visionversion r279

[Erik Slagter]

Why is the content in the filename???

[Persian Prince]

Why is the content in the filename???

 

It's not, I just wrote what each proc file has beside.

Edited by Persian Prince, 2 December 2020 - 20:29.

[WanWizard]

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?)

[Abu Baniaz]

How would that work for Multiboot image selection as an example? If every image used their own directory, that means to establish what image was in a slot, all the various names would have to be listed in every image.

 

Wouldn't a uniform name and location detailing the image be the way to go?

[WanWizard]

No, "distro" is a global node, And its value should be the same as that subdirectory.

 

But all other globally needed information should also be global. The "distro" subdirectory should only contain nodes the image (maker) itself uses, and is not under control of the "governing body".

 

The biggest problem, and why I never suggested proc nodes, is that you have them only from the booted image. There is no way to access node data from other boot partitions.

 

So if that is a requirement, proc nodes are not a solution.

[betacentauri]

How would that work for Multiboot image selection as an example? If every image used their own directory, that means to establish what image was in a slot, all the various names would have to be listed in every image.

 

Wouldn't a uniform name and location detailing the image be the way to go?

What do you need to multiboot image selection? You need to know where to find the Startup files. Maybe startup file format and slot count and on which device the partition is located.

I wouldn't store image names. These can change every minute (you can flash always via USB stick, boot menu or ofgwrite) new images and there is no mechanism to store the image names somewhere.

So better like now retrieve the image names on the fly.

[Abu Baniaz]

I am referring to the image details shown on the selection screen.  "Like now" does not work too well across the images. 

 

Vix screen here

 image selection vix.jpg   67.17KB   3 downloads

 

PLI screen here

 image selection pli.jpg   50.56KB   3 downloads

 

As you can see, On PLI, there is no indication as to whether I will be selecting the Dev version of Vix or Homebuild version.

 

This is a minor issue and should not hold up implementation. 

 

[Persian Prince]

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?)

 

It's just what we use, it's not the final API so of course that would be version/revision instead of visionversion/visionrevision, I'm not stupid

 

We could go like this:

 

/proc/enigma2/distro (force)

 

/proc/distro/proc1

~

/proc/distro/procn

 

(Reserved and nobody should change any proc name here)

 

/proc/distro/specific/proc1

~

/proc/distro/specific/procn

 

(Optional and do what you want)

[Persian Prince]

No, "distro" is a global node, And its value should be the same as that subdirectory.

 

But all other globally needed information should also be global. The "distro" subdirectory should only contain nodes the image (maker) itself uses, and is not under control of the "governing body".

 

The biggest problem, and why I never suggested proc nodes, is that you have them only from the booted image. There is no way to access node data from other boot partitions.

 

So if that is a requirement, proc nodes are not a solution.

 

That could be solved

 

In each build we copy a txt/py file of proc contents with bitbake to a specific location that every team must follow then in Python/C/Shell/Whatever we go like this:

 

if /proc/enigma2/distro == /lib/modules/enigma2/distro:

    then it's native

else:

    then it's multiboot

 

(Example)

Edited by Persian Prince, 3 December 2020 - 00:43.

[Persian Prince]

I am referring to the image details shown on the selection screen.  "Like now" does not work too well across the images. 

 

Vix screen here

image selection vix.jpg

 

PLI screen here

image selection pli.jpg

 

As you can see, On PLI, there is no indication as to whether I will be selecting the Dev version of Vix or Homebuild version.

 

This is a minor issue and should not hold up implementation. 

 

/proc/distro/imagetype

 

(develop,rc,beta,private,stable)

 

Also the txt/py file comes with the module

 

Possibilities are endless.

Edited by Persian Prince, 3 December 2020 - 00:44.

[IanSav]

Hi,

 

I think what Persian Prince has done is exactly what we needed.  It is some code and some results that we can see, explore and react to.  As can be seen, some appropriate reaction and discussion has begun.  The results of these discussion can be used to improve or amend the proposal or highlight that a different approach may be needed.

 

My initial reaction is to ask if we can please not use spaces in the proc file names.  These tend to be mishandled by many coders.  Then I would like to suggest that each of the file names have a standardised name, like an API entry point name.  This name should be common and agreed upon by all images.  This is along the lines of the textural API descriptions that XRayhTec and I tried to inject into the discussions earlier.  The files can then contain the results of the API call as appropriate.  If the file is read only then the content is immutable otherwise the content can be updated as required.

 

The file content can then be text or binary as required by the nature of the data.  The coder simply needs to open the file and read the content and use it as appropriate (hopefully documented).

 

So, using Persian Prince's example above, there could be a "/proc/distro/imagetype" file that, when read, will return content in the form of a string from one of the documented options "develop", "rc", "beta", "private" or "stable".  Given this is information about the build running this file would be read only and the content immutable.

 

I think there should also be consideration given to the way the data is captured.  In this example the data is a word in lower case.  I would like to propose that the data may be better stored in a case sensitive way so that the string retrieved can be immediately used for display to a user without further processing.  For example I can see that the "imagetype" data may well be used on an About screen so having the string saved as "Develop" or "Stable" etc may be more visually pleasant.  If required for processing the case can be changed for programmatic use.  This will become more significant for values like the image name where images have preferred case presentations like "openATV", "OpenPLi", "OpenVision" and "OpenViX" etc.  Similarly the hardware names, model names and other information for which the case can improve presentation can be stored appropriately.  These can be saved and presented in their display ready form but easily converted to lower or upper case for computational purposes.  Trying to use code to make these strings display ready will take more processing power to perform the transmutations and the formatting rules will be so complex it will not be worth the effort.  A little care an attention to the data when it is initially created can make the quality of this system significantly better and more efficient later.

 

What do people think?

 

Regards,

Ian.

[Huevos]

 

So are those procs going to work when enigma is not running?

 

Yes

 

They're not writable, they have static values and they're being managed by kernel so as long as kernel works the module works too.

 

I removed the cleanup function and once it loaded you can't even rmmod it so it's reliable.

 

It could be integrated to the kernel instead of a module but not good for build process.

de

How? please explain.

 

Image A is loaded and running in a slot. Image B is in a folder on a USB. Please explain how your code gives access to details of image B.

 

boxbranding.so works in the above situation.

Edited by Huevos, 3 December 2020 - 02:22.

[Persian Prince]

So are those procs going to work when enigma is not running?

Yes

They're not writable, they have static values and they're being managed by kernel so as long as kernel works the module works too.

I removed the cleanup function and once it loaded you can't even rmmod it so it's reliable.

It could be integrated to the kernel instead of a module but not good for build process.
de

How? please explain.

Image A is loaded and running in a slot. Image B is in a folder on a USB. Please explain how your code gives access to details of image B.

boxbranding.so works in the above situation.

In each build we copy a txt/py file of proc contents with bitbake to a specific location (for example besides module with exact name) that every team must follow then in Python/C/Shell/Whatever we go like this:

if /proc/enigma2/distro == /lib/modules/enigma2/distro:
then it's native
read proc
else:
then it's multiboot
read txt

(Example)

Edited by Persian Prince, 3 December 2020 - 02:40.