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

Paul Mackerras
2007-04-04T06:31:28Z

David Woodhouse writes:

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

Those are embedded platforms and therefore don't have users who aren't
developers interacting with it as a general-purpose computer.

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

In other words we're too lame to abstract the hardware properly and
users just have to deal with it...

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

You probably don't have a powermac or powerbook that has usable,
externally accessible serial ports either. Plenty of other people do.

It seems Debian has both 8250 and pmac_zilog built in; not sure which
one wins. Ubuntu has them both as modules and managed to get the
right one (pmac_zilog) loaded on a colleague's powerbook. You'd know
better than me what FC does.

In any case there definitely are people using pmac_zilog successfully
on powermacs and we need to come up with a way to avoid breaking their
setups. I'm prepared to accept that the Linux way is to be lame about
serial port naming provided that we avoid breaking existing working
setups.

Paul.