772 replies to this topic

[WanWizard]

So you generate the code based on bitbake variables?

 

Not what I had in mind for OpenPLi, but the prnciple fits what I proposed. A decoupling of the interface (proc entries in your case) from the source of the data.

 

Not sure yet if I like the solution of proc entries yet, but it is a million times better then the alternative .

[Persian Prince]

So you generate the code based on bitbake variables?

 

Not what I had in mind for OpenPLi, but the prnciple fits what I proposed. A decoupling of the interface (proc entries in your case) from the source of the data.

 

Not sure yet if I like the solution of proc entries yet, but it is a million times better then the alternative .

 

Yes some of them are bitbake original variables and some are our specific things.

 

For PLi we can reduce the code and have less variables.

 

Also as it's updated/generated each time it could be used for image version/time something you always have problem with:

 

/proc/openpli/imageversion

/proc/openpli/imagedate

/proc/openpli/compiledate

 

or anything you like

 

You can get rid of https://github.com/O...s/rc_models.cfg too as our module can't go rmmod.

Edited by Persian Prince, 2 December 2020 - 00:13.

[WanWizard]

For PLi we can reduce the code and have less variables.

 

It is an absolute prerequisite that every image uses exactly the same nodes, and is in agreement about exactly what (format of) data each node returns. If not, then the entire setup is useless.

 

/proc/openpli/imageversion

/proc/openpli/imagedate

/proc/openpli/compiledate

 

And for the same reason, it needs a generic name, Code needs to know which proc node to read, not to have to lookup which image is running first...

 

You can get rid of https://github.com/O...s/rc_models.cfg too as our module can't go rmmod.

 

There is a lot that can be removed.
 

[IanSav]

Hi Guys,

I am still following this topic but can't do much from my hospital bed. I hope to be home soon.

Regards Ian.

[Huevos]

 

So you generate the code based on bitbake variables?

 

Not what I had in mind for OpenPLi, but the prnciple fits what I proposed. A decoupling of the interface (proc entries in your case) from the source of the data.

 

Not sure yet if I like the solution of proc entries yet, but it is a million times better then the alternative .

 

Yes some of them are bitbake original variables and some are our specific things.

 

So how is that supposed to work? PLi doesn't have environmental variables.

 

Also why have you gone off and done this by yourself? Why is it not an oe-alliance project? However do you expect to get other teams onboard.

 

Looks like a remake of the model info file that OpenATV and OpenViX already have built in.

Edited by Huevos, 2 December 2020 - 02:37.

[Persian Prince]

 

For PLi we can reduce the code and have less variables.

 

It is an absolute prerequisite that every image uses exactly the same nodes, and is in agreement about exactly what (format of) data each node returns. If not, then the entire setup is useless.

 

/proc/openpli/imageversion

/proc/openpli/imagedate

/proc/openpli/compiledate

 

And for the same reason, it needs a generic name, Code needs to know which proc node to read, not to have to lookup which image is running first...

 

You can get rid of https://github.com/O...s/rc_models.cfg too as our module can't go rmmod.

 

There is a lot that can be removed.
 

 

 

In my opinion if a general proc returns the image name or distro first isn't bad like:

 

/proc/enigma2/distro

 

Then some "has-to-exist" proc files:

 

/proc/distro/proc1

~

/proc/distro/proc10

 

And the rest is optional and "not-general" for specific "off-topic" management:

 

/proc/distro/proc11

~

/proc/distro/procn

 

It won't bite

[Persian Prince]

 

 

So you generate the code based on bitbake variables?

 

Not what I had in mind for OpenPLi, but the prnciple fits what I proposed. A decoupling of the interface (proc entries in your case) from the source of the data.

 

Not sure yet if I like the solution of proc entries yet, but it is a million times better then the alternative .

 

Yes some of them are bitbake original variables and some are our specific things.

 

So how is that supposed to work? PLi doesn't have environmental variables.

 

Also why have you gone off and done this by yourself? Why is it not an oe-alliance project? However do you expect to get other teams onboard.

 

Looks like a remake of the model info file that OpenATV and OpenViX already have built in.

 

 

PLi could have what's needed and decide about it (I can sen them the required PRs on github), don't get me wrong here but "I don't care" which solution would be the choosen one I just wanted to show that this is another possibility and we're using it for real.

 

The thing is I had to change the old version of Backup Suite again (and again) in order to work on PLi because Zgemma is ruining everything but if you check our branch of Backup Suite there's no need for a change as it's futuristic.

 

The new module we're using could be a demonstration for PLi that an alternative exists already and not just a fairy tale.

 

I'm a man of action and can't just sit read about 20 pages and see "nothing" instead I did "something", it's not important if the repo isn't on OE-A as anybody could be invited to the "final solution" repo on the "final-choosen-public-git".

 

Currently I'm improving our module code to run on kernel 2.6.18 (dm800) ~ kernel 5.9.x (edision 4K).

Edited by Persian Prince, 2 December 2020 - 05:21.

[Persian Prince]

Hi Guys,

I am still following this topic but can't do much from my hospital bed. I hope to be home soon.

Regards Ian.

 

Oh sorry to hear that my friend but happy to hear you're getting better.

 

May the force be with you

[littlesat]

Can you put an example from the resulting content of the proc here? Maybe better to have one proc called branding that contains all ‘fixed’ values....
I would consider one proc with consistent labels.... that can be readed in e2 at once and the image builder can choose how to read it, store it etc in enigma2.... it only gets box name and those stuff from the proc...

Edited by littlesat, 2 December 2020 - 07:43.

[Frenske]

@Iansav.

 

I hope you get well again soon and that you can fully recover at home quickly.

[Persian Prince]

Can you put an example from the resulting content of the proc here? Maybe better to have one proc called branding that contains all ‘fixed’ values....
I would consider one proc with consistent labels.... that can be readed in e2 at once and the image builder can choose how to read it, store it etc in enigma2.... it only gets box name and those stuff from the proc...

 

Yes sure but I'm not home right now.

 

I'm against one thing like 100% because any kind of problem in one proc file like anything I don't know you name it will be disaster of falling everything.

[littlesat]

Just call it boxbranding to be in line of the code oe-a made.... note in addition that it would also be helpfull for plugins that cross image the implementation is the same in e2....!to avoid this proc is parsed multiple times.

[WanWizard]

It has nothing do to with branding, so "boxinfo" might be a more generic name.

 

And indeed, it is a bit silly to first get the distro name, and then use that to read the proc nodes, the whole excercise is to make something generic for all images.

 

@Huevos,

 

As I have been trying to explain from the beginning, where we get the data from, and how we organise it, is our problem. I am fully aware that we don't have that data ready at the moment, since we use runtime detection. But how we are going to solve it is not relevant, the only relevant bit is that you should be able to rely on the fact that "/proc/boxinfo/somedata" exists.

[littlesat]

Then boxinfo fine for me! And why not in one proc file so you can read the stuff in one run instead of fragments.

Edited by littlesat, 2 December 2020 - 12:29.

[WanWizard]

Because "we" are not the only ones interested in this data. It must also be available for plugins, bash scripts, C code, etc.

 

If that would not have been the case, it would have been easier to skip the proc nodes all together, and directly generate a Python constants file in Enigma.

[IanSav]

Hi Frenske and Persian Prince,

 

@Iansav.

 

I hope you get well again soon and that you can fully recover at home quickly.

 

Thank you for your well wishes.  The first operation was a success.  There are two more to come (2 weeks apart).  The prognosis is very good and a full recovery is expected.  It will take some time for me to get up to speed as I won't feel right until the job is complete.  I intend to catch up with Enigma2 and respond as much as possible.

 

This was a case of feeling unwell and calling a doctor only to be sent straight to hospital for one suspected bad thing and they discover the actual cause was something very different and very bad in other ways.  The symptoms did not at all match the cause.  Almost by accident they found the real issue as part of the CT scan looking for the original suspicions.

 

Regards,

Ian.

[Frenske]

Let’s all for a full recovery. Thumbs up.

[Persian Prince]

Then boxinfo fine for me! And why not in one proc file so you can read the stuff in one run instead of fragments.

 

Then a simple https://github.com/o...e-identifier.bb should be fine.

[Huevos]

It has nothing do to with branding, so "boxinfo" might be a more generic name.

 

And indeed, it is a bit silly to first get the distro name, and then use that to read the proc nodes, the whole excercise is to make something generic for all images.

 

@Huevos,

 

As I have been trying to explain from the beginning, where we get the data from, and how we organise it, is our problem. I am fully aware that we don't have that data ready at the moment, since we use runtime detection. But how we are going to solve it is not relevant, the only relevant bit is that you should be able to rely on the fact that "/proc/boxinfo/somedata" exists.

Yes I know, which is why it is pointless posting code that requires those variables.

[WanWizard]

I wonder what is the correct way forward then?

 

I suggested to remain abstract in this discussion, and only describe and document the API (which is this case is a list of proc nodes with their name and return value specification), and that was rejected. Now a working example is posted, and that is rejected because "it is too specific"?

 

I have no issue (in that respect) with what was posted, as I wrote several times before, the question where the data comes from is irrelevant for the implementation, every image builder can come up with their own version that suits their environment, as long as that implementation doesn't violate the API specs.

 

All you need to know as a consumer of the API is that (in this case) proc node /proc/boxinfo/somedata exists, and returns data that conforms to the written specification.