On Thu, 2007-04-05 at 09:48 +1000, Paul Mackerras wrote: > David Woodhouse writes: > > > OK, how about a config option to preserve the old behaviour... > > Well, that's a start but it doesn't provide a migration path. > > Is it possible to have the pmac_zilog ports registered both with the > new number and with the old number (assuming it's not already taken)? > That way people can move over gradually.
The new option was intended to provide a way to retain the old behaviour for systems where the kernel is updated but userspace must remain unchanged (for some reason I can't quite imagine right now). For _migration_, I think we can handle it better in userspace. Anyone who builds their own kernel can also manage to change one or two scripts or configuration files which currently refer to ttyS0. The only case where the question of migration really holds any water is for distributions. In Fedora, pmac_zilog has never worked -- the module always failed to load because 8250 was built-in. So it's an easy choice there -- we just switch over and it's fixed. Other distributions which change over to the fixed behaviour, if they want 8250 and z8530 ports to co-exist, can provide a udev rule which creates a symlink from ttySn->ttyPZ0 for backwards compatibility. Of course, the _numbers_ might change -- a given port might no longer be ttyS0 but ttyS1. But we're happy to overlook that one even though the effect on the user is identical, right? That doesn't address the fact that the 'console=' kernel command line argument needs changes. But in general, users who are that non-technical don't use serial consoles, and those who do can cope with this. I think perhaps we should add this new config option to the feature-removal-schedule right now, and take it out after a year or so. That should be plenty of time for people to upgrade. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
