Hi On Fri, Apr 17, 2009 at 12:40 PM, Tejun Heo <htejun@xxxxxxxxx> wrote: > Tejun Heo wrote: >> I don't really care one way or the other but the error condition >> itself looked somewhat pointless to me, so I just killed it. Is the >> error messasge really worth guaranteeing drive->pc can be accessed >> after completion? That's a nasty and fragile guarantee. If such >> check is really necessary, the proper way to do it would be recording >> whether the last command was request sense in some persistent data >> structure not trying to access a data structure which the code doesn't >> own anymore. Honestly, I don't know. The code predates even the initial git commit of the kernel so I guess nobody knows? And yeah, such a check looks a bit too much so I won't have any problem with removing it. Nevertheless, we need the small fix above in the ->do_request callback for all other packet commands since ide-tape uses currently ide_queue_pc_tail() for sending those. I know, I know, it is ugly and we're working on it :). > Yet another problem is that idetape_flush_tape_buffers() uses pc which > is on stack which drive->pc ends up pointing directly to, so it won't > work. Nobody expects that the pointer it passed into an API should be > accessible by the API implementation after it was done with it. > That's just a silly thing to do. The whole on stack passing should be passé :) soon since we're about to kill those ide_atapi_pc's. As I said before, this is very old code that is really rusty and we're trying to janitor it slowly. -- Regards/Gruss, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
