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