Hi Lennart, >>>>>> why do we have to spawn threads or do forks for DNS. This looks all >>>>>> pretty expensive. In ConnMan for example we just wrote our own async >>>>>> DNS using a mainloop. Works perfectly fine and is dirt cheap. >>>>> >>>>> Well, we don't fork threads/processes for each call but reuse them. >>>>> >>>>> What libasyncns does what your solution doesn't do is go via NSS. This >>>>> means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just >>>>> work, while that all is lost when doing DNS natively. >>>>> >>>>> I am pretty sure we should not bypass NSS for this. >>>> >>>> actually NSS for DNS is pretty nasty stuff. I am pretty sure we should >>>> bypass it and create a proper implementation. Is anybody actually using >>>> NIS or LDAP for domain name resolution? >>>> >>> >>> Yes, there are solutions that are using LDAP for hostname resolution >>> quite heavily - actually are based around LDAP without any >>> local /etc/hosts. >> >> that is extremely heavy and must suck form a latency point of >> view. Then again, nothing that a DNS<->LDAP bridge couldn’t easily >> support. Since dragging LDAP dependencies into every program that has >> to load NSS modules is not a good idea either. > > Note that "nscd" was created to deal with the performance of the LDAP > setups and also doesn't require loading everything into the same process.
and that is an excuse to keep using NSS modules? We took a rather shitty idea and hacked it up a little and it is now a little bit less shitty. Just to be clear, I have nothing against the general idea, I am just saying that NSS itself with its current design is pretty limited. And keep working around it is not helping either. Regards Marcel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel