Redesign plugins logic to work without plugins.cfg file

[chivakker]

Remove plugins.cfg .

When a new plugin is created by a third party, it should be able to register to the dispatcher for it to be loaded, instead of dispatcher reading a file.

[dvrogozh]

How you propose a registration mechanism? as of now file is exactly to let dispatcher know about plugins available on the system.

[miguelinux]

The idea here is to have a software that complies a stateless OS (https://clearlinux.org/features/stateless). One example is systemd.

Configuration files are read from directories in /etc/, /run/, and /usr/lib/, in order of precedence. 
Each configuration file in these configuration directories shall be named in the style of filename.conf. 
Files in /etc/ override files with the same name in /run/ and /usr/lib/. 
Files in /run/ override files with the same name in /usr/lib/.

Packages should install their configuration files in /usr/lib/. Files in /etc/ are reserved for the local
administrator, who may use this logic to override the configuration files installed by vendor packages. 
All configuration files are sorted by their filename in lexicographic order, regardless of which of the 
directories they reside in. If multiple files specify the same option, the entry in the file with the 
lexicographically latest name will take precedence. It is recommended to prefix all filenames 
with a two-digit number and a dash, to simplify the ordering of the files.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended 
way is to place a symlink to  /dev/null in the configuration directory in /etc/, with the same filename 
as the vendor configuration file. If the vendor configuration file is included in the initrd image, the 
image has to be regenerated.

[dvrogozh]

@miguelinux Originally we were installing plugins.cfg file to /usr/lib64/mfx/ and changed the location to /usr/share/mfx per request from @chivakker for Clear Linux... What you describe is how we should correctly place and handle our configuration file. Ok, this makes sense, but I thought the request is to completely dispose from the configuration file...

If we will keep our configuration file, do I understand correctly that the following is expected from us:

1. Rename it to plugins.conf
2. Place it in /usr/lib64/mfx (I guess you mean /usr/lib64 instead of /usr/lib in your message)
3. Add recognition of the /run/mfx/plugings.conf in a preference to /usr/lib64/mfx/plugins.conf
4. Add recognition of the /etc/plugings.conf in a preference to both /run/mfx/plugings.conf and /usr/lib64/mfx/plugins.conf

[miguelinux]

@dvrogozh yes, but I will follow as @chivakker said

1. Rename it to plugins.conf
2. Place it in /usr/share/mfx
3. Add recognition of the /run/mfx/plugings.conf in a preference to /usr/share/mfx/plugins.conf
4. Add recognition of the /etc/mfx/plugings.conf in a preference to both /run/mfx/plugings.conf and /usr/share/mfx/plugins.conf

/usr/share usually is used for not binaries files, and your config file path would be mfx/plugins.conf, located at

• /usr/share
• /run
• /etc

[bryteise]

@miguelinux My understanding is that the configuration file should not exist because the plugins are not something the end system administrator would be tweaking (which seems odd but I think that's what I understood from @chivakker due to these not being exactly plugins in how Linux would normally handle them). Looking to understand more though =).

[miguelinux]

Ok, try to auto-discover the plugins instead of search from a config file.

Sounds better.

[chivakker]

@dvrogozh do you have any update on this.

[onabiull]

Hello, Unfortunately we don't have any short or mid-term plans to make any radical changes to Media SDK. Most development focus shifted to oneVPL Runtime. But considering original ask I could think about two approaches.

1. Upgrade to oneVPL GPU runtime - it intentionally drop plugin support. No more plugins.cfg. Customers still shall be able to implement their GPU Runtime implementations according to spec.
2. Load plugins directly in the app (1:N LA, dlload, CreatePlugin(), MFXVideoUSER_Register(), ) or do not load them at all. Technically most of the plugins already a stub, which merely redirect calls inside Media SDK runtime. We provide them as a backward compatibility layer which makes older versions of Dispatcher happy.

Registration-based method already supported by plugin API. Third-party are not expected to modify plugins.cfg to integrate their plugins. That file used to serve a a kind of registry. While it is possible to re-configure dynamic dispatcher to look for plugins.cfg in any OSV-configured location, it would potentially break applications which linked to dispatcher statically and does not expect location change.