| /openbmc/obmc-console/subprojects/ |
| H A D | .clang-tidy | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | iniparser.wrap | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| /openbmc/obmc-console/ |
| H A D | config-internal.h | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | .gitignore | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | .clang-tidy | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | config.h | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | meson.build | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | tty-handler.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | console-dbus.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | config.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | console-client.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | log-handler.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | console-server.h | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | console-server.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| /openbmc/obmc-console/subprojects/packagefiles/iniparser/ |
| H A D | meson.build | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| /openbmc/obmc-console/test/ |
| H A D | test-config-parse.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | test-config-resolve-console-id.c | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|
| H A D | meson.build | 1e04f449 Wed Jun 12 09:35:58 CDT 2024 Alexander Hansen <alexander.hansen@9elements.com> use iniparser dependency for config file parsing
For the config file, we do not need the custom handwritten parser.
Thanks to Andrew for this command, we can now search for an alternative
$ git grep -lw INI -- :/:*.bb
meta-openembedded/meta-oe/recipes-support/inih/libinih_58.bb
meta-openembedded/meta-oe/recipes-support/iniparser/iniparser_4.1.bb
meta-openembedded/meta-oe/recipes-support/minini/minini_1.2.b.bb
poky/meta/recipes-devtools/python/python3-iniconfig_2.0.0.bb
poky/meta/recipes-devtools/python/python3-iniparse_0.5.bb
For the ini parser we have following requirements
- small API
- easy to use
- compiles fast
- has tests, examples, docs
- support for sections
- minini [1]
can be dropped from the list since it also supports colon
':' instead of '=' for separating key and value, creating 2 ways of
doing something. This makes it harder to swap out the ini parser in
the future.
- libinih [2]
uses SAX-style parsing of .ini files and thus does not provide
a DOM of the .ini. This is a break from the previous parser which
stored everything in struct config. To use this library would require
to create a struct to store all the possible configuration, then fill
that struct in one pass. Essentially wrapping that library to have
DOM capability. That would be possible, but not ideal. libinih is also
highly configurable with lots of config options.
- iniparser [3]
has all the required features and stores the results of its
parsing for later use. It is a seamless upgrade from the previous
parser. The call sites do not have to be modified and we can read the
config as before. A downside is that we have to provide our own wrap
file.
For our purposes, iniparser is a good choice.
Using this dependency allows us to drop the custom parser and all the
tests that go along with it.
If sections are required in future config files, iniparser can also
support that.
References:
[1] https://github.com/compuphase/minIni
[2] https://github.com/benhoyt/inih
[3] https://gitlab.com/iniparser/iniparser
Change-Id: Ie2b57171ec1f8cb6b1b80ca1d9e6c112bedc1195
Signed-off-by: Alexander Hansen <alexander.hansen@9elements.com>
|