From: Daniel Wagner <wagi@monom.org>
To: Piotr Karbowski <piotr.karbowski@protonmail.ch>
Cc: connman@lists.linux.dev
Subject: Re: Unification to connman configuration? Now it 3 separated places.
Date: Mon, 27 Feb 2023 08:09:23 +0100 [thread overview]
Message-ID: <20230227070903.rpbd6bleozrv3tjn@carbon.lan> (raw)
In-Reply-To: <cf41cdd7-6b79-3619-5bc3-64bc1ec18794@protonmail.ch>
On Tue, Jan 31, 2023 at 11:29:26AM +0000, Piotr Karbowski wrote:
> Hi,
>
> On 14/02/2022 08.45, Daniel Wagner wrote:
> > On Sun, Jan 30, 2022 at 09:50:31PM +0000, Piotr Karbowski wrote:
> >> If you were to move the /var/lib/connman/<SERVICE_NAME>/settings to
> >> perhaps subdirectory in /etc/connman/networks/ it could work. One of the
> >> example could be NetworkManager that actually dynamically create files
> >> in /etc.
> >
> > /var/lib/connman/* are not configuration files. These files contain the
> > state. The are under control of ConnMan and will be overwritten.
> >
> > That means these files need to live in space where ConnMan can write to
> > (/etc will not work). Furthermore, embedded devices tend to be vary
> > cautions about write updates and often move such things to a tmpfs.
> >
> > Another problem is the id used to apply to a newly discovered
> > services. The path is constructed using the MAC. In my opinion not very
> > convenient and not really future proof.
> >
> > All this is solvable but it is a bit more work than just moving the dirs
> > around. I think we would need to introduce a new configuration logic here.
> >
> >> That would be pretty clean interface to configure connman. Especially if
> >> you need to pre-create some configs for services manually like 802.1X
> >> that I think is not supported by any userspace utils that ships with
> >> connman.
> >
> > Yes, I do understand the need for something like this. Ideally we
> > wouldn't come up with yet another config file format. Maybe we could
> > reuse the one from systemd-networkd? No idea if this would work, just an
> > idea.
>
> I recently had to do another round of connman configuration which
> reminded me about this thread.
>
> Wanted to ask if you still consider this a feature that's worth getting
> into? I kind of got used to the current way but still believe it would
> benefit many to have it unified. I am all into being the tested if you
> ever decide to introduce some new interfaces to configure connman.
Yes, it still makes sense to me. Though I become a very poor maintainer and I
think it is high time to hand over the project to someone else. Without someone
looking over contributions the bit rotting continues and new feature are
certain not going to be implemented by me.
prev parent reply other threads:[~2023-02-27 7:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 22:40 Unification to connman configuration? Now it 3 separated places Piotr Karbowski
2022-01-30 14:51 ` Daniel Wagner
2022-01-30 21:50 ` Piotr Karbowski
2022-02-14 7:45 ` Daniel Wagner
2023-01-31 11:29 ` Piotr Karbowski
2023-02-27 7:09 ` Daniel Wagner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230227070903.rpbd6bleozrv3tjn@carbon.lan \
--to=wagi@monom.org \
--cc=connman@lists.linux.dev \
--cc=piotr.karbowski@protonmail.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).