772 replies to this topic

[WanWizard]

I made a proposal to address that, to create proc nodes for all installed images.

[IanSav]

Hi Huevos,

 

 

Hi,

 

The questions about where to store the data seemed to be resolved by having /proc entries such that shell, C++ and Python could all equally access the data from /proc.  We now seem to have gone back to the beginning and trying to work out where to store the data so it is available at all layers.  What was wrong with the /proc proposal?

 

Regards,

Ian.

 

It can only be accessed in a running image.

 

That should not be an issue.  The kernel code could extract data from other slots and return the data to the currently running image.

 

Mind you, I am not sure why all the interest in other slots.  Most of the data about which we are talking is data from and about the build/image we are currently running.  A significant amount of the information is about the hardware available, this will be exactly the same for all the slots.  Apart from the MultiBoot system what does information about another slot matter to the current slot and the code currently running?

 

Regards,

Ian.

[littlesat]

Procs from slots I think not a good idea (except for it has structure).... then better to have a image description file on a dedicated place in an image.... and then just the description text that should be shown one to one (so the image decide what will be shown) simple to implement and simple to parse by the Multiboot code.

Edited by littlesat, 5 December 2020 - 08:52.

[WanWizard]

Why is a uniform interface not a good idea, and data in two places is?

 

Remember, every slot can be active and inactive, so every slot needs BOTH a binary that creates the proc nodes, AND that file (or whatever different solution).

 

ihmo maintaining the same data in two places is a bad idea.

[littlesat]

An uniform interface is a good idea.... but doing it via procs?
The goal is to give more info about an image in a slot... Why not just create a file that can be parsed and show that info as is? Simple and uniform.
I just have the ideas that an image could show here info they want, which might also include a short release note or so instead.

-another suggestion-
Maybe also add the same info in the json image list (to show it when you select and info to flash in online flash) I’m afraid this might be the next suggestion and logical idea. and maybe also add foreign images to that json file (maybe when we add vix or openatv there as example they may add us as well and maybe also consider to use json instead of parsing a website)

Edited by littlesat, 6 December 2020 - 07:58.

[IanSav]

Hi,

 

One of the very early suggestions was to have a simple text file for all the information and that was rejected.  I don't know why it was rejected as that is what is now being suggested again, this time by the people who initially rejected it.

 

This is confusing and doing my head in.

 

Regards,

Ian.

[WanWizard]

I don't know what Littlesat's facination is with "a seperate solution for non-active partitions by using a file", and I also don't know what the difference is between opening a file and opening a proc node, and why the first would be simpler.

 

The big advantage of proc nodes (for me) is that they are immutable, there is no need for parsing, and they are easily accessible from C, Python and Bash, in a uniform way. And the entire community is used to reading proc nodes to determine box info, making the changes needed in the code to switch to the new system simpler.

 

My point was that if you have a "boxinfo.so" that creates proc nodes, and if you need to mount the inactive partitions to check what is present there, it is easy to just run the "boxinfo.so" you find in that partition, and pass it the slot number it was found in.

 

Instead of trying to come up with some other solution.

[Huevos]

I don't know what Littlesat's facination is with "a seperate solution for non-active partitions by using a file", and I also don't know what the difference is between opening a file and opening a proc node, and why the first would be simpler.

 

The big advantage of proc nodes (for me) is that they are immutable, there is no need for parsing, and they are easily accessible from C, Python and Bash, in a uniform way. And the entire community is used to reading proc nodes to determine box info, making the changes needed in the code to switch to the new system simpler.

 

My point was that if you have a "boxinfo.so" that creates proc nodes, and if you need to mount the inactive partitions to check what is present there, it is easy to just run the "boxinfo.so" you find in that partition, and pass it the slot number it was found in.

 

Instead of trying to come up with some other solution.

No. The info.so file does not have cross compatibility between P2 and P3. It has to be used by the Python version it was compiled for. That is why we are using a .py file to return image details to our multiboot code..

[littlesat]

One of the very early suggestions was to have a simple text file for all the information and that was rejected.

That time it was different. I suggest now a simple 'plain' text file that includes the information an image want to show there...

[WanWizard]

No. The info.so file does not have cross compatibility between P2 and P3. It has to be used by the Python version it was compiled for. That is why we are using a .py file to return image details to our multiboot code..

 

No idea what you are talking about, I was talking about the so that creates the proc nodes. That is a standalone so, it has not interface with anything else?
 

[Huevos]

 

No. The info.so file does not have cross compatibility between P2 and P3. It has to be used by the Python version it was compiled for. That is why we are using a .py file to return image details to our multiboot code..

 

No idea what you are talking about, I was talking about the so that creates the proc nodes. That is a standalone so, it has not interface with anything else?
 

 

Branding is a .so file imported by Python.

[Huevos]

 

One of the very early suggestions was to have a simple text file for all the information and that was rejected.

 

That time it was different. I suggest now a simple 'plain' text file that includes the information an image want to show there...

 

+1.

 

Why make things complicated? Making things complicated is just a barrier to getting this done.

Edited by Huevos, 6 December 2020 - 19:25.

[littlesat]

Branding is a .so file imported by Python.
-> what is wrong to make it py imported (swigged) by cpp..? And make the python module such a way that it can also be called via shell with attribute.

[Huevos]

What is wrong with a simple text file and allow each team to decide how to read it?

[WanWizard]

Branding is a .so file imported by Python.

 

So? The discussion was about the so that should create the proc nodes, that has nothing to do with any existing solution?
 

[WanWizard]

What is wrong with a simple text file and allow each team to decide how to read it?

 

What is wrong with a proc node that anyone can read? That requires no parsing, and is therefore a lot easier to process in Bash, Python and C? And is immutable and therefore trustworthy, which a file is definitely not, as it can be altered, it can be removed, it can be overwritten by a restore, ....

[Persian Prince]

 

What is wrong with a simple text file and allow each team to decide how to read it?

 

What is wrong with a proc node that anyone can read? That requires no parsing, and is therefore a lot easier to process in Bash, Python and C? And is immutable and therefore trustworthy, which a file is definitely not, as it can be altered, it can be removed, it can be overwritten by a restore, ....

 

https://github.com/O...envision-module now compiles even for dm800 (kernel 2.6.18) so it works for all, I hope I can come up with something good for multiboot detection.

[WanWizard]

The proposal was to be able to pass a optional slot number to the binary.

 

If the slot number is not given, create the nodes in /proc/<root>/current.

If a slot number is given, and it is not equal to the current slot, create the nodes in /proc/<root>/slot/<number>

If a slot number is given, and it is equal to the current slot, make /proc/<root>/slot/<number> a symlink to /proc/<root>/current.

 

After boot, only /proc/<root>/current will exist. Most of the time, it is all the information you need, from the currently running image.

 

As soon as the code needs info about the different slots of a multiboot box, it checks if /proc/<root>/slot exists. If not, fetch the list of slots and the locations, itterate over the slots, mount a partiton if needed, run the binary you find there with the slot number as argument, which will create the proc nodes for that multiboot slot.

 

This should be encapsulated in a Python function or class method, so you can simply call a getter to get the slot information (which can return false or an empty list/dict if it is not a multiboot box). which would run the actual fetch process on first call.

 

This given you access to ALL information defined on the image, in one go, in a reliable immutable way, not related to file systems, files, user and backup/restore issues.

 

As soon as "the governing body" decides to release a new version of the spec to introduce new nodes, it happens for all images, and the new data will be available automatically, without having the change code that parses files, etc.

[littlesat]

There are two things here.... some comments multiboot can show in a description field (under the pig) and something that gives technical info about the hardware the image is running on (the proc or so aka branding stuff). I would say keep them apart.

Edited by littlesat, 6 December 2020 - 23:08.

[Huevos]

 

What is wrong with a simple text file and allow each team to decide how to read it?

 

What is wrong with a proc node that anyone can read? That requires no parsing, and is therefore a lot easier to process in Bash, Python and C? And is immutable and therefore trustworthy, which a file is definitely not, as it can be altered, it can be removed, it can be overwritten by a restore, ....

 

What is wrong with keeping things simple?

 

Any file can get removed. pyo files for example. What is so special about this file that means it must be a proc? I thought you had already said implementation was up to each team.

Edited by Huevos, 6 December 2020 - 23:09.