On 12/9/05, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Fri, Dec 09, 2005 at 12:46:42PM +0100, Jens Axboe wrote: > > On Fri, Dec 09 2005, Erik Slagter wrote: > > > 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". > > > > The problem seems to be that you are misunderstanding the 'attitude', > > which was mainly based on the initial patch sent out which stuffs acpi > > directly in everywhere. That seems to be a good trigger for curt/direct > > replies. > > I was just following the example set by the ide acpi suspend/resume > patch, which people didn't seem to object to nearly as much. I guess > IDE's such a hack anyway that people aren't as worried :) I'll try > produce a patch that just inserts platform-independent code into scsi > around the start of next week. Sigh, it seems this is what you get for being nice... ;) Don't get it wrong IDE people (at least me) are also worried but they know that there are cases in which ACPI support will help (even if the main method should be talking to hardware directly) NOW not in X years when we will have proper, architecture independent suspend/resume handling (we can live with "ide_acpi=on" kernel parameter before it happens happily). I also pointed out that I would like to have generic code which can be shared between libata and IDE drivers (after all both can provide you with struct pci_dev * and port/device number). It would be even better if this code will stay in drivers/acpi/ata.c (?) and libata/IDE will just use the same functions (which will turn to NOP if CONFIG_ACPI=n) for PATA. Thanks, Bartlomiej - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
