On Tue, Feb 12, 2008 at 10:39:22PM +0100, Bartlomiej Zolnierkiewicz wrote:
Hi Bart,
> I think that this _really_ should be done _after_ unifying ATAPI handling [*].
> Otherwise you will be making some of the same changes to the _three_ copies
> of (more or less) identical code and more importantly we will have to delay
> unification after _all_ drivers are converted to rq->cmd[] (+ lets not forget
> that I'll have more changes to review ;).
>
> (*) please take a closer look at *_issue_pc(), *_transfer_pc() and *_pc_intr()
> in ide-{floppy,tape,scsi} (the useful hint is that after making these
> functions free of references to device driver specific objects/functions
> we can use drive->media == ide_{floppy,tape,scsi} checks for handling
> not yet fully unified / media type specific code).
I started working on probably the easiest unification we could do: unify all the
pc->flags defines and move them in a header where all drivers can use them. This
raises an architectural design question: The way i see it, the generic ATAPI handling
is going to be sort of "serving" functionality to the drivers using ATAPI. Do we want
all this functionality to go to ide.{h,c} or we want specific atapi.{h,c} files that
contain only this unified functionality, or whatever else. In general, how is this
generic layer going to be distributed among headers/.c files and what do we want there?
/me tends to think that special headers/files, small and easy to manage and
modular, have more advantages in this case but this is just me. After we've
decided on that, the rest of the issues will resolve by themselves/get easier to
tackle.
Thanks.
--
Regards/Gruß,
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
