Renaming of devices in 2.6.31

[Lars-Peter Clausen]

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