On 1/13/2015 7:21 PM, Al Stone wrote: > On 01/12/2015 12:39 PM, Pavel Machek wrote: >> On Mon 2015-01-12 14:41:50, Grant Likely wrote: >>> On Mon, Jan 12, 2015 at 2:23 PM, Pavel Machek <pavel@xxxxxx> wrote: >>>> On Sat 2015-01-10 14:44:02, Grant Likely wrote: >>>>> On Wed, Dec 17, 2014 at 10:26 PM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: >>>>>> On Tue, Dec 16, 2014 at 11:27 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >>>>>>> On Monday 15 December 2014 19:18:16 Al Stone wrote: >>>>>>>> 7. Why is ACPI required? >>>>>>>> * Problem: >>>>>>>> * arm64 maintainers still haven't been convinced that ACPI is >>>>>>>> necessary. >>>>>>>> * Why do hardware and OS vendors say ACPI is required? >>>>>>>> * Status: Al & Grant collecting statements from OEMs to be posted >>>>>>>> publicly early in the new year; firmware summit for broader >>>>>>>> discussion planned. >>>>>>> >>>>>>> I was particularly hoping to see better progress on this item. It >>>>>>> really shouldn't be that hard to explain why someone wants this feature. >>>>>> >>>>>> I've written something up in as a reply on the firmware summit thread. >>>>>> I'm going to rework it to be a standalone document and post it >>>>>> publicly. I hope that should resolve this issue. >>>>> >>>>> I've posted an article on my blog, but I'm reposting it here because >>>>> the mailing list is more conducive to discussion... >>>>> >>>>> http://www.secretlab.ca/archives/151 >>>> >>>> Unfortunately, I seen the blog post before the mailing list post, so >>>> here's reply in blog format. >>>> >>>> Grant Likely published article about ACPI and ARM at >>>> >>>> http://www.secretlab.ca/archives/151 >>>> >>>> . He acknowledges systems with ACPI are harder to debug, but because >>>> Microsoft says so, we have to use ACPI (basically). >>> >>> Please reread the blog post. Microsoft is a factor, but it is not the >>> primary driver by any means. >> >> Ok, so what is the primary reason? As far as I could tell it is >> "Microsoft wants ACPI" and "hardware people want Microsoft" and >> "fragmentation is bad so we do ACPI" (1) (and maybe "someone at RedHat >> says they want ACPI" -- but RedHat people should really speak for >> themselves.) > > I have to say I found this statement fascinating. > > I have been seconded to Linaro from Red Hat for over two years now, > working on getting ACPI running, first as a prototype on an ARMv7 box, > then on ARMv8. I have been working with Grant since very early on when > some of us first started talking about ARM servers in the enterprise > market, and what sorts of standards, if any, would be needed to build an > ecosystem. > > This is the first time in at least two years that I have had someone > ask for Red Hat to speak up about ACPI on ARM servers; it's usually > quite the opposite, as in "will you Red Hat folks please shut up about > this already?" :). > > For all the reasons Grant has already mentioned, my Customers need to > have ACPI on ARM servers for them to be successful in their business. > I view my job as providing what my Customers need to be successful. > So, here I am. I want ACPI on ARMv8 for my Customers. I want that too, even for platforms that might not ever run Windows. -- ljk > >> You snipped quite a lot of reasons why ACPI is inferior that were >> below this line in email. >> >> Pavel >> >> (1) ignoring fact that it causes fragmentation between servers and phones. >> > > I see this very differently. This is a "fact" only when viewed from > the perspective of having two different technologies that can do very > similar things. > > In my opinion, the issue is that these are two very, very different > markets; technologies are only relevant as the tools to be used to be > successful in those markets. > > Just on a surface level, phones are expected to be completely replaced > every 18 months or less -- new hardware, new version of the OS, new > everything. That's the driving force in the market. > > A server does not change that quickly; it is probable that the hardware > will change, but it is unlikely to change at that speed. It can take > 18 months just for some of the certification testing needed for new > hardware or software. Further, everything from the kernel on up is > expected to be stable for a long time -- as long as 25 years, in some > cases I have worked on. "New" can be a bad word in this environment. > > Best I can tell, I need different tool sets to do well in each of these > environments -- one that allows me to move quickly for phones, and one > that allows me to carefully control change for servers. I personally > don't see that as fragmentation, but as using the right tool for the > job. If I'm building a phone, I want the speed and flexibility of DT. > If I'm building a server, I want the long term stability of ACPI. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
