On Fri, 2005-12-09 at 06:27 -0500, Jeff Garzik wrote: > > I perfectly understand that, what I do object against, is rejecting a > > concept (like this) totally because the developers(?) do not like the > > mechanism that's used (although ACPI is used everywhere else in the > > kernel). At least there might be some discussion where this sort of code > > belongs to make the design clean and easily maintainable, instead of > > instantly completely rejecting the concept, because OP simply doesn't > > like acpi. > > Framing the discussion in terms of "like" and "dislike" proves you > understand nothing about the issues -- and lacking that understanding, > you feel its best to insult people. > > libata suspend/resume needs to work on platforms without ACPI, such as > ppc64. libata reset needs to work even when BIOS is not present at all. > And by definition, anything that is done in ACPI can be done in the > driver. > > The only thing libata cannot know is BIOS defaults. Anything else > libata doesn't know is a driver bug. We already know there are a ton of > settings that should be saved/restored, which is not done now. Until > that code is added to libata, talk of ACPI is premature. Further, even > the premature patch was obviously unacceptable, because you don't patch > ACPI code directly into libata and SCSI. That's the wrong approach. I case this (still) isn't clear, I am addressing the attitude of "It's ACPI so it's not going to be used, period". About the exact technical implementation, I do not have an opinion, because I don't have the knowledge. BTW I try to not actually insult people (as others here seems to like to do). If someone really feels offended, my apologies. I cannot hide some irritation though.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
