Re: RFC: ACPI/scsi/libata integration and hotswap

[Erik Slagter <erik@slagter.name>]

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