Jump to content


Photo

One proc file for detecting the MACHINE in all enigma2 images.


  • Please log in to reply
772 replies to this topic

Re: One proc file for detecting the MACHINE in all enigma2 images. #541 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 12:46

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.



Re: One proc file for detecting the MACHINE in all enigma2 images. #542 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 13 December 2020 - 12:53

@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 :D

 

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


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #543 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 13 December 2020 - 12:55

 

 

 

 

 

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.


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #544 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 13:24

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.


Re: One proc file for detecting the MACHINE in all enigma2 images. #545 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 14:20

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #546 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 13 December 2020 - 15:08

 

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


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #547 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 13 December 2020 - 15:29

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.

Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #548 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 16:50

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.



Re: One proc file for detecting the MACHINE in all enigma2 images. #549 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 17:51

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


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #550 Persian Prince

  • Senior Member
  • 1,982 posts

+247
Excellent

Posted 13 December 2020 - 18:55

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.


Open Vision sources: https://github.com/OpenVisionE2


Re: One proc file for detecting the MACHINE in all enigma2 images. #551 Abu Baniaz

  • PLi® Contributor
  • 2,499 posts

+64
Good

Posted 13 December 2020 - 20:19

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.



Re: One proc file for detecting the MACHINE in all enigma2 images. #552 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 20:44

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


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #553 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 21:57

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.



Re: One proc file for detecting the MACHINE in all enigma2 images. #554 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 21:58

 

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.



Re: One proc file for detecting the MACHINE in all enigma2 images. #555 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 22:03

In that case, nothing said... ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #556 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 22:15

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



Re: One proc file for detecting the MACHINE in all enigma2 images. #557 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 22:19

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.
 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: One proc file for detecting the MACHINE in all enigma2 images. #558 Abu Baniaz

  • PLi® Contributor
  • 2,499 posts

+64
Good

Posted 13 December 2020 - 22:20

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.


Re: One proc file for detecting the MACHINE in all enigma2 images. #559 Huevos

  • PLi® Contributor
  • 4,661 posts

+163
Excellent

Posted 13 December 2020 - 22:22

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?



Re: One proc file for detecting the MACHINE in all enigma2 images. #560 WanWizard

  • PLi® Core member
  • 70,528 posts

+1,811
Excellent

Posted 13 December 2020 - 22:33

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.



3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users