Posted 12 December 2020 - 21:27
Some proc entries are needed to be there with exact names (which we define later) for all teams and some can be there if a team wanted them.
So we're going to have reserved names and optional names, you can't force a team to not have an optional proc as long as it follows the API.
Also "kernelversion" is not a folder it's a variable as we all know there so many kernel verions out there.
Open Vision sources: https://github.com/OpenVisionE2
Posted 12 December 2020 - 21:30
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.
Open Vision sources: https://github.com/OpenVisionE2
Posted 12 December 2020 - 21:40
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?
Posted 12 December 2020 - 21:45
No. It has nothing to do with enigma2 or drivers. It is a kernel module to return hardware details. Calling it enigma2 is stupid. Enigma is software. And this runs from boot. It doesn't need enigma and has no dependence on it.
Edited by Huevos, 12 December 2020 - 21:50.
Posted 12 December 2020 - 21:51
So distro data is part of hardware then is it?
Posted 12 December 2020 - 21:59
The data is being added by an Enigma2 distro build process ( hopefully agreed by everyone), nothing intrinsic with the hardware (by manufacturer).
The process doesn't have to be agreed by everyone. Totally irrelevant. Only the end-result needs to be agreed.
I've been saying this since day one.
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.
Posted 12 December 2020 - 22:08
The data is being added by an Enigma2 distro build process ( hopefully agreed by everyone), nothing intrinsic with the hardware (by manufacturer).
The process doesn't have to be agreed by everyone. Totally irrelevant. Only the end-result needs to be agreed.
I've been saying this since day one.
The hardware data needs to be in the same location, with the same filename. On all distros! This is what I was referring to. I didn't mention build process has to be agreed.
An image build is what creates the data and the images have their varying methods of accomplishing it.
Posted 12 December 2020 - 22:48
So distro data is part of hardware then is it?
To me it is very clear distro is not hardware. If people want to add firmware to this it should be under that heading. e.g.
/proc/hardware/feature
/proc/firmware/feature
Posted 12 December 2020 - 23:36
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.
Edited by Huevos, 12 December 2020 - 23:37.
Posted 12 December 2020 - 23:42
The data is being added by an Enigma2 distro build process ( hopefully agreed by everyone), nothing intrinsic with the hardware (by manufacturer).
The process doesn't have to be agreed by everyone. Totally irrelevant. Only the end-result needs to be agreed.
I've been saying this since day one.
Yes, only thing that is relevant is x proc outputs this, y proc outputs that, etc. Right now that is what needs to be decided in this discussion.
Posted 13 December 2020 - 02:52
The data is being added by an Enigma2 distro build process ( hopefully agreed by everyone), nothing intrinsic with the hardware (by manufacturer).
The process doesn't have to be agreed by everyone. Totally irrelevant. Only the end-result needs to be agreed.
I've been saying this since day one.
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 December 2020 - 02:55
So distro data is part of hardware then is it?
To me it is very clear distro is not hardware. If people want to add firmware to this it should be under that heading. e.g.
/proc/hardware/feature
/proc/firmware/feature
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 December 2020 - 03:06
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.So what was that test file you uploaded? Or are you saying it should not have a .ko extension?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.
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.
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 December 2020 - 03:16
So what was that test file you uploaded? Or are you saying it should not have a .ko extension?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.
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 December 2020 - 05:39
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.
Posted 13 December 2020 - 06: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.
Yes 100%
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 December 2020 - 09:18
@Persian Prince.
Congratulations with your 31th birthday. Enjoy this special day.
Mijn schotel is een T90 met 10 LNB's. Daarnaast voor de fun nog een draaibaar systeem met een Triax TD 78.
Dreamboxen heb ik niet meer echt actief. Verder heb ik ook nog een een VU+ duo2 met 500Gb harddisk + een VU+ Uno, Zero, Solo 4K, Ultimo 4K, Zero 4K, Uno 4Kse. + ook nog een Xtrend ET7x00. Daarnaast heb ik ook nog diverse andere modellen w.o. een Formuler F4, ET8500, ET7500, Mut@nt 2400HD, Xsarius Fusion HD se en verder nog wel het e.e.a. waarmee op verzoek vanalles wordt getest. Iemand moet het tenslotte doen. 
Los van de eerder genoemde modellen heb ik nog wel een rits aan testsamples als Mut@nt 2400HD, HD60, GB UE4K, GB Trio4K, Maxitec Multibox combo en Twin, Octagon sf8008, sf8008 mini en last but nog least enkele modellen van het Grieks Duitse Edision.
Voor centrale opslag van media gebruik ik een Qnap 219P met tweemaal 2 Tb harddisks + een Synology DS414 met 12 Tb Totale opslag.
-------------------------------------------------------------------------------------------
Many answers to your question can be found in our wiki: Just one click away from this "solutioncentre".
Als ik alles al wist hoefde ik ook niets te vragen. If I had all the knowledge I had no questions at all.
Posted 13 December 2020 - 10:23
Hi Persian Prince,
Happy Birthday!
Regards,
Ian.
Posted 13 December 2020 - 10:44
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Posted 13 December 2020 - 12:32
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.
So what was that test file you uploaded? Or are you saying it should not have a .ko extension?
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.
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.
Edited by Huevos, 13 December 2020 - 12:32.
0 members, 13 guests, 0 anonymous users
