772 replies to this topic

[littlesat]

As far I know our boxnames are coming from the MANUFACTURER’s BSP layer...

[betacentauri]

„ if getBoxName() == "sf8008":“

Especially this is what we want to get rid off. With a proper box branding you don’t need that.

[WanWizard]

Exactly.

 

If you need to use logic on information returned, you're doing something wrong, and/or the abstraction layer doesn't give you the required information (which means the API needs updating).

[IanSav]

Hi Betacentauri,

 

„ if getBoxName() == "sf8008":“

Especially this is what we want to get rid off. With a proper box branding you don’t need that.

 

Here! Here!

 

While something like this may be required somewhere I think it should be *VERY* hard to justify this code anywhere.  Certainly the operation of the firmware should *NEVER* be dependent on code like this.

 

Regards,

Ian.

[Huevos]

„ if getBoxName() == "sf8008":“

Especially this is what we want to get rid off. With a proper box branding you don’t need that.

So how do I get the filename of the blindscan binary because it is different on every piece of hardware?

 

https://github.com/o...in.py#L899-L912

[littlesat]

You should not need the box name or branding name in blindscan in the first place... because that is already wrong!!! Actually when a binary is required just and only the correct one should be installed...(I suggest this is the scructured solution... why do we need the binary from box x y z a b and c on all boxes?!)
On my question why does a plugin need branding I still do not get an answer....

Edited by littlesat, 20 July 2020 - 08:44.

[Persian Prince]

 

„ if getBoxName() == "sf8008":“

Especially this is what we want to get rid off. With a proper box branding you don’t need that.

So how do I get the filename of the blindscan binary because it is different on every piece of hardware?

 

https://github.com/o...in.py#L899-L912

 

Simple:

 

Just provide blindscan binary with this name in all bsps: "blindscan"

 

We could install the correct file with bitbake or add another variable in conf/inc: BLINDSCAN_NAME

 

then read it in branding

[Persian Prince]

Another example:

 

https://github.com/o...ndscan-utils.bb

 

SRC_URI = "file://dags_blindscan"

BLINDSCAN_NAME = "dags_blindscan"

 

and in https://github.com/o...branding-module we should have

 

getBlindscanBinary() which gives us "dags_blindscan"

 

[Huevos]

LOL, are you really suggesting blindscan filenames should be moved into branding module.

[WTE]

 

We could install the correct file with bitbake or add another variable in conf/inc: BLINDSCAN_NAME

 

 

 

The file is not the issue but many boxes didn't work or had issues with the blindscan plugin. The problems are often fixed in plugins like a nice example shown good in the blindscan plugin. The problems should been fix by manufactures.

 

The BSP layer can easily say build blindscan-version1 for manufactures which have specific issues or when the manufacture solves all issues it can use the original blindscan

[Persian Prince]

LOL, are you really suggesting blindscan filenames should be moved into branding module.

As we have our own fork of branding module, you'll see soon how I'm going to use it

[littlesat]

Or just put a merge request and wait (a bit)... indeed the blindscan is a big example how it should not be done. The requirement for a branding module is actually a dirty work a round. Maybe triggered to the ones that last dictate the code by the manufacturers..... better do not offer it and ask the manufacturers politely to adapt.

Edited by littlesat, 20 July 2020 - 10:27.

[WanWizard]

LOL, are you really suggesting blindscan filenames should be moved into branding module.

 

EVERYTHING hardware dependent should be in the branding module, NOTHING hardware dependent should be in the image source... This has been my point from the beginning.

 

The requirement for a branding module is actually a dirty work a round. Maybe triggered to the ones that last dictate the code by the manufacturers..... better do not offer it and ask the manufacturers politely to adapt.

 

What have you been smoking?

[littlesat]

�.....

[Huevos]

 

 

We could install the correct file with bitbake or add another variable in conf/inc: BLINDSCAN_NAME

 

 

 

The file is not the issue but many boxes didn't work or had issues with the blindscan plugin. The problems are often fixed in plugins like a nice example shown good in the blindscan plugin. The problems should been fix by manufactures.

 

The BSP layer can easily say build blindscan-version1 for manufactures which have specific issues or when the manufacture solves all issues it can use the original blindscan

 

Yes of course the manufacturers are to blame. I haven't suggested otherwise. But here we are... do we just deny users features because the manufacturers only care about themselves...

 

And it can't be done in branding because the binary is selected based on box AND tuner. If it was just box the wouldn't be a problem.

 

But anyway that is just one example.

[littlesat]

By ‘just’ implementing a work-a-round the manufacturers ate also totally not motivated to it right... it is not ‘just’ about helping the users.... it is also strive to keep some structure.... where is the balance?

Edited by littlesat, 20 July 2020 - 18:23.

[Huevos]

By ‘just’ implementing a work-a-round the manufacturers ate also totally not motivated to it right... it is not ‘just’ about helping the users.... it is also strive to keep some structure.... where is the balance?

Do you really believe not providing a workaround will motivate a manufacturer to do the right thing? Or will it just motivate users to switch image to one that does provide a workaround? And if you lose your users what manufacturer is going to be motivated to provide anything?

 

"Where is the balance?"... How long is a piece of string? I guess you have to look at each individual case and decide.

[littlesat]

Yep... it is extreem simple.... when all images are doing this right they have to. it is oe-a that starts to alllow this. And now you see where you are.
As you can see with eg sf8008 multiboot as example you see this is a better way to go. Now also on this box it is compatible with standaard code plus an sd is not mandatory anymore. Just swallow everything from a manufacturer and accepting work a rounds is not the way to go!
From the beginning in blindscan the if box x use binary a and derive to code h stuff was not acceptable........ may I answer a plugin needs branding to satisfy if box x then do y stuff....
This is not only about satisfy users, but also to get the ‘engine’ behind it right. And also users notify manufacturers to get their stuff right when an image does not support something right. It sounds in this community some easily accept work a rounds in the name to satisfy users. At the end you end up with code witth lots of exceptions and complications. Here blindscan is a big example....

Edited by littlesat, 21 July 2020 - 06:52.

[Persian Prince]

This is how I did it for Blindscan: https://github.com/O...ac60cb98404f247

 

Waiting to see the test reports.

[littlesat]

That really hurts..... if box in (a,b,c,d,e,f,g) or model in (q,r,s) then do y all over the place...  And then for DMM a separate py file...  And here it does not stop... I see also things like when tuner in slot x then give message it does not work... and then also do blingscan except when tuner has type z then use different binary...

 

Actually the situation from this blindscan stuff was something the community should not except in the first place! This is THE example how it should not be done. And the most mean thing here is that it might now be too late to fix it!

 

At the end the users might have blindscan support on a lot of boxes. But the DEVs and maintenance of the plugin may become a nightmare. I suggest this is out-of-balance!

Edited by littlesat, 21 July 2020 - 11:01.