772 replies to this topic

[Persian Prince]

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.

Ian,

I'm against spaces in proc files like in model names but what about ubi parameters or similars?

Also using mixed case isn't good in my opinion especially when it comes to distro detection something that if you lose it you went to oblivion.

But we can have

/proc/distro/specific/friendlydistroname
/proc/distro/specific/friendlymodelname

As I said endless possibilities

At last I'm glad you're better and glad you like what I propose.

Regards,
Persian Prince

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

I wonder if I could improve this in other way and call it multiboot flag:

For now all of the proc files are read-only but we can have writable ones too so add another proc file called "multiboot" for example then read

/proc/enigma2/distro

and compare it with the txt/py file beside module, if the result was the same write

/proc/distro/multiboot (off)

else write

/proc/distro/multiboot (on)

in this case no other coding is required in other languages as kernel module is doing it for us.

Edited by Persian Prince, 3 December 2020 - 03:06.

[IanSav]

Hi Persian Prince,
 

I'm against spaces in proc files like in model names but what about ubi parameters or similars?

 

I think spaces should always be avoided in file names.  If you want separations try "." or "_".

 

Also using mixed case isn't good in my opinion especially when it comes to distro detection something that if you lose it you went to oblivion.

But we can have

/proc/distro/specific/friendlydistroname
/proc/distro/specific/friendlymodelname

As I said endless possibilities

 
I think having single values repeated for presentation purposes is unnecessary.  It will bloat the directory, require more maintenance and serve little purpose.  Save the value once and in display ready format.  The shell, C++ and Python all have a simple and fast ways to make a string upper or lower case for computational purposes.

 

At last I'm glad you're better and glad you like what I propose.

 

Thanks.

 

By the way, I reread this thread and realised that some of my comments about using the API type names in the /proc don't apply as that is what you already intended.  Sorry, I will blame the residual anesthesia in my system for my misunderstanding. 

Regards,
Ian.

 

[littlesat]

Why tons of procs while you put everything in one proc.

[Persian Prince]

Why tons of procs while you put everything in one proc.

 

How can we customize it then?

 

We want to have some proc files which are not general.

 

How Backup Suite or other shell related things get the values?

 

cat | grep | sed | cut ?

 

No, thank you.

Edited by Persian Prince, 3 December 2020 - 07:28.

[littlesat]

Just have a proc that has a format like this... Every image can put there what they like...

 

boxname=VU Duo 4K

trendname=VU+

... (I saw this style long time ago earlier in this thread)...

 

And then describe the minimal what should be there...

 

I know this is implementation... but somehow we need to finish this.

 

Having tons of procs means each thing need to be readed to collect al the info...

 

From the other side procs with just one 'line' of information are short to read...

 

It is just for putting a different solution here...

 

When at least (some) procs are different this isn't a real 'API... ' so we can continue to fight and discuss about 'OpenPLi misses proc x and OpenATV misses proc y....'.

 

When backup suite was a real python plugin instead of actually a full sh script it does not need to parse these kind of procs (note Console() module is helpfull here)... It can take the values right away from a python module that reads the proc(s).

Edited by littlesat, 3 December 2020 - 08:29.

[Persian Prince]

Just have a proc that has a format like this... Every image can put there what they like...

 

boxname=VU Duo 4K

trendname=VU+

... (I saw this style long time ago earlier in this thread)...

 

And then describe the minimal what should be there...

 

I know this is implementation... but somehow we need to finish this.

 

Having tons of procs means each thing need to be readed to collect al the info...

 

From the other side procs with just one 'line' of information are short to read...

 

It is just for putting a different solution here...

 

When at least (some) procs are different this isn't a real 'API... ' so we can continue to fight and discuss about 'OpenPLi misses proc x and OpenATV misses proc y....'.

 

When backup suite was a real python plugin instead of actually a full sh script it does not need to parse these kind of procs (note Console() module is helpfull here)... It can take the values right away from a python module that reads the proc(s).

 

Feel free to manage master branch of Backup Suite for PLi then

 

You're saying data is needed for python only so why introduce something new at all.

[IanSav]

Hi Littlesat,

 

Throwing all the possible data into a single file implies that we all have to start parsing the file and looking for items of interest.  The values and structure will quickly become divergent and all unification hopes will be quickly dashed.

 

Persian Prince has come up with a design that should be explored and discussed.  It appears to have addressed *all* the technical requirements that have been discussed so far.  At this point I think we should be checking if there are any show stoppers with his proposal.  If no-one can fault the core proposal then we should move to flesh it out with the specifications of all the data that needs to be presented.  If there is a problem with the design then let's see if the problem can be corrected or else look for an alternate design.

 

By the way, with regard to people deleting the kernel file.  I think this is a non issue.  All of Linux and Enigma2 suffers from the same risks.  If people tamper with any system files they deserve what they get.  If you don't understand something then leave it alone. 

 

Regards,

Ian.

[WanWizard]

The only issue I have is two different solutions for running image vs multiboot image, something you don't have with a py or so solution.

 

i.e. "python boxinfo,py getDistro" or "boxinfo.so getDistro"

 

Where Python is more flexible since every box has it, while compiled C may be dependent on libraries or library versions (and static linking makes it  big).

 

Downside of both is access from 'the other side". Accessing python from C is cumbersome, accessing an so from Python means lots of shelling....

[Persian Prince]

The only issue I have is two different solutions for running image vs multiboot image, something you don't have with a py or so solution.

 

i.e. "python boxinfo,py getDistro" or "boxinfo.so getDistro"

 

Where Python is more flexible since every box has it, while compiled C may be dependent on libraries or library versions (and static linking makes it  big).

 

Downside of both is access from 'the other side". Accessing python from C is cumbersome, accessing an so from Python means lots of shelling....

 

I'll try to cover multiboot detection with https://forums.openp...dpost&p=1280901

[Abu Baniaz]

Is having a proc file for machine/box/device capability and another for image details (same name by everyone) the way to go?

 

Also, I don't know where a multiboot flag comes into relevance. ViX does not do multi-boot/non-multi-boot images. If you flash an image using Image Manager in Vix, you will flash in a slot of your choice on a hardware multiboot device.  As far as I understand., if you flash the same image by USB, it wipes all the other partitions. The same applies to PLI, but you have different names for the compiled images and you cannot flash a multi-boot PLI image by USB.

 

The point I was making in post 391 is that the image details of any image should be readable. Although the discussion stream relates to hardware multiboot, the same image identification criteria should be available to plugins like OpenMultiBoot. Although OpenPLi do not endorse this, lots of pother people use the plugin.

[littlesat]

Just a point on wanwizard’s suggestion.... instead of a proc do you mean a python file on a specific location Of an image so multiboot is also able to take information out of an image.... (which is not possible with procs). These py’s just follow an agreed format (eg functions that can be called that give a proper answer or even better what you have in python properties - so the image builder itself can decide to make it a static variable or function?
I’m afraid this is a better method then using procs....

Edited by littlesat, 3 December 2020 - 16:55.

[betacentauri]

Do we really have a big problem with multiboot?

From my point of view do you only need one information from a not running image. Something like an image name perhaps with extra informations like ViX it has, but that can be in one single file which is read. What else do you need to know from a not running image?

Well you also need to know how to start that image. But this is generic and can be handled via proc entries.

[Abu Baniaz]

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

[betacentauri]

We should define one single file which contains the needed informations inclusive the format of the file (if needed). I would prefer a single line in a separate file, but it can also be a formatted one like ViX has, but then you need to parse it. If all images use this file, we have no problems.

[Abu Baniaz]

ATV uses same file and location too. With a lot more information about other things than image. 

 

box_type=gbue4k
build_type=
machine_brand=GigaBlue
machine_name=UHD UE 4K
version=6.4
build=20201203
date=20201203
comment=openATV
target=9
creator=openATV
url=http://www.opena.tv
catalog=http://www.opena.tv
oever=OE-Alliance 4.4
distro=openatv
brandoem=gigablue
machinemake=gbue4k
imageversion=6.4
imagebuild=20201203
imagedevbuild=001
imagetype=release
feedsurl=http://feeds2.mynonpublic.com/6.4/gb7252
imagedir=gigablue/ue4k
imagefs=tar.bz2 
mtdrootfs=mmcblk0p5
mtdkernel=mmcblk0p4
rootfile=rootfs.tar.bz2
kernelfile=kernel.bin
mkubifs=
ubinize=
driverdate=
arch=cortexa15hf-neon-vfpv4
display-type=colorlcd220
hdmi=True
yuv=False
rca=False
av-jack=False
scart=False
scart-yuv=False
dvi=False
minitv=False
hdmi-in-hd=False
hdmi-in-fhd=False
wol=False
wwol=False
ci=True
transcoding=transcoding

[littlesat]

Then I think it is better to have a python module with defined properties...
It seems ooenatv also added a lot of stuff that could be found on runtime...’

Edited by littlesat, 3 December 2020 - 18:24.

[Persian Prince]

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.

[Abu Baniaz]

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.

[betacentauri]

I only say that such a file is maybe needed to get informations for multiboot from a not running image. I haven't said we should use that for a running image!