LWN: Comments on "Udev and systemd to merge"

Dependency on DBUS?

oldtomas — Mon, 09 Apr 2012 14:59:29 +0000

Will there be a binary dependency on libdbus?

Udev and systemd to merge

khim — Fri, 06 Apr 2012 21:25:42 +0000

The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)

s/Linux/Windows/

Widow-maker is used to attach to the upstream, to “WAN” power grid (this is what you “naturally expect” for some reason). This is Windows way.

In Linux you share your wall outlets (you local in-house “LAN” electric network) instead.

the entire concept of LAN vs. WAN only propagates this confusion

Why? WAN == WIDE area network (think city-level or even wider electrical network), LAN == LOCAL area network (think you own tiny in-house network with dozen or two plugs and few appliances). If you want to share electricity with someone you most definitely will do it using your local network (unless you have some serious reasons to use thing which is called Widow-maker or other similarly ominous names).

Udev and systemd to merge

scientes — Fri, 06 Apr 2012 20:54:43 +0000

#1. the entire concept of LAN vs. WAN only propagates this confusion

#2. The Linux way of electricity networking does exist in your 2nd electrical example, its called a Widow-maker or other similarly ominous names. (for good reason)

Udev and systemd to merge

khim — Fri, 06 Apr 2012 20:39:19 +0000

It's my internet connection I want to share, so I naturally expect to set its interface, the upstream one, to 'share with other computers'; the upstream connection is what I'm sharing, and is therefore be the object in the sentence "Share my internet connection with other computers".

Well, it'll be nice psychology study which will show just why Joe Average gets the facts backward, but this logic is obviously quite strange.

Let's forget about network, routing, packets, etc. Suppose my neighbour lost electrical power and I, ever the helpful guy, want to share my grid power connection with him (electrical grid, not Internet).

Now, I have two choice:
1. I can go find out where and how my own house itself is connected to grid and try to change that global connection. I can even succeed and survive (if I'm lucky).
or
2. I can change my local connection configuration: just plug extension cord to my wall socket and attach appliances of my neighbour to it.

Somehow when electrical grid is concerned everyone automatically assumes solution #2 is right, but for Internet they want go and try to change WAN#1 (their WAN connection)? WHY? What's so special about Internet?

P.S. This phenomenon is quite obviously present because Microsoft tries to “help” here. It ALSO makes no sense to change WAN configuration when you share it even in Windows, but hey, if people en masse want to do this strange thing then this is how it should be done. As a result when you share network connection you must “alter” WAN connection, but this is illusion. When you try to “share” WAN connection in Windows WAN connection is not changed at all. Instead Windows goes and silently changes LAN connection behind your back.

The end result is essentially the same as with Linux, but with a twist: in simple cases everything “just works”, but in complex cases you must imagine these behind the scenes changes and do complex dance (Ok, I need to change this network in this and that way, but this is impossible to do so I need to create fictive temporary network and change THIS, then I can delete it because it's unneeded and I can fix THAT and but this well mean that networks will be disconnected but this can be fixed later…) I hate that.

Udev and systemd to merge

cortana — Fri, 06 Apr 2012 20:37:45 +0000

That language change would definitely be a lot better.

Udev and systemd to merge

scientes — Fri, 06 Apr 2012 20:23:33 +0000

thats only because you are considering yourself a slave to your Internet connection, and a slave to the Internet. The way it works, it will share any connections you have, even if you dual-banding with the neighbor that has a differn't ISP so that you don't have to worry about censorship, are to evade network neutrality violations.

sure maybe the language needs to be made clearer, "share Internet to this interface?"

Udev and systemd to merge

cortana — Fri, 06 Apr 2012 20:02:30 +0000

I find it confusing to have to set the mode of the downstream interface to 'share with other computers'. It's my internet connection I want to share, so I naturally expect to set its interface, the upstream one, to 'share with other computers'; the upstream connection is what I'm sharing, and is therefore be the object in the sentence "Share my internet connection with other computers".

Udev and systemd to merge

scientes — Fri, 06 Apr 2012 19:44:57 +0000

> One quirk that I never bothered to raise upstream was that you're not supposed to set the mode of the *upstream* connection to 'shared to other computers'; you're supposed to set the mode of the *local* connection.

as someone that has basic understanding of the networking, and has done this manually, this makes perfect sense, the other way you talk of is confusing, and would be way less capable.

If it wasn't for ipv4 exhaustion, sharing your internet connection could as simple as turning on ipv4 packet forwarding. (now there is also address allocation issues, so DHCP) the complexity, and ever difference between upstream, and downstream, somes from Network Address Translation.

Udev and systemd to merge

Eckhart — Fri, 06 Apr 2012 16:53:34 +0000

Ah, then I just misinterpreted your original sentence. Thanks.

Udev and systemd to merge

Aissen — Fri, 06 Apr 2012 15:26:50 +0000

See:
https://lwn.net/Articles/452865/
and more recently:
https://lwn.net/Articles/484168/

I said "full integration" because systemd is already in debian (http://packages.qa.debian.org/s/systemd.html ), it's just not the default init. So it's integrated, but not fully since not all daemons have systemd unit files.

Udev and systemd to merge

Eckhart — Fri, 06 Apr 2012 14:49:04 +0000

>Most things in Debian are optional, that's the beauty of the thing (and sometimes, the hassle, see the systemd "full integration" drama).

Can you please explain the systemd "full integration" "drama"?
(both "full integration" and "drama")

Udev and systemd to merge

Eckhart — Fri, 06 Apr 2012 14:39:54 +0000

The way NetworkManager works is actually pretty simple. Unless a connection is marked "Shared", it is considered a potential upstream connection. Of all the upstream connections, the best one is marked the default gateway, with simple ordering (i.e. vpn wins over cable, cable wins over wireless…).
A connection marked as shared will get a DHCP server and uses NAT to route traffic over the default gateway. Therefore it is perfectly possible to share your 3g connection via ethernet to a bunch of computers.

Udev and systemd to merge

Eckhart — Fri, 06 Apr 2012 14:32:55 +0000

> can i share over ethernet, as opposed to just wireless? If so, I guess I missed that functionality, I had alot of pain trying to do it myself while still having networkmanager work.

This is perfectly possible with NetworkManager. Just create a wired connection, set method to Shared, and NetworkManager will start a DHCP server on your wired connection.

Udev and systemd to merge

cortana — Fri, 06 Apr 2012 12:20:44 +0000

I don't think NM cares about the kinds of each connection involved in sharing. One quirk that I never bothered to raise upstream was that you're not supposed to set the mode of the *upstream* connection to 'shared to other computers'; you're supposed to set the mode of the *local* connection. Perhaps NM sets up some iptables rules so that only packets from local interface marked as 'shared to other computers' will be routed out of the upstream interface... I didn't bother to look into it once I made it work. :)

Udev and systemd to merge

MaZe — Fri, 06 Apr 2012 07:33:45 +0000

This is a fundamental git metadata format bug.

a commit object includes 0 or more parent hashes.
initial commit having 0,
normal commits having 1,
merges having 2 or more.

a normal two-way merge thus has 2 parent hashes.
a subtree two-way merge also has 2 parent hashes.

nowhere in the merge commit metadata is the fact that it is a subtree merge recorded (nor is the subtree directory recorded)

ie. the fix would be to include not only the parent's hash, but also the subdirectory at which the parent commit is being merged.

Since the subtree merge commit does not include anything to distinguish it from a normal non-subtree merge, it is not possible to (cheaply in terms of processing power) determine that all changes happening at path X/Y/Z within the subtree parent history should actually be treated as happening at subtree/X/Y/Z.

When running something like git log across a commit, ie. across it's history, git has to look at hundreds or thousands or tens of thousands of merges, it cannot afford to devote cpu time to figuring out whether a merge commit is a subtree commit, so it assumes all of them aren't.

As a result of this, once starts looking at the parent of a subtree merge (and its parents), the assumption that the tree is rooted at / is no longer correct.

As a result:
git log subtree/X/Y/Z will show changes to Z since the subtree merge
git log X/Y/Z will show changes to Z before the subtree merge

Worse, if you have Makefile, and merge another project with a Makefile into subdirectory dir:
git log dir/Makefile shows changes since the subtree merge
git log Makefile shows all changes to the Makefile and changes to dir/Makefile from before the subtree merged - interspersed.

This could be fixed by having instead of
parent <hash>
information in the commit object something like
parent <hash> @ subtree

[for extra brownies also allow the opposite, ie. supertree merges, where you merge not commit into directory, but commit:directory into /, or even super-subtree merges, where you merge commit:directory into other_directory]

so the generic format should allow:
parent <hash>:directory/path @ subtree/path

and all the tools should be taught to follow such parent links properly.

Unfortunately, this will not fix subtree merges performed with old versions of git, and it is a backwards incompatible change.

Udev and systemd to merge

scientes — Thu, 05 Apr 2012 16:49:55 +0000

> It's great to be able to e.g., quickly configure my laptop for "internet connection sharing" with just a few clicks.

can i share over ethernet, as opposed to just wireless? If so, I guess I missed that functionality, I had alot of pain trying to do it myself while still having networkmanager work.

Udev and systemd to merge

scientes — Thu, 05 Apr 2012 16:43:41 +0000

their linker also has an arbitrary (and low) limit of 96 shared libraries linked to a process.

Udev and systemd to merge

geofft — Wed, 04 Apr 2012 23:26:24 +0000

If you pass a filename argument to git log with --stat or similar, it'll only show the changes that apply to that filename.

(I'm not sure this is the correct behavior, but it is the current behavior.)

Udev and systemd to merge

rleigh — Wed, 04 Apr 2012 23:16:14 +0000

Have you tried the new ifupdown in experimental? If not, it might be worth a try (but an updated version will be going into unstable in the next few days if you want to wait). This fixes a lot of long-standing issues.

Udev and systemd to merge

iabervon — Wed, 04 Apr 2012 21:23:39 +0000

I'd guess it was actually the assumption that GNOME couldn't possibly get a system daemon right. Nobody wants to repeat the situation we had when every desktop environment had its own sound daemon that interfered with sound from programs that didn't use it. Of course, that's not actually the case, but having a generic component come from a desktop environment project gives people the wrong impression.

Udev and systemd to merge

karim — Wed, 04 Apr 2012 21:00:28 +0000

No, Android merges the code-base, not the processes. They run as separate processes in Android.

Udev and systemd to merge

przemoc — Wed, 04 Apr 2012 20:28:29 +0000

Maybe "merging" wasn't done right after all?

commit ad29a9f14fa8b1932c0e418bfcf1c10ce6a35a33
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu Jan 5 22:41:45 2012 +0100

merge udev/, libudev/, systemd/ files in src/; move extras/ to src/

R099 udev/udevd.c src/udevd.c

commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

R099 src/udev/src/udevd.c src/udev/udevd.c

Or git is losing some traces?

$ git log --follow --name-status -- src/udev/src/udevd.c
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

D src/udev/src/udevd.c

It's interesting that the only history of this file is its deletion. ;-)

--
1.7.9.1

Udev and systemd to merge

drag — Wed, 04 Apr 2012 18:52:40 +0000

It certainly seems like a good candidate for /usr/share/doc/*/examples item.

Udev and systemd to merge

tzafrir — Wed, 04 Apr 2012 18:43:21 +0000

That said, the full reference file is confusing without an example.

http://bugs.debian.org/637769

Last time I asked, I was told adding such a thing was not a good idea (which is why the bug report is not in the NM bugzilla).

Udev and systemd to merge

mgedmin — Wed, 04 Apr 2012 17:59:51 +0000

I've attempted to use nmcli to connect to a wireless network (WPA2 encryption) in the past and failed miserably. As far as I can tell, this is simply not supported (you can only connect to a connection you've configured before).

I can barely manage to figure out how to list available networks ('nmcli dev wifi', really?).

Udev and systemd to merge

mathstuf — Wed, 04 Apr 2012 16:46:41 +0000

Right, this is something I don't see why nmcli can't help with. A subcommand like "nmcli dump-config essid 'some_wireless_network'" to get a barebones keyfile which can then be edited should be possible.

Udev and systemd to merge

drag — Wed, 04 Apr 2012 16:40:50 +0000

> Of course, being able to create connections with nmcli would be nice too (unless it's a recent change, I haven't found out how to give it passwords and such for new wireless networks and instead have to launch nm-applet to create the connection which can then be managed with nmcli).

You edit your own keyfile and then copy it to /etc/NetworkManager/system-connections/. NetworkManager watches that directory and should pick up on changes to configs automatically.

Although it's usually easier to use the nm-applet to make something so you have a config to work on when you want to make changes in the future.

Udev and systemd to merge

Aissen — Wed, 04 Apr 2012 16:05:42 +0000

Most things in Debian are optional, that's the beauty of the thing (and sometimes, the hassle, see the systemd "full integration" drama).
Also, previous commenter pointed out that I mixed ifplugd and ifupdown. He was right.

Udev and systemd to merge

jond — Wed, 04 Apr 2012 15:28:14 +0000

> The funny thing about Debian's mess: it relies heavily on ifplugd (although it isn't mandatory), which was written by… I'll let you guess ;-)

Indeed, "it's entirely optional" would be closer to the truth.

Udev and systemd to merge

jond — Wed, 04 Apr 2012 15:27:14 +0000

The D-Bus guys have been trying to push a lot of that into the Kernel (no, really)

Udev and systemd to merge

mathstuf — Wed, 04 Apr 2012 15:09:08 +0000

I think he's aware it's a saying. I think he's more asking why this would have any effect on his decision to switch to mdev at all.

Udev and systemd to merge

mathstuf — Wed, 04 Apr 2012 15:04:55 +0000

> The spec for the settings can be found..
> http://projects.gnome.org/NetworkManager/developers/api/0...

Thanks for that link. It really needs to be mentioned in the nmcli man pages.

Udev and systemd to merge

mathstuf — Wed, 04 Apr 2012 15:01:38 +0000

> NetworkManager is actually becoming pretty awesome. It's great to be able to e.g., quickly configure my laptop for "internet connection sharing" with just a few clicks.

Unfortunately, a feature[1] (though I consider it a bug) which is a blocker for me is still present.

Basically, I'd like to be able to set a wireless network as "flaky" so that if the connection drops, NM silently retries in the background continually instead of dropping the connection and *then* trying to reconnect. NM-aware applications tend to freak out if this happens every 5 minutes or so. Another use case is when moving around and one network is out of range temporarily in the presence of another known network (personal wireless, which is vastly preferred, versus campus wireless in my case). Going between floors takes me out of range of the my wireless, but the end points are both within range. I'd like to be able to tell NM that, but AFAIK, it will drop the connection, pick up the campus wireless and then not drop it when my wireless comes back into range because the campus connection is still there.

Of course, being able to create connections with nmcli would be nice too (unless it's a recent change, I haven't found out how to give it passwords and such for new wireless networks and instead have to launch nm-applet to create the connection which can then be managed with nmcli).

Currently, I just use ifcfg scripts for connections and wpa_supplicant.conf for wireless network configuration.

[1]There's a bug open somewhere for it, but I can't find it right now.

Make it a library?

RCL — Wed, 04 Apr 2012 14:58:44 +0000

When you start to reuse code it becomes unmaintainable. Everyone is afraid of touching the common part lest they break some functionality they cannot test for themselves (or even know about).

So unless the common part is really simple and plain and will *never* need any refactor/improvement, don't do that. The world is built upon redundancy, which helps parallelization of efforts.

Udev and systemd to merge

Aissen — Wed, 04 Apr 2012 14:54:46 +0000

Indeed, "git log --follow -- src/udevd.c" is giving the expected result — almost: it only shows the old commits.
It's a weird behaviour "git log" is having here, I don't fully understand why.

Udev and systemd to merge

niner — Wed, 04 Apr 2012 14:20:26 +0000

You have to use the path the file had in the original repository.

Udev and systemd to merge

drag — Wed, 04 Apr 2012 14:15:17 +0000

Nano? Pff.

Just rewrite Eclipse using Vala and then compile it to C and import it into the udev Git repository and that should be it. Problem solved.

Udev and systemd to merge

drag — Wed, 04 Apr 2012 13:46:10 +0000

I like network manager, personally, but I don't think it's going to offer much of a improvement over 'post-up' calls.

Generally what you'd want to do for network-manager is to put your scripts into /etc/NetworkManager/dispatcher.d in the typical "if [ "$2" = "up" ]; then" style format.

To get the best benefits out of NetworkManager you want to disable all the 'legacy' configuration plugins and use keyfile. That way you can edit all your network configurations using a 'ini' file format in /etc/NetworkManager/system-connections/

The advantage to this is that you can support a much more diverse amount of network connection types with better granularity then you can through traditional distro-specific configs.

The spec for the settings can be found..
http://projects.gnome.org/NetworkManager/developers/api/0...
http://live.gnome.org/NetworkManager

For managing it through the command line use 'nmcli'.

I wish Gnome would provide a better documentation and examples for people using network manager on a server, but oh well.

Udev and systemd to merge

Aissen — Wed, 04 Apr 2012 13:00:52 +0000

Exactly my point. The first thing I did was:

$ git log --follow src/udev/udevd.c
commit 3e2147858f21943d5f4a781c60f33ac22c6096ed
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Apr 3 21:24:46 2012 +0200

move imported udev into place

--
And that was all. Then git blame on the same file seems to have all the history. So what should I do to have git log show me the full history ?

Udev and systemd to merge

yoshi314 — Wed, 04 Apr 2012 12:51:39 +0000

too bad http://cgit.freedesktop.org/systemd/systemd/log/src/udev does not show much, even though the global log does.