On Thu, Feb 19, 2015 at 11:32 AM, Reindl Harald <[email protected]> wrote: > @Tom: sorry for the off-list reply, your reply-all disabled "reply to list" > in my MUA :-( > > Am 19.02.2015 um 11:23 schrieb Tom Gundersen: >> That is a related problem, but it is a minor detail. The point is that >> we don't want to have to store state on disk (about which interface >> should have which name). The only way then is to find an algorithm >> that will always compute the same name for the same interface without >> referring to any state. Topology is one way. Firmware information is >> another. MAC addresses is another. Using the kernel names as-is is out >> of the question. Having a list on disk mapping interfaces to names is >> also out of the question. > > "Having a list on disk mapping interfaces to names is also out of the > question" because it would solve the problem?
Yes. We don't like solving problems. Only creating them ;-) No, seriously, the problem is that while in most cases writing state to disk would be fine, there are cases where we don't have a writeable disk at the right time. We can never assume /etc to be writable (except due to explicit admin requests, never automatically due to hardware events etc) and we can not assume /var to be available during early boot. Moreover, the more state we rely on the more things can break. To the extent possible we don't want the admin to have to worry about wiping state from disk (having this attitude from the get-go makes it much nicer when we do things like fresh /etc and/or /var on every boot). > frankly that worked over many years with udev rules and still works if you > put the MAC in the ifcfg-ethX You can still have a list of MAC addresses and interface names with today's udev. What we won't do is to generate the list on-the-fly when interfaces appear. And yeah, you'll have to name them something else than ethX to avoid the kernel race. But that is surely not a huge problem (solving it, would be really ugly). > get rid of the race with kernel it would only have needed a agreement that > the kernel autonaming use a different scheme not colliding with ethX and as > all the years before on Fedora facing the first time a new ethernet card > appears configure the ethX in the udev rules We don't explicitly ban ethX in udev, we just say that you have to use different names than the kernel. If you convince the kernel developers to call all the links fooZ you can rename to ethX just fine. > the problem with the current way is that you can't rely any longer that > eth0, eth1, eth2 are present on different hardware as long as you don't > disable "predictable interface names" - well, i can live with that and have > my ethX but that don't make the new scheme better Yeah, if you really want eth0,1,2, then just disable the logic. It cannot be the default though. It just does not work. Feel free to prove me wrong by posting a patch implementing this whilst keeping the properties we need. I think you should know all the concerns by now, so no need for me to repeat myself yet again. > there are people with the need to re-use unmodified config files instead > fork them on every machine..... Yeah, this is something we have kept in mind with our own config files (in networkd in particular). We have an elaborate matching logic precisely because we want config files to be reusable to the greatest degree possible. It probably works for you by just making sure the naming scheme for your links is the same on all your machines (or maybe your machines just give that to you for free because you are lucky), but in general that is not powerful enough and not reliable enough. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
