linux-kernel - Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers; optionally.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1175777154.2719.14.camel@shinybook.infradead.org>
Date:	Thu, 05 Apr 2007 08:45:53 -0400
From:	David Woodhouse <dwmw2@...radead.org>
To:	Paul Mackerras <paulus@...ba.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Brad Boyer <flar@...andria.com>, linuxppc-dev@...abs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] Stop pmac_zilog from abusing 8250's device numbers;
	optionally.

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/