[arch-projects] [initscripts][netcfg] deprecating advanced network functionality from initscripts

[Dave Reisner]

On Tue, Apr 26, 2011 at 10:17:26PM +0200, Tom Gundersen wrote:
> On Tue, Apr 26, 2011 at 8:43 PM, Dan McGee <dpmcgee at 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.

d