Sean McNeil wrote: > Hi Mike, > > Once again you get totally pissed off without explanation.
I explained it -- what do you not understand about ABI compatability? You are proposing to break existing software. That's not cause for concern? > As stated by > Andy, most software stacks use the sysfs value to get the > max_brightness. Tell us what breaks? No - if YOU want to change this, then YOU tell us why it WON'T break. Right now YOU represent ONLY YOUR user-space apps -- that's not adequate. And no, the fact is that the requirement to use max_brightness is NOT well known, or well documented -- and not all the distros use it. Should they? That's a different question. Just because you have excellent control over YOUR user space does not entitle you or Om to make this sort of change with ONLY your input! Other existing distros, ESPECIALLY the ones that actually out in common use (!) should also be considered. > If it is new code, why not check > max_brightness? Yes, ****NEW*** code should do this. But hey! News flash! There is EXISTING code for these devices, and it doesn't do that!!! It's unfortunate that I seem to be the only one advocating for that community... (OOPS! But then since this ABI change was ONLY posted to the kernel list, I guess maybe it isn't so surprising there are no objections... Hmmm.... could there be a process problem here?) > 0-63 for brightness? Come on, anyone hard-coding for > this is guaranteed not to be portable to other platforms - even GTA03 > possibly. 0-255, however, has been in many kernels, for many years and > has been thought to be a safe assumption. Come on, ABI changes are ABI changes and it matters not how stupid or irrational the original ABI might have been. The reasonableness of the value is not the point, and you know it. (although why not 63? It makes as much sense to the typical developer as any of the other numerous values passed into APIs of all sorts.) > So, explain yourself and stop ranting No. I might as well ask you to stop advocating your distro/company. We both have an interest in this, and my voice is no less important than yours. (I don't know who you are -- perhaps you represent one of the major Linux distros with a almost-ready-for-market project that will propel the vision of Openmoko forward? In that case, I happily defer to you. But right now, you are just an individual lobbying for your personal position, just as I am.) > What will break? Sorry, that's NOT how ABI's work. YOU tell me what will work, and how it will be remediated, and preferably have the distro managers for the affected software chime in to support the ABI breakage with a plan. In this, doing that should be trivial. But for some reason, even in trivial cases like this, NOBODY in Om "Kernel-land" seems to see fit to even consider the user apps! (You aside, Sean -- you are doing an excellent job in representing your distro/company's needs, and the other Om distros should use your active involvement as an example.) > I wanted a > #define so I could build a kernel for any desired max. Andy thinks we > should just go with what is a de-facto standard. Either is OK with me. Then we don't have an issue, do we? Seems that if someone doesn't like the #define (defaulting to the current value), then they should explain why it should be changed. Like I said, this should be trivial -- there's only 8 (or maybe 9 since I heard of another new one this week) distros for the devices, and a few wiki pages -- if someone REALLY wants to change the ABI, it shouldn't be so hard to do it the right way with a quick RFC sent to the appropriate distro mailing lists, etc. I would think that with the new focus Om is claiming, that changes such as this that provide no functionality improvements would be WAY down the priority list, especially when implementing the change might have the impact of negatively affecting ANY user space stuff. We've now invested more time and energy in discussing this than it was worth. I can't see any reason that justifies changing the existing ABI. Regards, Mike (mwester)
