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