[PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

[David Woodhouse]

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