Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Wed, Nov 13, 2013 at 11:22:28PM +0200, Patrik Flykt wrote: Hi, This patch set implements a DHCPv4 client library named libsystemd-dhcp to be used with systemd-network. Nice stuff. Where did this code come from, conman? If so, for some reason I thought that it would be easier to make a library of the existing conman dhcp code and have both projects use it instead of forking and having two copies? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
Hi Greg, This patch set implements a DHCPv4 client library named libsystemd-dhcp to be used with systemd-network. Nice stuff. Where did this code come from, conman? If so, for some reason I thought that it would be easier to make a library of the existing conman dhcp code and have both projects use it instead of forking and having two copies? that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop and then it will also start using libsystemd-dhcp. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
Hi, On Thu, 2013-11-14 at 06:31 +0900, Greg KH wrote: Nice stuff. Where did this code come from, conman? If so, for some reason I thought that it would be easier to make a library of the existing conman dhcp code and have both projects use it instead of forking and having two copies? Looking more carefully at the code in ConnMan started to reveal the relative age of the DHCP client part and showed some interesting code that might not be entirely correct. After removing the GLib main loop parts not too much valuable code was left behind. I have kept one eye in the existing code to find additions for picky servers so I hope the lessons learned have not been lost. I'm more positive with the DHCPv6 part, that implementation has more reusable parts. I'm not too worried about having two copies for now, the one in ConnMan would have met its fate anyway a bit later. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Thu, 2013-11-14 at 06:49 +0900, Marcel Holtmann wrote: that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop But I think the long term architecturally correct place for the core system main loop is glibc, not systemd. For example, that would allow runtimes like OpenJDK and Python to unconditionally depend on it (if present). As systemd's event loop becomes public API, it has the potential to create interoperability problems for GNOME - think applications like https://git.gnome.org/browse/gnome-logs that want to both monitor the systemd journal and talk to GTK+. At the moment it's OK because sd_journal has APIs sufficient to plug in external loops. Adding a mainloop API to glibc would be a lot of work - it might even entail trying to get it by POSIX. At least it'd entail describing the interaction with the other POSIX APIs. But I think that'd be worth the effort. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
Hi Colin, that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop But I think the long term architecturally correct place for the core system main loop is glibc, not systemd. For example, that would allow runtimes like OpenJDK and Python to unconditionally depend on it (if present). As systemd's event loop becomes public API, it has the potential to create interoperability problems for GNOME - think applications like https://git.gnome.org/browse/gnome-logs that want to both monitor the systemd journal and talk to GTK+. At the moment it's OK because sd_journal has APIs sufficient to plug in external loops. Adding a mainloop API to glibc would be a lot of work - it might even entail trying to get it by POSIX. At least it'd entail describing the interaction with the other POSIX APIs. But I think that'd be worth the effort. I am a bit lost on your concerns here. Our focus for ConnMan is libsystemd-bus and kdbus support. Over time we will be removing our dependency on GLib completely. So the systemd event loop will become our only event loop. And as a system daemon, I only care about writing to the Journal. No idea why I would need a event loop for that. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Thu, 2013-11-14 at 07:25 +0900, Marcel Holtmann wrote: I am a bit lost on your concerns here. Our focus for ConnMan is libsystemd-bus and kdbus support. Yeah, sorry; I just kind of used your mail as a basis for the larger picture of sd_event as public API. And as a system daemon, I only care about writing to the Journal. No idea why I would need a event loop for that. Ah...even if you're not spawning external processes, I'd imagine you at least want g_timeout_add()/sd_event_add_monotonic() type thing where library code manipulates the poll timeout. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Wed, 13.11.13 17:18, Colin Walters (walt...@verbum.org) wrote: On Thu, 2013-11-14 at 06:49 +0900, Marcel Holtmann wrote: that is the long term plan. Once ConnMan is switching over to use libsystemd-bus and kdbus, we are switching over to using the systemd event loop instead of GLib main loop But I think the long term architecturally correct place for the core system main loop is glibc, not systemd. For example, that would allow runtimes like OpenJDK and Python to unconditionally depend on it (if present). As systemd's event loop becomes public API, it has the potential to create interoperability problems for GNOME - think applications like https://git.gnome.org/browse/gnome-logs that want to both monitor the systemd journal and talk to GTK+. At the moment it's OK because sd_journal has APIs sufficient to plug in external loops. Adding a mainloop API to glibc would be a lot of work - it might even entail trying to get it by POSIX. At least it'd entail describing the interaction with the other POSIX APIs. But I think that'd be worth the effort. I am pretty sure it makes sense to have domain-specific event loops. I am not convinced that it would even be possible to unify all event loop implementations into one. For example, GLib and and sd-event support priorization of events, which means we need to flush all queued events from the kernel before we decide which one to run first. This however is probably not the best choice for a number of other usecases, where you want to optimize for ridiculous numbers of fds. Hence, I believe developers should get a lot of freedom on how much or how little event loop they want, and which implementation they choose. Then, GMainLoop can do some things sd-event cannot do. sd-event can do a number of things GMainLoop cannot do. I doubt moving OpenJDK or Python to sd-event or something like it ever would make sense. (Do either even have any event loop? Java at least prefers async stuff via threads as the solution for IO, not multiplexing via poll()-like stuff -- which they only added very very late to the language...). For all event loop consuming library code I write I will make sure that it can be connected to any reasonable event loop, not only sd-event. I mean, libsystemd-bus already includes two event loop implementations, one in sd-event, and another trivial one in sd_bus_wait() in a way... So, please do not understand sd-event as an attempt to get everybody to use the same event loop. It's just an attempt to provide a good event loop by default, that is more useful than pure epoll (such as sanely handles lots of timers), that tries to provide some of the features that GMainLoop supported since a longer time (like timer coalescing or priorisation), that we need for low-level stuff (like OOM safety, this stuff should run in PID1...), and is generally just code that people can use, if they want, but don't have to. Not an attempt for standardisation but an attempt to just provide code that solves naked epoll()'s problems, without going overboard and turning into libev/libevent. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Thu, Nov 14, 2013 at 12:47:24AM +0100, Lennart Poettering wrote: I doubt moving OpenJDK or Python to sd-event or something like it ever would make sense. (Do either even have any event loop? http://www.python.org/dev/peps/pep-3156/ Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Wed, 13.11.13 23:22, Patrik Flykt (patrik.fl...@linux.intel.com) wrote: Hi, This patch set implements a DHCPv4 client library named libsystemd-dhcp to be used with systemd-network. The code implements the DHCP protocol from the INIT state up to expiry, T1 and T2 timer setting, but does nothing in response to the IP address reacquisition T1 and T2 timers being triggered. Expiry timer is followed and the DHCP client stopped when it triggers. INIT-REBOOT state is also not yet implemented; both these missing parts are to be implemented next. The code assumes that the caller can figure out the interface to use. The code expects to be handed an sd_event loop, a MAC address and an interface index. The outcome is a notification of an IP address being acquired and the callback provider is expected to set the IP address, netmask and default gateway. Higher level DHCP options such as DNS and NTP servers are requested from the server by default, but the response is not yet collected anywhere. I also don't know how detailed callback information is needed, is there for example any need to know the protocol state transitions or messages sent/received. I'd keep things minimal. But the addition DHCP metadata like NTP servers we certainly should pass back to the user of the lib. However, I'd very much prefer doing this high-level instead of low-level, i.e. provide calls such as sd_dhcp_client_get_ntp() to get a list of NTP servers, and so on... I do like the code and where this is going! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 00/28] Initial DHCP v4 library implementation
On Thu, 2013-11-14 at 00:47 +0100, Lennart Poettering wrote: I am pretty sure it makes sense to have domain-specific event loops. I am not convinced that it would even be possible to unify all event loop implementations into one. For example, GLib and and sd-event support priorization of events, Right, this is: https://bugzilla.gnome.org/show_bug.cgi?id=156048 I doubt moving OpenJDK or Python to sd-event or something like it ever would make sense. (Do either even have any event loop? Java at least prefers async stuff via threads as the solution for IO, not multiplexing via poll()-like stuff -- which they only added very very late to the language...). Yes, Java added it late, but it is AFAIK fairly actively used in some subsets of that world. Zbigniew already linked to the Python version. For all event loop consuming library code I write I will make sure that it can be connected to any reasonable event loop, not only sd-event. Ok, that's a reasonable short term answer. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
