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

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]

Date:	Wed, 04 Apr 2007 02:03:54 -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] Stop pmac_zilog from abusing 8250's device numbers.

On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > Why? What's so special about the name 'ttyS'?
> 
> It's the name that users of Linux expect built-in serial ports to have.

Not really. The norm under Linux is for non-8250 ports to use
properly-registered device numbers and names. There's not many which are
still broken in this respect -- it's basically pmac_zilog and some Sun
UARTs, isn't it?

And even if it _were_ true, it wouldn't be a particularly good reason
for changing the way we handle serial ports under Linux.

> > > The built-in ports can generally be enumerated early on boot in a
> > > stable order, and they should be assigned the low ttySn numbers,
> > > regardless of what chip is used to implement them. 
> > 
> > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > on most supported platforms -- we have separate device numbers, and
> > names, for most types of ports. There's only one or two drivers which
> > abuse ttySn for anything other than 8250 ports.
>
> It 'should' be the case because that is what is easiest for users and
> makes most sense from a user's point of view.

I really don't buy that argument. People cope perfectly well
with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
an 8250, it doesn't usually get called ttyS0. There's certainly nothing
_easier_ about ttyS0. Unless it's really an effort to type that extra
character :)

> You still haven't given any reason why a user should have to know or
> care whether the built-in serial ports on his/her computer are
> implemented with a 16C550 chip or a Z85C30 chip or something else.

Because that's the way serial ports are named under Linux. If you want
to change that, then take it up with the serial maintainer -- but
pmac_zilog as it is upstream at the moment is just _broken_. The module
just doesn't load if you have 8250 built in or loaded. That's what you
get when you abuse device numbers belonging to another driver.

> In any case your patch is a user-visible incompatible API change and
> will break existing working setups, so it should only be put in after
> suitable warning has been given.  Maybe we need a module parameter to
> select between the old and new behaviour to ease the transition.

Perhaps that's true; I'd certainly never seen a working setup with
pmac_zilog, because I'd never actually seen the module load. It's always
failed for me, because I have 8250 support built in to my kernels.

-- 
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/