Repository navigation
Add dmsystem service files so DHCP starts as a service - #2
Merged
Merged
Conversation
dmdhcp is a Library-type module like dmicmp, so configs/dhcp.ini loads and enables it via libsystemd's type=library, mirroring dmicmp's configs/icmp.ini. Unlike dmicmp, dmdhcp does not do anything useful merely by being loaded - dmdhcp_start() still needs to be called per interface. Add a small tools/dhcpc application module (the same per-interface-instance shape dmnet's networkd uses) plus a dhcp@.ini unit template so an integrator can enable DHCP on whichever specific interfaces need it, without auto-wiring into dmnet's own netif device rule (which would either silently lose the RX pump or the DHCP trigger, since libsystemd only honors the first rules file that defines a given device class).
dmnetif.h #includes dmroute.h directly, so any target that includes it needs dmroute's headers on its include path - the dhcpc module itself already links dmroute for this reason, but its test target didn't.
dhcpc already links dmdhcp_if directly, so loading it (however it gets started) loads and enables dmdhcp as its own module dependency - the same way tools/ping pulls in dmicmp with no separate unit for it. A standalone configs/dhcp.ini (type=library, exec=dmdhcp) was therefore redundant: it offered a second way to reach the same load+enable dhcpc already causes as a side effect. Also add tools/dhcpc/configs/dhcp.rules ([class=netif] start=dhcp@%name), now that libsystemd fires every rule matching a device class instead of only the first (choco-technologies/dmsystem#4) - dhcp.rules and dmnet's own networkd.rules can both declare [class=netif] and both fire from the same dmnetif device event, so every interface gets a DHCP attempt alongside its RX pump with no static per-interface unit file to maintain. dhcp@.ini's after=/requires= on dhcp/networkd@%i is dropped too: dhcpc only needs to call dmdhcp_start(), which retries DISCOVER on its own timer regardless of whether the RX pump is up yet. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nobwf1PoG7dzKcwTWx5w5K
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
tools/dhcpcApplication-type module that callsdmdhcp_start(iface, ...)on one named interface and exits - the actual trigger that turns "dmdhcp is loaded" into "this interface has an address" (dmdhcp itself, unlike dmicmp, does nothing on its own once loaded - seedocs/service.md).dhcpclinksdmdhcp_ifdirectly, so loading it - by any means - loads and enablesdmdhcpas its own module dependency automatically (the same waytools/pingin dmicmp pulls indmicmp). There is no separatedhcp.iniunit - it would just be a redundant second way to reach the same load+enabledhcpcalready causes.tools/dhcpc/configs/dhcp@.ini(per-interface unit template) andtools/dhcpc/configs/dhcp.rules([class=netif] start=dhcp@%name) so every interfacedmnetifreports gets adhcp@<iface>instance automatically, the same per-interface-instance shape dmnet'snetworkduses for its RX pump - installed alongside dmnet's ownnetworkd.rules, both declaring[class=netif]and both firing from the same device event. This relies on choco-technologies/dmsystem#4 (merged) -libsystemdnow fires every rule matching a class instead of only the first.docs/service.mddocumenting the above, updatedocs/README.md/rootREADME.mdto link it, and wiretools/dhcpcinto the build (CMakeLists.txt,dmdhcp.dmr,manifest.dmm), following the exact conventionsdmicmp/tools/pingalready established for a nested Application-type tool module.Test plan
cmake --build .) succeeds fordmdhcpand the newdhcpc/test_dhcpctargetsctestpasses, including the newtest_dhcpcsteps (missing args, unknown interface, module unload, and a successfuldmdhcp_start()against a fixture interface)tools/dhcpc/configs/dhcp@.ini+dhcp.rulesinto alibsystemdunits/rules directory alongside dmnet'snetworkd@.ini/networkd.rulesand confirm bothnetworkd@<iface>anddhcp@<iface>auto-start for a real interface🤖 Generated with Claude Code
https://claude.ai/code/session_01Nobwf1PoG7dzKcwTWx5w5K