On Tue, Apr 26, 2011 at 3:33 PM, Dave Reisner <d...@falconindy.com> wrote: > On Tue, Apr 26, 2011 at 10:17:26PM +0200, Tom Gundersen wrote: >> On Tue, Apr 26, 2011 at 8:43 PM, Dan McGee <dpmc...@gmail.com> wrote: >> > I do- making a system unbootable without a config change is never a >> > good idea. My hope with selection number 2 was that no one using a >> > "normal" config would have to change anything, e.g. those using >> > headless systems would not have to tweak any dials. >> >> This is a good point (which I should have elaborated on). The problem >> is that there is currently no limit to what weird things people might >> use the network script to do, so it is very hard to keep 100% >> backwards compatibility (unless we opt for not changing anything at >> all). >> >> What I had in mind was to map the old configuration to the new one in >> such a way that those who had a vanilla setup before would not notice >> anything. However, those who set up weird stuff would have to change >> their config. >> >> Note that we cannot keep 100% backwards compatibility if we want to >> move to iproute2 (which I really think we should as net-tools has >> been dead for more than 10 years), so something would have to break >> (Dave, correct me if I'm wrong here...). > > net-tools uses the kernel's ioctl syscall interface to get/set values in > the kernel's routing tables. This entire interface has been deprecated, > but I've seen no indication of it going away yet. I suspect that perhaps > one day, it will. > > iproute2 uses netlink sockets to communicate with the kernel, which is a > far more extensible and flexible interface. It's already fairly old, > being introduced in the 2.2 series. iproute2 also has the advantage of > being maintained by the same people in charge of the network stack in > the kernel. If something were to change, we'd surely see appropriate > changes in iproute2 as well. > >> So the question is: is it worth trying to keep some network >> functionality in initscripts, taking into account that we cannot be >> 100% backwards compatible? Alternatively, is backwards compatibility >> so important that we should not change it at all? >> > > Maybe there's some way to have an ugly pubescent transition where we > fall back on the old config if variables are missing and complain loudly > to the user, citing deprecation. Large warnings in the bridge and > bonding functionality would be appropriate too.
I imagine the majority of setups look like this for people: $ grep eth /etc/rc.conf # DHCP: Set your interface to "dhcp" (eth0="dhcp") eth1="dhcp" INTERFACES=(eth1) At the very least, you need to make this a no-hassle out of the box netcfg configuration setup (perhaps there can be some sort of netcfg use rc.conf mode?). With that said, coming from someone working on a system-critical piece of software: anything you want to remove or make inoperable needs at least a year of warning and prep time. I know that sounds absurd with an "always changing" Arch, but note how an rc.conf from near 0.1 days would probably still work today. -Dan
