From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: petkovbb@gmail.com
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [RFC PATCH] ide-floppy: use rq->cmd for preparing and sending packet cmds to the drive
Date: Wed, 13 Feb 2008 14:30:16 +0100 [thread overview]
Message-ID: <200802131430.16450.bzolnier@gmail.com> (raw)
In-Reply-To: <20080213124625.GB13446@gollum.tnic>
Hi,
On Wednesday 13 February 2008, Borislav Petkov wrote:
> 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
Yep.
> 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.
I think that:
drivers/ide/ide-atapi.c
include/linux/ide.h
should be fine for now...
Moving code around is trivial so we can always fixup before pushing upstream.
Thanks,
Bart
prev parent reply other threads:[~2008-02-13 13:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-12 14:37 [RFC PATCH] ide-floppy: use rq->cmd for preparing and sending packet cmds to the drive Borislav Petkov
2008-02-12 21:39 ` Bartlomiej Zolnierkiewicz
2008-02-13 12:46 ` Borislav Petkov
2008-02-13 13:30 ` Bartlomiej Zolnierkiewicz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200802131430.16450.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=petkovbb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.