Renaming of devices in 2.6.31

Michael 'Mickey' Lauer mickey at
Sun Nov 22 23:55:34 CET 2009

Am Sonntag, den 22.11.2009, 23:43 +0100 schrieb Lars-Peter Clausen:
> Joerg Reisenweber wrote:
> > [Lars-Peter Clausen So  22. November 2009]:
> >> Michael 'Mickey' Lauer wrote:
> >>> Am Sonntag, den 22.11.2009, 18:19 +0100 schrieb Lars-Peter
> >>> Clausen:
> >>>
> >>>> But: pm-bt is gone anyway pm-gps is gone soon pm-gsm might
> >>>> also go away, but if it's not it'll be renamed back.
> >>> Is anyone preparing a document for the poor userland folks that
> >>>  will get their peripheral control means ripped up side down?
> >> Not yet. But once the kernel work has been done and there are no
> >> more changes to be expected, I guess there will be detailed
> >> information what has changed.
> >
> > Great, so let's stop userland development until that day :-(
> Why do you want to do that?
> > You're aware of ?
> Yes. And I think it's pretty confusing.
> >
> >>>> gta02-vibrator is called gta02::vibrator. And this will stay.
> >>>>
> >>> So gta01 will have a gta02::vibrator, oh well, there's much
> >>> worse things in life than not making sense :)
> >> No gta01 has gta01::vibrator
> >
> > OMG
> I know you can't understand that. But I'm following specs here

I question the sanity of specs that say that a device with the _same_
interface and semantics has to be exposed through different names via
sysfs. Can you point me to the relevant docs, please?

> and
> from a userspace perspective it shouldn't matter whether the it's call
> neo1973::vibrator gta01::vibrator or ldksaldwaieaz::vibrator

"Matter" is relative. It's about being able to rely on what the
kerneprovides to userland or not. The effect is that with this attitude
userland is forced to introduce more files that have to be
handmaintained whenever the chique of the day requires another renaming.

I would understand it if there were any technical necessities for that,
but just because you can or blindly following specs does not make it a
strong point to me.


More information about the openmoko-kernel mailing list