Re: Status of netcfg-static
On Thursday 28 January 2010, Josef Wolf wrote:
> This can not be replaced by the generic netcfg with netcfg/use_dhcp set
> to "false" or netcfg/disable_dhcp set to "true"?
In theory that could maybe be done (but see below). Also note that setting
an arch-dependent default while still fully supporting preseeding is not
trivial.
> And won't generic netcfg fall back to static when dhcp fails? So even
> the above settings should not be needed, IMHO.
But that does not give give the same functionality. For s390 static
configuration makes the most sense, *even* if there is a DHCP server on
the network.
> What is so special about the s390 that it requires/deserves its own
> netcfg? Why not introduce netcfg-thinkpad or netcfg-eeepc or something?
Because it is exclusively a server platform without any relevant
application in other environments.
> Frans, I have not changed any wireless bits here.
Sorry, I misread the patch.
> I don't really care about netcfg-static. I don't have a s390 and I don't
> know anybody who have one. I just think duplicated code to be a bad
> thing.
OTOH, it just works, so why worry too much about it?
> I get the feeling that there's something wrong. You may argue that
> wireless is not used by s390 anyway, but the bad feeling remains.
Maybe it is wrong, but nobody will ever hit it. IMO it would make sense to
strip all wireless support from -static (if possible).
> > > - while (1) {
> > > + /* Check to see if netcfg should be run at all */
> >
> > [...]
> >
> > On s390 network configuration is required.
>
> But netcfg/enable is set to "true" by default. So I don't see a
> functional change here.
Sure, there's no real functional change, but it's also not a necessary
change.
> I did not know that netcfg-static is for s390 only and that
> dhcp don't work on s390. But my original question remains: are there any
> reasons _not_ to replace netcfg-static by generic netcfg?
One reason is to avoid needless inclusion of the dhcp3-client-udeb in the
s390 initrds. Another is to not complicate the code by needing different
defaults for static/dhcp.
I'm not saying that a cleanup of -static may not be useful, but it should
only be done with a proper appreciation of how its used. And dropping it
is more work than you might think.
Reply to: