Hi Jens,
There is one part of the block layer I'm having trouble completely
understanding (well there are loads really, but right now there's one in
particular :)):
Do block drivers need to watch out for requests that aren't "normal"
reads and writes? The MMC block driver has a funky prepare function
that checks for FS and PC requests and discards anything else. I
believe this is wrong in two regards:
a) PC requests seem to be prepared SCSI cmds, and the MMC driver just
expects normal transfer requests. Therefore, such requests should not
be accepted by this driver.
b) The block layer won't throw weird stuff at us unless explicitly told
so. I.e. a normal block queue will only produce normal FS requests.
Please educate the masses. :)
(I've cc:d Alex as he copied the MMC block driver for the MemoryStick
code, so he's probably also interested in this)
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Thu, Aug 14 2008, Pierre Ossman wrote:
> Hi Jens,
>
> There is one part of the block layer I'm having trouble completely
> understanding (well there are loads really, but right now there's one in
> particular :)):
>
> Do block drivers need to watch out for requests that aren't "normal"
> reads and writes? The MMC block driver has a funky prepare function
> that checks for FS and PC requests and discards anything else. I
> believe this is wrong in two regards:
You should check in the driver whether the request type is supported. So
if you can only handle fs requests, you should do a check for
!blk_fs_request() after elv_next_request() and call
end_(de)queued_request() appropriately.
> a) PC requests seem to be prepared SCSI cmds, and the MMC driver just
> expects normal transfer requests. Therefore, such requests should not
> be accepted by this driver.
Yes, that is correct. A PC request is essentially a SCSI command sent
directly.
> b) The block layer won't throw weird stuff at us unless explicitly told
> so. I.e. a normal block queue will only produce normal FS requests.
Normal IO activity will only produce fs requests. However, if someone
uses eg SG_IO on your block device, you will be sent pc requests. There
are no checks for this, it is left to the driver.
--
Jens Axboe
On Thu, 14 Aug 2008 13:42:09 +0200
Jens Axboe <[email protected]> wrote:
>
> You should check in the driver whether the request type is supported. So
> if you can only handle fs requests, you should do a check for
> !blk_fs_request() after elv_next_request() and call
> end_(de)queued_request() appropriately.
>
So killing off the request with -EOPNOTSUPP is preferred over having a
prepare function and stopping it there?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
On Thu, Aug 14 2008, Pierre Ossman wrote:
> On Thu, 14 Aug 2008 13:42:09 +0200
> Jens Axboe <[email protected]> wrote:
>
> >
> > You should check in the driver whether the request type is supported. So
> > if you can only handle fs requests, you should do a check for
> > !blk_fs_request() after elv_next_request() and call
> > end_(de)queued_request() appropriately.
> >
>
> So killing off the request with -EOPNOTSUPP is preferred over having a
> prepare function and stopping it there?
Nope, that doesn't matter. If you already have a prep function, using
BLKPREP_KILL is the easiest solution.
--
Jens Axboe