772 replies to this topic

[Abu Baniaz]

If it gives the date of the build is made, then that is what I think is beneficial. Not the date that a last commit on GitHub was made.

 

For example, if somebody runs an OpenViX Release image today, the date should be today's date. Not the last commit to Release branch which was 11th November.

 

As PLI lock things down to hashes, then it does not matter to them too much.

Edited by Abu Baniaz, 13 December 2020 - 22:36.

[Huevos]

Bitbake would only update something when there is something to update. So in OpenPLi the module wouldn't update at all, if there is no change to the commit hash of the repo we're going to use for the source.

 

In OE-A that is different, as everything is done manually and you have to bump the PR to force a new build.

Well as the updating of data in the procs doesn't have anything to do with commits on the source repo that doesn't seem like a very good plan, unless you are thinking of having a load of static data on that repo.

 

And BTW, we don't have to bump the PR to rebuild a module. Most of our stuff is AUTOREV.

Edited by Huevos, 13 December 2020 - 22:40.

[WanWizard]

Afaik OE-A doesn't build with a PR server, so manual PR bumping was needed?

 

And as you don't know how we are going to implement it, you don't know. It might be a lot of static data (as most of the data actually is), why not? Does it matter where it comes from, if it is generated from BB variables, it's still static?

[Huevos]

If it gives the date of the build is made, then that is what I think is beneficial. Not the date that a last commit on GitHub was made.

 

For example, if somebody runs an OpenViX Release image today, the date should be today's date. Not the last commit to Release branch which was 11th November.

 

As PLI lock things down to hashes, then it does not matter to them too much.

 

 

Afaik OE-A doesn't build with a PR server, so manual PR bumping was needed?

 

And as you don't know how we are going to implement it, you don't know. It might be a lot of static data (as most of the data actually is), why not? Does it matter where it comes from, if it is generated from BB variables, it's still static?

Well that I don't understand because when I went to the trouble of collecting all the data previously your comment was that is just a lot of static data and not impressed.

[Persian Prince]

Bitbake would only update something when there is something to update. So in OpenPLi the module wouldn't update at all, if there is no change to the commit hash of the repo we're going to use for the source.

 

In OE-A that is different, as everything is done manually and you have to bump the PR to force a new build.

Our module gets rebuilded on each build because of:

do_configure[nostamp] = "1"

And as it's a tiny module you won't feel a thing.

 

So it's a good choice for image date

[IanSav]

Hi,

 

I think that a root tree name like "extrainfo" is inappropriate.  This tree is provided for and maintained by Enigma2 developers.  The primary reason for the existance of this data is to provide information to Enigma2.  The root name should reflect that.  I feel that a name like "enigma" would be far more appropriate.  I don't think that a version or generation number should be included to allow the name to survive and be appropriate for future generations of the code.

 

Regards,

Ian.

Edited by IanSav, 13 December 2020 - 23:17.

[WanWizard]

Well that I don't understand because when I went to the trouble of collecting all the data previously your comment was that is just a lot of static data and not impressed.

 

My point was and still is that for this discussion it is totally irrelevant where an image builder gets the data from, and how the proc nodes are created. Even discussions about ko file names are not relevant.

 

The only thing relevant is the list of proc nodes, and the exact specification of the data they return.

 

Because all the code (enigma and plugins) need is being able to rely on the nodes being there, and the data they return.

 

Also, I haven't seen anything about versioning. We need to think about that, for nodes that will be added at a later date. The "nodes being there" is then no longer something you can rely on.

[IanSav]

Hi WanWizard,

 

 

Well that I don't understand because when I went to the trouble of collecting all the data previously your comment was that is just a lot of static data and not impressed.

 

... Even discussions about ko file names are not relevant.

 

Sorry to disagree but the name will be important as this must be known by the Enigma2 code.  This is one of the variables that needs to be specified so that it can be used transparently across all builds, images and slots.

 

Regards,

Ian.

[WanWizard]

The module ko file loads on boot, which makes the proc nodes available. Why is the name of the module relevant? And I thought it was decided that proc nodes for multiboot images was a bad idea?

 

Did I miss something?

[IanSav]

Hi WanWizard,

 

The module ko file loads on boot, which makes the proc nodes available. Why is the name of the module relevant? And I thought it was decided that proc nodes for multiboot images was a bad idea?

 

Did I miss something?

 

Perhaps I missed something.  I thought that the ko file on each slot was to be accessed to get information about the image on slots other than the currently running image in the current slot.  That is why concern was shown earlier about the file being located in a path that contains a dynamic value (of the image's kernel version).

 

Regards,

Ian.

[WanWizard]

I don't know.

 

I've been too busy trying to get OpenPLi 8 out the door for Xmas, I've been just skimming the forum the last week...

[Persian Prince]

I don't know.

 

I've been too busy trying to get OpenPLi 8 out the door for Xmas, I've been just skimming the forum the last week...

https://forums.openp...dpost&p=1285090

 

[WanWizard]

Ah, ok, you're using modinfo to get the data from the multiboot partitions. Check, I get it, thanks!

[Huevos]

Hi WanWizard,

 

The module ko file loads on boot, which makes the proc nodes available. Why is the name of the module relevant? And I thought it was decided that proc nodes for multiboot images was a bad idea?

 

Did I miss something?

 

Perhaps I missed something.  I thought that the ko file on each slot was to be accessed to get information about the image on slots other than the currently running image in the current slot.  That is why concern was shown earlier about the file being located in a path that contains a dynamic value (of the image's kernel version).

 

Regards,

Ian.

Ian, I have no idea why you want to make this complicated. There is no need to know the kernel version folder name to access "modinfo" details of that file.

 

e.g.

root@vuultimo4k:~# python
Python 2.7.16 (default, Jan  3 2020, 14:39:48)
[GCC 9.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import subprocess
>>> import glob
>>>
>>> for f in glob.glob('/lib/modules/*/kernel/drivers/openvision/openvision.ko'):
...     print f
...
/lib/modules/3.14.28-1.12/kernel/drivers/openvision/openvision.ko
>>>
>>>
>>> p = subprocess.Popen("modinfo %s" % f, stdout=subprocess.PIPE, shell=True)
>>> (output, err) = p.communicate()
>>>
>>> print output
filename:       /lib/modules/3.14.28-1.12/kernel/drivers/openvision/openvision.ko
description:    Open Vision information
author:         Open Vision developers
license:        GPL
depends:
vermagic:       3.14.28-1.12 SMP mod_unload ARMv7 p2v8

>>>
>>>

Storing that data in the module description is already hack. Lets not add another hack to make the first hack "better".

[IanSav]

Hi Huevos,

 

Globbing for files is costly.  Why do it if it isn't required?

 

Also wasn't this code meant to be easy to find from the shell, C++ and Python?

 

You can call it a hack, you can call it whatever you want, this is the first proposal that seems to be acceptable to more people than any other suggestion made so far.  If we don't start moving forward then this thread and this issue will *never* progress.

 

Regards,

Ian.

[WanWizard]

I agree if the binary needs to be called, it would be better if the name is fixed / known. I don't see any reason for an creating an openpli.ko or an openvision.ko, if the name can be made generic.

 

Afaik the "modinfo" data is only used when scanning multiboot partitions, correct?

[Persian Prince]

I agree if the binary needs to be called, it would be better if the name is fixed / known. I don't see any reason for an creating an openpli.ko or an openvision.ko, if the name can be made generic.

 

Afaik the "modinfo" data is only used when scanning multiboot partitions, correct?

I agree with Ian, if we create a symlink for it would be good as we all know where is the shortcut no matter what the kernel version is.

 

We want to access it from everywhere so why search it first?

 

openvision.ko creates proc entries for you (when it's loaded) but if you want to extract information from a child image and you're the parent you just go with modinfo and read what's there.

 

*ALSO* modinfo is the backup plan so we could read it when the proc isn't there, you may want to skip this part but we at Open Vision won't because I don't want to rely on proc and when it's not there everything goes to hell.

 

I just nailed it

Edited by Persian Prince, 14 December 2020 - 03:14.

[littlesat]

I do not like an extra info proc folder.... I prefer eg branding and tender procs in the folder where they belong... based on existing first and name for the rest also a. Correct folder name... eg imagedirectories or so etc...

[Huevos]

Hi Huevos,

 

Globbing for files is costly.  Why do it if it isn't required?

 

Also wasn't this code meant to be easy to find from the shell, C++ and Python?

 

You can call it a hack, you can call it whatever you want, this is the first proposal that seems to be acceptable to more people than any other suggestion made so far.  If we don't start moving forward then this thread and this issue will *never* progress.

 

Regards,

Ian.

Don't you think iterogating the .ko with modinfo is already a nasty hack. And that output has to be parsed, which goes against the principal of this whole project. So hack on top of hack on top of hack to support the first hack. And now the new plan to add a symlink to make the chain of hacks work more smoothly.

Edited by Huevos, 14 December 2020 - 08:46.

[Huevos]

I do not like an extra info proc folder.... I prefer eg branding and tender procs in the folder where they belong... based on existing first and name for the rest also a. Correct folder name... eg imagedirectories or so etc...

So you want /proc/branding/<feature> ?

Edited by Huevos, 14 December 2020 - 08:34.