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)