Renaming of devices in 2.6.31

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Renaming of devices in 2.6.31

Michael 'Mickey' Lauer-2
Hi folks,

I have seen some questionable renaming of platform devices in kernel
2.6.31 and want to know your reasoning behind things like

gta02-pm-bt.0     gta02-pm-gps.0    gta02-pm-gsm.0  and gta02-vibrator

which is obviously incorrect as the same devices exist on the Neo1973
(gta01, if you remember...) as well.

Can you please rename this back to the original name?

--
:M:


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 'Mickey' Lauer wrote:

> Hi folks,
>
> I have seen some questionable renaming of platform devices in
> kernel 2.6.31 and want to know your reasoning behind things like
>
> gta02-pm-bt.0     gta02-pm-gps.0    gta02-pm-gsm.0  and
> gta02-vibrator
>
> which is obviously incorrect as the same devices exist on the
> Neo1973 (gta01, if you remember...) as well.
>
> Can you please rename this back to the original name?
>
Hi

Yeay, this is an historically grown issue. And I've already said that
in retrospect it was stupid.

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.
gta02-vibrator is called gta02::vibrator. And this will stay.

- - Lars

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJcqIACgkQBX4mSR26RiNU6QCfeYe8G9moMSCPExYhjwnsVtRx
UMkAnRHEC4Xg9kkgmG8F7R0gaEiSSg8L
=Czc8
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Michael 'Mickey' Lauer-2
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?

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

Thanks,

--
:M:


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJdxUACgkQBX4mSR26RiMmwgCcCGn084Vbo4lHO83xEovg4S8h
MVcAn13TkBtYElkJo8MNrYFWsPAAxEwK
=ermj
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Joerg Reisenweber
[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
:-(
You're aware of  http://wiki.openmoko.org/wiki/GTA02_sysfs ?


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

/j

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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  http://wiki.openmoko.org/wiki/GTA02_sysfs ?
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 and
from a userspace perspective it shouldn't matter whether the it's call
neo1973::vibrator gta01::vibrator or ldksaldwaieaz::vibrator

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJvo0ACgkQBX4mSR26RiMBSwCfa81w5ti7xxS797VGXirm4Da7
qE8AnjVT3UPOvy22lXsoxjzpLIpuvRw/
=uf/9
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Michael 'Mickey' Lauer-2
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  http://wiki.openmoko.org/wiki/GTA02_sysfs ?
> 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.

--
:M:


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael 'Mickey' Lauer wrote:

> 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  http://wiki.openmoko.org/wiki/GTA02_sysfs ?
>> 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?
You are free to do that.


The naming spec for leds can be found at:
http://www.mjmwired.net/kernel/Documentation/leds-class.txt

>> 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.
Uhm... In case you missed the pattern: "*::vibrator"

- - Lars

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJx+oACgkQBX4mSR26RiPqtQCffHT7pbPBsgf0D8+T8RmNM5Ic
JjcAn2B+XH1nhOJg1dAx5yvJPq4/2V3r
=ebT6
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Michael 'Mickey' Lauer-2
Am Montag, den 23.11.2009, 00:23 +0100 schrieb Lars-Peter Clausen:

> > "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.
> Uhm... In case you missed the pattern: "*::vibrator"

Ah, right, I can just rewrite everything to use suffixes and crawl
through the whole sysfs on startup to catch up with this renaming dance.

</irony>

--
:M:


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Michael 'Mickey' Lauer-2
In reply to this post by Lars-Peter Clausen
Am Montag, den 23.11.2009, 00:23 +0100 schrieb Lars-Peter Clausen:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael 'Mickey' Lauer wrote:
> > 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  http://wiki.openmoko.org/wiki/GTA02_sysfs ?
> >> 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?
> You are free to do that.
>
>
> The naming spec for leds can be found at:
> http://www.mjmwired.net/kernel/Documentation/leds-class.txt

Ok, I have read this. Twice to make sure I don't overlook anything.
Nowhere does it says that on an UmbaUmba Phone the vibrator needs to be
called UmbaUmba::vibrator. The line you are probably referring to is

"devicename:colour:function"

What 'devicename' reflects to is up to interpretation, in my opinion it
does not mean the device as a whole (UmbaUmba Phone), but rather the
peripheral device (FooBarCustomChip). As such, the same vibrator device
can be found in gta01 and gta02, hence needs to have the same name.

Richard, excuse me for disturbing you, but we need some advice here. As
the LED class maintainer, could you give your opinon on renaming those
class devices? The thread starts w/
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-November/010717.html

Thanks,

--
:M:


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
In reply to this post by Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Westerhof wrote:

> Lars-Peter Clausen wrote:
>
>>>> 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.
>>>> 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
>
> This is all quite ridiculous -- so in addition to having to know
> the underlying machine (gta01 vs gta02), now userspace has to know
> what kernel version?  So all userspace apps now have to have a huge
> nested case structure to select the correct sysfs interface, based
> on the machine and the kernel version as well.
The second person who apparently missed pattern... "*::vibrator"
This will even work for non gta phone which use - to quote mickey -
"the _same_ interface and semantics".
>
> This is simply wrong.  A vibrator is a vibrator - call it
> gta0x::vibrator if you must.  And there's no need to change the
> other interfaces, and break userspace for numerous packages if the
> change is for no other reason than for the kernel tidiness.
> Compatibility DOES matter -- or will you next be removing all those
> ioctls that nobody seems to like and all the other "old" stuff in
> the kernel?  Of course you won't -- and neither should anyone mess
> with the established sysfs names for this device.
Yes, indeed breaking api is a really bad thing to do, I agree. But
sometimes you have to do it, because the old api is just stupid and
broken. And the number of applications using the gta01/gta02 sysfs api
is fairly small, so it shouldn't be to much of a problem patching them.
Btw. I wrote a mail about it a few months ago and nobody complained.


And if everything turns out according to plan there will even be a
neo1973-compatd which will provide the old names for applications that
cannot be changed. (Like gilln)

Furthermore nobody is forced to use 2.6.31. You can still stick with
andy-tracking or even apply your own patches on top of it
reestablishing the good old device name order.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJznYACgkQBX4mSR26RiMDugCfdje91SBA3Y5hURRc4WcHNekY
+FQAn11hNLLeOiTYMNBnQY5NLX10ajb2
=dJSQ
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Mike Westerhof
Lars-Peter Clausen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike Westerhof wrote:
>> Lars-Peter Clausen wrote:
>>
>>>>> 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.
>>>>> 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
>> This is all quite ridiculous -- so in addition to having to know
>> the underlying machine (gta01 vs gta02), now userspace has to know
>> what kernel version?  So all userspace apps now have to have a huge
>> nested case structure to select the correct sysfs interface, based
>> on the machine and the kernel version as well.
> The second person who apparently missed pattern... "*::vibrator"

Not missed at all -- a) that is a but a single example, and in the
general case it doesn't scale, and b) it still results in user-space
needing to be changed to work with the new kernel, for no reason other
than kernel "pretty-ness".


> This will even work for non gta phone which use - to quote mickey -
> "the _same_ interface and semantics".
>> This is simply wrong.  A vibrator is a vibrator - call it
>> gta0x::vibrator if you must.  And there's no need to change the
>> other interfaces, and break userspace for numerous packages if the
>> change is for no other reason than for the kernel tidiness.
>> Compatibility DOES matter -- or will you next be removing all those
>> ioctls that nobody seems to like and all the other "old" stuff in
>> the kernel?  Of course you won't -- and neither should anyone mess
>> with the established sysfs names for this device.
> Yes, indeed breaking api is a really bad thing to do, I agree. But
> sometimes you have to do it, because the old api is just stupid and
> broken. And the number of applications using the gta01/gta02 sysfs api
> is fairly small, so it shouldn't be to much of a problem patching them.
> Btw. I wrote a mail about it a few months ago and nobody complained.

And on this very same mailing list, I argued about this sort of
gratuitous kernel api changing with Andy Green.  So if, as you imply,
arguments are strengthened by age, then my arguments against this sort
of thing clearly predate your email by many many months and trump your
email.  But of course that's just silly, so your statement about a mail
a few months ago has no value as far as the validity/invalidity of your
argument. :)

> And if everything turns out according to plan there will even be a
> neo1973-compatd which will provide the old names for applications that
> cannot be changed. (Like gilln)

Oh goody.  Even MORE stuff!  Again, this misses the fundamental point -
userspace needs to be changed in order to accommodate this kernel
"Pretty-up".  A new daemon, to take up flash space, and consume CPU, and
 generally unnecessarily crud up user-space -- and it's a distro change
as well!  All for the sake of pretty.

> Furthermore nobody is forced to use 2.6.31. You can still stick with
> andy-tracking or even apply your own patches on top of it
> reestablishing the good old device name order.

So at this point in your argument, you are basically saying "S*** you if
you don't like it go fork the kernel!" -- that's rather arrogant, isn't
it?  That's hardly the way to resolve a problem.  I'm sorry you feel
that way.  I guess we'll have to take up this argument on LAKL when you
submit this?

Meh, it probably isn't worth it.  At least not to me; just another
example of kernel silliness that just makes dealing with kernel upgrades
in Linux far more difficult than it has to be.  Oh well.

By-the-way, if you feel so strongly about the "prettyness" of the names,
perhaps you should fork the kernel for yourself?  Why impose your
arbitrary judgement that this is a break in compatibility that is Good,
while the others we've already noted are ok to keep?  (Pardon me if I
don't recognize your qualification in making that kernel decision; I
honestly don't keep up with the who's-who in kernel development beyond
knowing that Linus is god.)

-Mike (mwester)

Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Richard Purdie-3
In reply to this post by Michael 'Mickey' Lauer-2
On Mon, 2009-11-23 at 00:48 +0100, Michael 'Mickey' Lauer wrote:

> Am Montag, den 23.11.2009, 00:23 +0100 schrieb Lars-Peter Clausen:
> > The naming spec for leds can be found at:
> > http://www.mjmwired.net/kernel/Documentation/leds-class.txt
>
> Ok, I have read this. Twice to make sure I don't overlook anything.
> Nowhere does it says that on an UmbaUmba Phone the vibrator needs to be
> called UmbaUmba::vibrator. The line you are probably referring to is
>
> "devicename:colour:function"
>
> What 'devicename' reflects to is up to interpretation, in my opinion it
> does not mean the device as a whole (UmbaUmba Phone), but rather the
> peripheral device (FooBarCustomChip). As such, the same vibrator device
> can be found in gta01 and gta02, hence needs to have the same name.
>
> Richard, excuse me for disturbing you, but we need some advice here. As
> the LED class maintainer, could you give your opinon on renaming those
> class devices? The thread starts w/
> http://lists.openmoko.org/pipermail/openmoko-kernel/2009-November/010717.html

Once devices have a name I generally advise people to stick with it.

The devicename is there simply so you can tell different LEDs apart. For
example, when you plug in a USB device with LEDs, you can tell them
apart from some other LEDs just by looking at the names (in that example
you can also look at the bus the device would be connected to). It also
helps me with bug reports :).

I'd expect that userspace is only ever interested in finding any
vibrator which it can easily do easily with a wildcard search
(/sys/class/leds/*:*:vibrator). Anyone encoding full device names in
their driver code probably shouldn't be. The location to look for these
things is fixed and the format well defined so there shouldn't be a
problem.

Note that the sysfs people hate me for this. They would want you to go
through each directory in /sys/class/leds/ opening
the /sys/class/leds/*/function file and reading it to find what you
want. So it could be much worse!

Cheers,

Richard




Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
In reply to this post by Mike Westerhof
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Westerhof wrote:

> Lars-Peter Clausen wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Mike Westerhof wrote:
>>> Lars-Peter Clausen wrote:
>>>
>>>>>> 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.
>>>>>> 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
>>> This is all quite ridiculous -- so in addition to having to
>>> know the underlying machine (gta01 vs gta02), now userspace has
>>> to know what kernel version?  So all userspace apps now have to
>>> have a huge nested case structure to select the correct sysfs
>>> interface, based on the machine and the kernel version as well.
>>>
>> The second person who apparently missed pattern... "*::vibrator"
>
> Not missed at all -- a) that is a but a single example, and in the
> general case it doesn't scale, and b) it still results in
> user-space needing to be changed to work with the new kernel, for
> no reason other than kernel "pretty-ness".
>
>
Oh boy... If your distro wants to ship 2.6.31 then it should add an
initscript creating a softlink.
This whole discussion about the vibrators sysfs name is just pure
nonsense. If you think it's a problem for your userspace you'll have
to apply a two liner patch to your kernel before compiling it.

>> This will even work for non gta phone which use - to quote mickey
>> - "the _same_ interface and semantics".
>>> This is simply wrong.  A vibrator is a vibrator - call it
>>> gta0x::vibrator if you must.  And there's no need to change the
>>>  other interfaces, and break userspace for numerous packages if
>>> the change is for no other reason than for the kernel tidiness.
>>>  Compatibility DOES matter -- or will you next be removing all
>>> those ioctls that nobody seems to like and all the other "old"
>>> stuff in the kernel?  Of course you won't -- and neither should
>>> anyone mess with the established sysfs names for this device.
>> Yes, indeed breaking api is a really bad thing to do, I agree.
>> But sometimes you have to do it, because the old api is just
>> stupid and broken. And the number of applications using the
>> gta01/gta02 sysfs api is fairly small, so it shouldn't be to much
>> of a problem patching them. Btw. I wrote a mail about it a few
>> months ago and nobody complained.
>
> And on this very same mailing list, I argued about this sort of
> gratuitous kernel api changing with Andy Green.  So if, as you
> imply, arguments are strengthened by age, then my arguments against
> this sort of thing clearly predate your email by many many months
> and trump your email.  But of course that's just silly, so your
> statement about a mail a few months ago has no value as far as the
> validity/invalidity of your argument. :)
>
>> And if everything turns out according to plan there will even be
>> a neo1973-compatd which will provide the old names for
>> applications that cannot be changed. (Like gilln)
>
> Oh goody.  Even MORE stuff!  Again, this misses the fundamental
> point - userspace needs to be changed in order to accommodate this
> kernel "Pretty-up".  A new daemon, to take up flash space, and
> consume CPU, and generally unnecessarily crud up user-space -- and
> it's a distro change as well!  All for the sake of pretty.
>
And updating the kernel isn't a distro change?
As I said in my previous mail: I'm fully aware that this changes
create complications for userspace applications and it hurts doing so.
I also said that it was the lesser evil for me.

>> Furthermore nobody is forced to use 2.6.31. You can still stick
>> with andy-tracking or even apply your own patches on top of it
>> reestablishing the good old device name order.
>
> So at this point in your argument, you are basically saying "S***
> you if you don't like it go fork the kernel!" -- that's rather
> arrogant, isn't it?  That's hardly the way to resolve a problem.
> I'm sorry you feel that way.  I guess we'll have to take up this
> argument on LAKL when you submit this?
>
> Meh, it probably isn't worth it.  At least not to me; just another
> example of kernel silliness that just makes dealing with kernel
> upgrades in Linux far more difficult than it has to be.  Oh well.
>
> By-the-way, if you feel so strongly about the "prettyness" of the
> names, perhaps you should fork the kernel for yourself?
I already did that half a year ago. The result is what this discussion
is about.
> Why impose your arbitrary judgement that this is a break in
> compatibility that is Good, while the others we've already noted
> are ok to keep?  (Pardon me if I don't recognize your qualification
> in making that kernel decision; I honestly don't keep up with the
> who's-who in kernel development beyond knowing that Linus is god.)
>
> -Mike (mwester)

- - Lars

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJ4qcACgkQBX4mSR26RiODjwCfYWP71v99mMoHdzLuZAKuvFwb
uTAAn3SETdTQfx6by2PDqowk9nayH8SQ
=ur24
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Werner Almesberger
In reply to this post by Lars-Peter Clausen
Lars-Peter Clausen wrote:
> No gta01 has gta01::vibrator

I actually like this much better than the old approach of trying to
come up with a permanent name that would encompass the whole range
of devices with such a subsystem.

If a new device joins the club, the structure of the kernel names
can stay the same, just user space needs to adapt the basename for
the respective device.

Not that the idea of having good permanent names wouldn't have its
appeal, but experience has shown that most of the names one comes
up with, despite the best intentions end up being neither good nor
particularly permanent.

However, I don't see a reason for not communicating such changes to
user space developers as soon as the changes are pushed. Leaving
them as "surprises" for people to discover on their own can only
cause confusion and wasted time.

- Werner

Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Carl-Daniel Hailfinger-2
In reply to this post by Lars-Peter Clausen
On 23.11.2009 02:17, Lars-Peter Clausen wrote:

> Mike Westerhof wrote:
> > Lars-Peter Clausen wrote:
> >> Mike Westerhof wrote:
> >>>
> >>> This is all quite ridiculous -- so in addition to having to
> >>> know the underlying machine (gta01 vs gta02), now userspace has
> >>> to know what kernel version?  So all userspace apps now have to
> >>> have a huge nested case structure to select the correct sysfs
> >>> interface, based on the machine and the kernel version as well.
> >>>
> >> The second person who apparently missed pattern... "*::vibrator"
> > Not missed at all -- a) that is a but a single example, and in the
> > general case it doesn't scale, and b) it still results in
> > user-space needing to be changed to work with the new kernel, for
> > no reason other than kernel "pretty-ness".
>
> Oh boy... If your distro wants to ship 2.6.31 then it should add an
> initscript creating a softlink.

Did you know that Linus himself has declared that kernel upgrades should
not break userspace regardless of how twisted, buggy or crappy the
userspace is? Even if the userspace in question relies on an
undocumented kernel bug, fixing that kernel bug has to happen in a way
that won't break userspace assumptions. LKML archives have the flamewar
from a few weeks ago in all its beauty. A few other mails from Linus
(different threads, much older) state that a kernel upgrade should not
break an installed distribution.

Just FYI.

Regards,
Carl-Daniel
--
Developer quote of the month:
"We are juggling too many chainsaws and flaming arrows and tigers."


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carl-Daniel Hailfinger wrote:

> On 23.11.2009 02:17, Lars-Peter Clausen wrote:
>> Mike Westerhof wrote:
>>> Lars-Peter Clausen wrote:
>>>> Mike Westerhof wrote:
>>>>> This is all quite ridiculous -- so in addition to having to
>>>>>  know the underlying machine (gta01 vs gta02), now
>>>>> userspace has to know what kernel version?  So all
>>>>> userspace apps now have to have a huge nested case
>>>>> structure to select the correct sysfs interface, based on
>>>>> the machine and the kernel version as well.
>>>>>
>>>> The second person who apparently missed pattern...
>>>> "*::vibrator"
>>> Not missed at all -- a) that is a but a single example, and in
>>> the general case it doesn't scale, and b) it still results in
>>> user-space needing to be changed to work with the new kernel,
>>> for no reason other than kernel "pretty-ness".
>> Oh boy... If your distro wants to ship 2.6.31 then it should add
>> an initscript creating a softlink.
>
> Did you know that Linus himself has declared that kernel upgrades
> should not break userspace regardless of how twisted, buggy or
> crappy the userspace is? Even if the userspace in question relies
> on an undocumented kernel bug, fixing that kernel bug has to happen
> in a way that won't break userspace assumptions. LKML archives have
> the flamewar from a few weeks ago in all its beauty. A few other
> mails from Linus (different threads, much older) state that a
> kernel upgrade should not break an installed distribution.
>
> Just FYI.
>
> Regards, Carl-Daniel
Yes I did.

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksJ8/gACgkQBX4mSR26RiNVnwCfWPBmsEKoyq8WDQFmOwe2POfC
94AAn3UuFd3Rg94aTVICxTt3DctxSfMr
=Woej
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Radek Polak
In reply to this post by Carl-Daniel Hailfinger-2
Carl-Daniel Hailfinger wrote:

> Did you know that Linus himself has declared that kernel upgrades should
> not break userspace regardless of how twisted, buggy or crappy the
> userspace is?

I think this should imply for mainline kernels.

I spent like 5 hours udating QtMoko distro to these new sysfs paths. I
did it also when switching from 2.6.24->2.6.29 and if this is the last
time i had to do this it's not such problem for me.

Please, let's fix suspend/resume and other problems first and then talk
about sysfs paths.

Regards

Radek


Reply | Threaded
Open this post in threaded view
|

Re: Renaming of devices in 2.6.31

Klaus 'mrmoku' Kurzmann
On Mon, 23 Nov 2009, Radek Polak wrote:

> Carl-Daniel Hailfinger wrote:

> > Did you know that Linus himself has declared that kernel upgrades should
> > not break userspace regardless of how twisted, buggy or crappy the
> > userspace is?

> I think this should imply for mainline kernels.

> I spent like 5 hours udating QtMoko distro to these new sysfs paths. I
> did it also when switching from 2.6.24->2.6.29 and if this is the last
> time i had to do this it's not such problem for me.
which is possible for you, because QtMoko is a distro and you determine
which kernel to use. FSO is aiming to be compatible with all the
different kernel versions out there. And that is getting difficult when
the interface to the kernel is changing...

> Please, let's fix suspend/resume and other problems first and then talk
> about sysfs paths.

> Regards

> Radek

--
Klaus 'mrmoku' Kurzmann