772 replies to this topic

[WanWizard]

No, I am saying that the order in which modules are loaded matters, if the module needs to use an existing proc path.

 

Say we go for /proc/stb/info, that means either /proc/stb already exists (box drivers are loaded first) or not, in which case it should be created. When it is created, the box driver may no longer load (as creating /proc/stb will fail).

 

This issue does not exist (and will not exist in the future) if we go for /proc/something-completely-unique-here/...

[betacentauri]

Please don’t spend 1000 post regarding a name. Yes, it shouldn’t be a complete nonsense name, but eg
/proc/enigma2 or /proc/firmware or /proc/e2branding or something like this is ok. We can collect all possible names and can later vote for it.

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.
There is still much to do.

[Persian Prince]

Please don’t spend 1000 post regarding a name. Yes, it shouldn’t be a complete nonsense name, but eg
/proc/enigma2 or /proc/firmware or /proc/e2branding or something like this is ok. We can collect all possible names and can later vote for it.

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.
There is still much to do.

 

I think we talked about this before

 

Only a common path is needed not exact data.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

But I'm not sure about something, do I need to add hardware features too?

 

Example:

 

/proc/openvision/lcd

 

then it writes "bwlcd128" or

 

/proc/openvision/transcoding

 

then it writes "True"

[Persian Prince]

Also we can have subfolders like:

 

/proc/openvision/hardware/

 

then add hardware related proc entries

 

/proc/openvision/distro/

 

then add distro related proc entries

 

*openvision is the prototype name not the final solution.

Edited by Persian Prince, 15 December 2020 - 00:37.

[WanWizard]

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.

[betacentauri]

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.

[Persian Prince]

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.

 

I can add all those proc nodes but how you want to give them data in PLi?

 

I suggest start updating all metas with what you need.

[WanWizard]

Maybe bad example from me. Better forget it.

Better example transcoding. Do we have one proc file named transcoding which returns True/False or true/false or 0/1. Or do we have more proc files as some boxes can transcode 2 streams. A transcoding proc and “numberOfTranscoder” proc. Or does transcoding proc returns 0, 1, 2 for the number of streams which can be transcoded? Do we need extra info for transcoding like the encoder device names and so on.
So many things to decide.

Better example.

[LraiZer]

Please don’t spend 1000 post regarding a name.

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts 

 

Nomenclature has been decided, ALL TEAMS shall follow this decision and continue with other api spec discussion!

 

The OpenHAL API specs for version 1.0 of this hardware abstraction layer (HAL) shall be as follows:

 

common ground repo for openhal will be here: https://github.com/E...Plugins/OpenHAL

 

kernel module will be called: openhal.ko

 

proc path will be here: /proc/openhal/

 

Merry Xmas 

[Persian Prince]

Please don’t spend 1000 post regarding a name.

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts 
 
Nomenclature has been decided, ALL TEAMS shall follow this decision and continue with other api spec discussion!
 
The OpenHAL API specs for version 1.0 of this hardware abstraction layer (HAL) shall be as follows:
 
common ground repo for openhal will be here: https://github.com/E...Plugins/OpenHAL
 
kernel module will be called: openhal.ko
 
proc path will be here: /proc/openhal/
 
Merry Xmas 

Naming isn't important now although you could check https://github.com/persianpros as I reserved some good and related org names like

https://github.com/OpenEnigma2

But openhal is like a team name and currently is openvision.

[WanWizard]

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts 

 

 

I don't care at all what it is, but indeed, using "openSomething" might not be a good idea. Shorten it to "hal", problem solved.

[Huevos]

 

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.

 

The whole project is pointless if the returned data is not identical in all distros. By the sound of it you seem to think this data is to be used for decorating the image, not for logic.

Edited by Huevos, 15 December 2020 - 10:24.

[littlesat]

if 'hd51' then do 'something else' is exactly what should be avoided... and why this discussion is needed. At the end it should be if 'feature available on this box' then 'use this feature' instead.... 

We strived to have the SystemInfo.py the only place where we have checks on box model but we already 'claim' a feature to it from there.... What is tried to design here is even remove the box model check out of here and go for the feature system somehow right away. And then we try to do this cross image...

[Huevos]

if 'hd51' then do 'something else' is exactly what should be avoided... and why this discussion is needed. At the end it should be if 'feature available on this box' then 'use this feature' instead.... 

We strived to have the SystemInfo.py the only place where we have checks on box model but we already 'claim' a feature to it from there.... What is tried to design here is even remove the box model check out of here and go for the feature system somehow right away. And then we try to do this cross image...

That is not how procs are currently used throughout the image. Yes, some current procs are used in a boolean way but plenty more output strings that the logic uses.

[littlesat]

What is done in SystemInfo.py is our implementation. We strived this was our only file in e2 that contains box model checks. Instead of check for box model it better could parse some procs to check for specific features.

[Huevos]

 

The name is not enough. We still need to speak about the needed informations and what exactly the API should return. Only one example box name. Should it return hd51 or mutant51? If both are needed how do we call the proc files and so on.

 

We want to use hd51 as we use the machine name but another team may use mutant51 but we both use same proc so in all sources we know what brings that name.

 

No.

 

What is returned is not relevant. I've been saying this since day one.

 

If someone thinks it is, it is because that person wants to apply logic to it ( i.e. if name = "hd51" then... ), and if that is the case, that person has missed the point of this exercise, which is to remove dependencies (and this if clearly creates a dependency).

 

So please explain why this is needed.

 

e.g. /proc/.../display would output one of the following...

'', 'textlcd', '7segment', 'bwlcd96', 'bwlcd128', 'bwlcd140', 'bwlcd255', 'colorlcd', 'colorlcd128',
'colorlcd220', 'colorlcd390', 'colorlcd400', 'colorlcd480', 'colorlcd720', 'colorlcd800'

Where would we be if every team just outputted any data it liked? Without 100% consistency the project is dead.

[LraiZer]

As i understand this, any feature that is an actual hardware capable api spec for which logic is allowed to be applied should be in path /proc/hal/*

 

Any results returned in the api spec that are allowed to be variable between images can only to be used for info/display purposes. No logic is allowed be be applied (eg. api spec for model simply asks to return a 16 byte max string). These should be in a sub info path /proc/hal/info/* 

 

returns api spec variable: (no logic allowed, info/display purposed only!)

 

/proc/hal/info/name

/proc/hal/info/model

/proc/hal/info/brand

/proc/hal/info/distro

 

returns api spec as defined: (logic allowed!)

 

/proc/hal/kernel

/proc/hal/python

/proc/hal/architecture

/proc/hal/socfamily

[WanWizard]

The whole project is pointless if the returned data is not identical in all distros. By the sound of it you seem to think this data is to be used for decorating the image, not for logic.

 

It seems to me that you have totally missed the point of this entire exercise.

 

If there is any need to use if name == "hd51" then, then the API is missing information. Please give an example where you feel you need this, and I'll prove you wrong.
 

[WanWizard]

Where would we be if every team just outputted any data it liked? Without 100% consistency the project is dead.

 

You also seem to miss the difference between "random" string data, and a specific value or value list.

 

Obviously, a list of values should follow the spec, like boolean and numeric values should.

 

But name is just a display string, and therefor its value is of no importance. The spec should just define it as "a string". There is no reason to apply logic to a field like "name".

[littlesat]

Why do we need Hal?