772 replies to this topic

[littlesat]

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

Edited by littlesat, 14 December 2020 - 08:58.

[IanSav]

Hi Littlesat,

 

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

 

You have just brought this thread back to the start.  This was suggested in the first place as the "simple" option.  It was rejected because the settings were mutable.  You are now proposing two different sources for the information.  This was also rejected as problematic.  This looping back over already rejected ideas is just wasting time and distracting everyone from making real progress.

 

If you want a simple text file as a single source of the information then I am okay with that concept.  Others were not.  Do people want to revisit a single text file as the repository of all this information?

 

Regards,

Ian.

[Persian Prince]

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

 

Try it yourself, try it on Zgemma HiSilicon for example and you'll understand the problems.

 

We should avoid existing folders and to be more specific we should avoid existing folders created by main STB drivers.

[littlesat]

Procs are not mutable...
The multiboot solution are.... but that has somehow added value as a user can change a description....

[Huevos]

Procs are not mutable...
The multiboot solution are.... but that has somehow added value as a user can change a description....

The user can't change the output of the procs or modinfo. That would require a rebuild.

[Huevos]

Hi Littlesat,

 

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

 

You have just brought this thread back to the start.  This was suggested in the first place as the "simple" option.  It was rejected because the settings were mutable.  You are now proposing two different sources for the information.  This was also rejected as problematic.  This looping back over already rejected ideas is just wasting time and distracting everyone from making real progress.

 

If you want a simple text file as a single source of the information then I am okay with that concept.  Others were not.  Do people want to revisit a single text file as the repository of all this information?

 

Regards,

Ian.

No... we already have an immutable, it's called box branding. Why would we ever consider flat files? How would that be a forwards step compared to what we have used for 10 years.

[Huevos]

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

To me this looks like a good idea. i.e.

 

/proc/stb/boxtype

/proc/stb/machine

/proc/stb/machinebuild

/proc/stb/hdmiin

/proc/stb/wol

etc

[IanSav]

Hello Huevos,

 

 

No... we already have an immutable, it's called box branding. Why would we ever consider flat files? How would that be a forwards step compared to what we have used for 10 years.

 

 

That is not a global solution and it has already been rejected by OpenPLi.  There are also issues with boxbranding that don't make it a better solution over Persian Prince's proposal.  Why keep pushing the boxbranding agenda?

 

Regards,

Ian.

[IanSav]

Hello Huevos,

 

 

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

To me this looks like a good idea. i.e.

 

/proc/stb/boxtype

/proc/stb/machine

/proc/stb/machinebuild

/proc/stb/hdmiin

/proc/stb/wol

etc

 

It was mentioned that entries in this tree *might* clash with entries provided by manufacturers.  I am told that the entries created by manufacturers are not always correct or reliable.  I think it is better to stay clear of directories used by others.

 

Regards,

Ian.

[Persian Prince]

 

Just a suggestion... put the complete 'new' stuff to the already existing proc folder /proc/stb/info.... it already exists... but can now get 'more info'... So just extend the existing - not create/hack a new one, where we somehow 'never' can agree a good name for (as there is already a folder for it why create a different?)

+

For multi-boot it would be fine to have a file in /etc that gives and image description (short) in the first row and an extended in the following rows.

To me this looks like a good idea. i.e.

 

/proc/stb/boxtype

/proc/stb/machine

/proc/stb/machinebuild

/proc/stb/hdmiin

/proc/stb/wol

etc

 

As I said we should avoid existing folders and to be more specific we should avoid existing folders created by main STB drivers.

 

You could check what will happen on Zgemma HiSilicon for example.

[Persian Prince]

compiledate proc added: https://github.com/O...6f45ad4bdacadfb

 

This will give us a static date time, as the module compiles each time image gets compiled it's the correct date for image compile date.

 

And I'm sad to see all you care in your fork is NAMES and names all the time: https://github.com/H...c5545c58d934a95

 

And how OE-A is the "PKG_MAINTAINER" only GOD knows.

[Huevos]

Anything I do in my fork is not relevant outside my own build.

If you don't want to use /proc/stb can we please use /proc/hardware and /proc/firmware.

[Persian Prince]

Anything I do in my fork is not relevant outside my own build.

If you don't want to use /proc/stb can we please use /proc/hardware and /proc/firmware.

 

We should not use existing folders in /proc so "stb" is out of the list, are "firmware" and "hardware" empty and available in all drivers?

 

Those are suspicious words so we should care.

 

I think /proc/enigma is fine although it's not general and we may use the proc files in other programs like Kodi later but we're enigma2 developers so the kernel is the reflection of our work.

[Huevos]

BTW, I didn't realise this project was only for non-oe-alliance teams. So no point me continuing with it further.

[Persian Prince]

BTW, I didn't realise this project was only for non-oe-alliance teams. So no point me continuing with it further.

 

Who said that? But do you see any OE-A team here except ViX? Why I should I care about any other OE-A team when they don't care about this matter at all?

 

And please save the lecture that they're monitoring this topic which is a joke to me.

 

We respect ViX devs as they're great, supportive, cooperative and friendly so it's for you all not just non-oe-a teams.

 

Final API is not even out and this is a prototype that's all.

[littlesat]

To me this looks like a good idea. i.e.

/proc/stb/boxtype
/proc/stb/machine
/proc/stb/machinebuild
/proc/stb/hdmiin
/proc/stb/wol

Nope please all in /proc/stb/info

Edited by littlesat, 14 December 2020 - 19:59.

[WanWizard]

You also need to be careful with module loading order, what happens if /proc/stb doesn't exist because the box drivers haven't been loaded yet (takes 30s on a VU+ 4K box)...

 

I still think it is a very bad idea to re-use an existing proc node. Like PP wrote, we have to make sure it is unique, and available on every box.

[Persian Prince]

To me this looks like a good idea. i.e.

/proc/stb/boxtype
/proc/stb/machine
/proc/stb/machinebuild
/proc/stb/hdmiin
/proc/stb/wol

Nope please all in /proc/stb/info

 

Why don't you test it yourself?

 

Fork and change it to what you need then install it on ARM HiSilicon Zgemma and similars.

 

We tested that before so we won't go for it again.

[Persian Prince]

You also need to be careful with module loading order, what happens if /proc/stb doesn't exist because the box drivers haven't been loaded yet (takes 30s on a VU+ 4K box)...

 

I still think it is a very bad idea to re-use an existing proc node. Like PP wrote, we have to make sure it is unique, and available on every box.

 

That's what I'm trying to say, no matter what order you use the result is not good.

[Huevos]

You also need to be careful with module loading order, what happens if /proc/stb doesn't exist because the box drivers haven't been loaded yet (takes 30s on a VU+ 4K box)...

 

I still think it is a very bad idea to re-use an existing proc node. Like PP wrote, we have to make sure it is unique, and available on every box.

Are you saying the kernel is not fully running when enigma loads?