772 replies to this topic

[Huevos]

Hi,

 

It seems that some people don't have the imagination or vision to work out what Persian Prince is trying to explain.  Nitpicking appears to be preferred over progress.  My comment also didn't appear to be explicit or clear enough to explain what I think Persian Prince is intending so I will try again.

 

Persian Prince appears to be suggesting that his proposed module be added/included onto *EVERY* Enigma2 system.  The file is intended to live in a directory something like "/lib/modules/<kernelversion>/kernel/drivers/enigma2/enigma2.ko" or "/lib/modules/<kernelversion>/kernel/drivers/enigma2.ko" so as to be acceptable for the kernel in use.  As has been pointed out as an issue the "<kernelversion>" element is dynamic.  On my test machine the "<kernelversion>" location is actually "4.10.12".  The previously unspoken intention was to create a link from that location to something more globally standard like "/lib/modules/enigma2.ko" or even "/lib/enigma2.ko".  This link can easily be the same on *all* Enigma2 images and builds so it can easily be found by Enigma2 code yet still be appropriately located for use by the kernel.

 

@Persian Prince, is my interpretation what you are intending?

 

Regards,

Ian.

If all the theory men stopped commentating and actually provided some useful input such as variable names this project would have been closed months ago. And if people looked at the app and actually tried to build it this thread wouldn't be so full of stupid questions.

[Persian Prince]

@Persian Prince.

Congratulations with your 31th birthday. Enjoy this special day.

 

Oh thanks a lot

 

I wish my solution get chosen and we start changing things soon

 

Hi Persian Prince,

 

Happy Birthday!

 

Regards,

Ian.

 

Thanks a lot my friend

 

A good recovery for both of us I hope

 

Hip hip hip hoera!

Thank you

[Persian Prince]

 

 

 

 

 

How about?
 
/proc/hardware_data.ko
(for hardware data that distros put there)
 
/proc/enigma2_data.ko
(for enigma data, distro name, type, version, url etc. Several images already use /etc/image-version)

 
.ko file in /proc path?!
 
You can't even modprobe such thing, and there will be no two .ko files for sure, nobody wants to double the maintenance.

So what was that test file you uploaded? Or are you saying it should not have a .ko extension?

1) The ".ko" file is the kernel module. The file starts running when the stb boots. You don't access that file directly. The program in that file puts up entries in the /proc folder. These are not files but are readable from the file system as if they were files.
 
2) Any kernel module (the ".ko" file) can be analyzed by "modinfo" whether it is running or not. This has nothing to do with the entries in the /proc folder.

A kernel module won't start unless you load it or some other module depends on it and loads it so "The file starts running when the stb boots." is wrong.

What I added to be acccessible from modinfo commamd is exactly because of this so even without loading the module data could be extracted.

image-version or any .py file is not secure as they could easily change so reliability of such those files is absolute 0

 

What do you mean it is wrong? It is loaded at boot by /etc/modules-load.d/xxx.conf.

 

Yes that's because I added:

KERNEL_MODULE_AUTOLOAD += "openvision"

otherwise the module won't get loaded by default.

[Huevos]

Personally I wouldn't want that in the distro.conf file (or equivalent). I want modules built from their own recipes rather than having bits distributed all around "core" repo.

do_install() {
	install -d ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers/openvision
	install -m 0644 ${S}/openvision.ko ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers/openvision/
	install -d ${D}${sysconfdir}/modules-load.d
	install -m 0644 ${WORKDIR}/git/modules-load.d/openvision.conf ${D}${sysconfdir}/modules-load.d/
}

Edited by Huevos, 13 December 2020 - 13:25.

[WanWizard]

Personally I wouldn't want that in the distro.conf file (or equivalent). I want modules built from their own recipes rather than having bits distributed all around "core" repo.

 

+10.

 

But I think every image builder is free on how to implement it, the only thing that is important that after booting the image, the proc nodes are there. How they get there isn't really relevant.

[Persian Prince]

 

Personally I wouldn't want that in the distro.conf file (or equivalent). I want modules built from their own recipes rather than having bits distributed all around "core" repo.

 

+10.

 

But I think every image builder is free on how to implement it, the only thing that is important that after booting the image, the proc nodes are there. How they get there isn't really relevant.

 

Yes this part is up to the teams.

 

We have cleaner recipes less hardcoded values and that's how we like them

[Persian Prince]

As I see no objection to my solution anymore I assume this is the way so lets talk about API and where to work on this module.

 

https://github.com/e2openplugins could be a common ground, also our git is fine and invitations could be sent but I really don't care where's the git as long as it's on github not on weird platforms like bitbucket.

 

As the proc entries could be used/read for other softwares it's better to use a general name for it like:

 

/proc/extrainfo (please don't go for names like firmware hardware software as they all can be there)

 

We should have a list of reserved proc entries and the rest would be optional (like vision entries that we have and we will keep).

 

Here's a list of reserved entries (suggested by me):

/proc/extrainfo/model
/proc/extrainfo/brand
/proc/extrainfo/platform
/proc/extrainfo/version
/proc/extrainfo/revision
/proc/extrainfo/feedsurl
/proc/extrainfo/distro
/proc/extrainfo/oe
/proc/extrainfo/kernel
/proc/extrainfo/python
/proc/extrainfo/architecture
/proc/extrainfo/socfamily
/proc/extrainfo/rctype
/proc/extrainfo/rcname
/proc/extrainfo/rcidnum
/proc/extrainfo/imagedir
/proc/extrainfo/imagefs
/proc/extrainfo/mtdbootfs
/proc/extrainfo/mtdrootfs
/proc/extrainfo/mtdkernel
/proc/extrainfo/rootfile
/proc/extrainfo/kernelfile
/proc/extrainfo/mkubifs
/proc/extrainfo/ubinize
/proc/extrainfo/forcemode

I have no idea how many teams want to work on this module but I can only see PLi, ViX and Open Vision for now, so others will follow?

 

From each team we need someone who knows how kernel/modules work not someone to just maintain the repo as I'm pretty good with git maintenance (no offence but we need devs with kernel experience) so talk about this inside and let us know.

Edited by Persian Prince, 13 December 2020 - 15:30.

[Huevos]

As I see no objection to my solution anymore I assume this is the way so lets talk about API and where to work on this module.

 

https://github.com/e2openplugins could be a common ground, also our git is fine and invitations could be sent but I really don't care where's the git as long as it's on github not on weird platforms like bitbucket.

 

As the proc entries could be used/read for other softwares it's better to use a general name for it like:

 

/proc/extrainfo (please don't go for names like firmware hardware software as they all can be there)

 

We should have a list of reserved proc entries and the rest would be optional (like vision entries that we have and we will keep).

 

Here's a list of reserved entries (suggested by me):

/proc/extrainfo/model
/proc/extrainfo/brand
/proc/extrainfo/platform
/proc/extrainfo/version
/proc/extrainfo/revision
/proc/extrainfo/feedsurl
/proc/extrainfo/distro
/proc/extrainfo/oe
/proc/extrainfo/kernel
/proc/extrainfo/python
/proc/extrainfo/architecture
/proc/extrainfo/socfamily
/proc/extrainfo/rctype
/proc/extrainfo/rcname
/proc/extrainfo/rcidnum
/proc/extrainfo/imagedir
/proc/extrainfo/imagefs
/proc/extrainfo/mtdbootfs
/proc/extrainfo/mtdrootfs
/proc/extrainfo/mtdkernel
/proc/extrainfo/rootfile
/proc/extrainfo/kernelfile
/proc/extrainfo/mkubifs
/proc/extrainfo/ubinize
/proc/extrainfo/forcemode

I have no idea how many teams want to work on this module but I can only see PLi, ViX and Open Vision for now, so others will follow?

 

From each team we need someone who knows how kernel/modules work not someone to just maintain the repo as I'm pretty good with git maintenance (no offence but we need devs with kernel experience) so talk about this inside and let us know.

Rather see hardware and firmware as the proc names. /proc/hardware/feature, /proc/firmware/feature.

 

For OE-Alliance the easiest thing is to make a common module that all teams can use. That way they can either make their own... or add one line to ./image/enigma2.bb and they would immediately be up and running.

[WanWizard]

Why does OE-Alliance care what other teams use? With all due respect, none of their business...

[Persian Prince]

Why does OE-Alliance care what other teams use? With all due respect, none of their business...

 

I think he means other teams in OE-A not us.

[Abu Baniaz]

Please add a build date value. Will give a more accurate build date than checking opkg status and more universal method than datestamp of bootimage.

[WanWizard]

+1. Saves a bit of logic and processing time too.

[Huevos]

Please add a build date value. Will give a more accurate build date than checking opkg status and more universal method than datestamp of bootimage.

The module is refreshed on every update so would give the date of the last update.

[Huevos]

 

Why does OE-Alliance care what other teams use? With all due respect, none of their business...

 

I think he means other teams in OE-A not us.

 

Yes that is exactly what I mean.

[WanWizard]

In that case, nothing said...

[Huevos]

As I see no objection to my solution anymore I assume this is the way so lets talk about API and where to work on this module.

 

https://github.com/e2openplugins could be a common ground, also our git is fine and invitations could be sent but I really don't care where's the git as long as it's on github not on weird platforms like bitbucket.

 

As the proc entries could be used/read for other softwares it's better to use a general name for it like:

 

/proc/extrainfo (please don't go for names like firmware hardware software as they all can be there)

 

We should have a list of reserved proc entries and the rest would be optional (like vision entries that we have and we will keep).

 

Here's a list of reserved entries (suggested by me):

/proc/extrainfo/model
/proc/extrainfo/brand
/proc/extrainfo/platform
/proc/extrainfo/version
/proc/extrainfo/revision
/proc/extrainfo/feedsurl
/proc/extrainfo/distro
/proc/extrainfo/oe
/proc/extrainfo/kernel
/proc/extrainfo/python
/proc/extrainfo/architecture
/proc/extrainfo/socfamily
/proc/extrainfo/rctype
/proc/extrainfo/rcname
/proc/extrainfo/rcidnum
/proc/extrainfo/imagedir
/proc/extrainfo/imagefs
/proc/extrainfo/mtdbootfs
/proc/extrainfo/mtdrootfs
/proc/extrainfo/mtdkernel
/proc/extrainfo/rootfile
/proc/extrainfo/kernelfile
/proc/extrainfo/mkubifs
/proc/extrainfo/ubinize
/proc/extrainfo/forcemode

I have no idea how many teams want to work on this module but I can only see PLi, ViX and Open Vision for now, so others will follow?

 

From each team we need someone who knows how kernel/modules work not someone to just maintain the repo as I'm pretty good with git maintenance (no offence but we need devs with kernel experience) so talk about this inside and let us know.

"extrainfo" is a meaningless name. "hardware" and "firmware".

 

Also not all the items in the list are available to all teams.

 

Attached a file of what our env variables look like.

Attached Files

•  bb-env-var.txt   1.64MB   2 downloads

[WanWizard]

Also not all the items in the list are available to all teams.

 

That is always bound to happen, and the reason for this excersize.

 

If someone needs something, and it is deemed to be not-image-specific, it needs to be added to the spec, and all images should implement it, even if they don't use it. Because a plugin might.
 

[Abu Baniaz]

The module is refreshed on every update so would give the date of the last update.

Do you mean the module which does not exist yet? If so, we have time to improve it's design.

The value in image-version file that some images use is the actual build date, not just when an update is done on GitHub.

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

[Huevos]

Oh, and

 

 

The module is refreshed on every update so would give the date of the last update.

Do you mean the module which does not exist yet? If so, we have time to improve it's design.

The value in image-version file that some images use is the actual build date, not just when an update is done on GitHub.

 

Abu, I have no idea what you mean. The build date of the module is when an update build is run. What else could it be?

[WanWizard]

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.