On 21/10/2024 14:51, Lennart Poettering wrote:
On Mo, 21.10.24 12:38, Petr Menšík (pemen...@redhat.com) wrote:
Okay. It might be better than D-Bus, but having to make separate connections
for every single resolution is still a bit wasteful.
Uh. I mean, if you want, kep the connections around a
Not sure I follow here. Chrony is default NTP implementation on Fedora
AFAIK. Not systemd-timesyncd or timedatex. Chrony does not use varlink
interface, does it?
On 21/10/2024 15:11, Michael Catanzaro wrote:
On Mon, Oct 21 2024 at 02:51:56 PM +02:00:00, Lennart Poettering
wrote:
I know you d
On Mon, Oct 21 2024 at 02:51:56 PM +02:00:00, Lennart Poettering
wrote:
I know you don't like systemd-resolved, but maybe you can at least
acknowledge that is does exist.
The nice thing about IPC APIs is it's easy to reimplement them however
you please, similar to how elogind reimplements man
On Mo, 21.10.24 12:38, Petr Menšík (pemen...@redhat.com) wrote:
> > That's quite a misunderstanding. Varlink takes benefit of the fact
> > that AF_UNIX connections are cheap, and it optimizes for that
> > (i.e. there is no handshake protocol or so, like in D-Bus). i.e. if
> > you want 7 DNS resolu
On 21. 10. 24 11:53, Lennart Poettering wrote:
On So, 20.10.24 18:33, Petr Menšík (pemen...@redhat.com) wrote:
From what I read about Varlink.org, it requires answers to be delivered in
the same order in which queries has came.
That's quite a misunderstanding. Varlink takes benefit of the fac
On So, 20.10.24 18:33, Petr Menšík (pemen...@redhat.com) wrote:
> From what I read about Varlink.org, it requires answers to be delivered in
> the same order in which queries has came.
That's quite a misunderstanding. Varlink takes benefit of the fact
that AF_UNIX connections are cheap, and it op
On Sa, 19.10.24 08:55, Andrew Lutomirski (l...@mit.edu) wrote:
> 2. D-bus and varlink. These are at least not tied to /etc, but, just like
> /etc, they’re associated with the wrong namespace!
>
> Name resolution is part of *networking*, not filesystem. I should be able
> to nsenter a network names
On Fr, 18.10.24 16:27, Petr Menšík (pemen...@redhat.com) wrote:
> Is there any API description of the Varlink API, which you are referring to?
In Varlink introspection contains the documentation
itself. i.e. here's what "varlinkctl introspect
/run/systemd/resolve/io.systemd.Resolve io.systemd.Res
From what I read about Varlink.org, it requires answers to be delivered
in the same order in which queries has came. That is quite unwanted
feature for the name resolution. We cannot set priorities affecting
earlier queries. If some names are resolved sooner and previous name is
taking long, it
Interesting point. Haven't thought about it much. Yes, current
/etc/resolv.conf is quite a weird configuration style in common today's
usage. I thought about proposing standard unix domain socket in /run,
but that would still be part of filesystem namespace.
Unix domain have advantage, that th
On Oct 18, 2024, at 7:28 AM, Petr Menšík wrote:
Is there any API description of the Varlink API, which you are referring to?
I have found:
- https://systemd.io/WRITING_RESOLVER_CLIENTS/
-
https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html
- https://systemd.
Is there any API description of the Varlink API, which you are referring to?
I have found:
- https://systemd.io/WRITING_RESOLVER_CLIENTS/
-
https://www.freedesktop.org/software/systemd/man/latest/org.freedesktop.resolve1.html
- https://systemd.io/USER_GROUP_API/
None of that mentions the raw
On Do, 17.10.24 18:11, Petr Menšík (pemen...@redhat.com) wrote:
> > I certainly have answered the questions you raised for *myself*,
> > though I am pretty sure you are not going to like my answer: I think
> > the Varlink IPC APIs that systemd-resolved implements are the way to
> > go. There's wor
I agree in some parts. But introducing new Varlink protocol makes it not
necessary simpler or more modern.
On 16. 10. 24 17:08, Lennart Poettering wrote:
On Mo, 14.10.24 22:53, Petr Menšík (pemen...@redhat.com) wrote:
I think struct addrinfo used by getaddrinfo() is basically good output even
On Mo, 14.10.24 22:53, Petr Menšík (pemen...@redhat.com) wrote:
> I think struct addrinfo used by getaddrinfo() is basically good output even
> for HTTPS record. But it needs in addition also key=value metadata with
> additional parameters. Similar for SRV. The end result is still ordered list
> o
Hello!
Is there any good place, where do you think possible improvements in
resolution API provided to applications should happen? Should it be
glibc mailing list?
We have touched it at my question about draft allowing multiple records
in single DNS query [1]. In current best practice, appli
16 matches
Mail list logo
