On Wed, 08 Aug 2007 14:22:20 +0100
David Vrabel <[email protected]> wrote:
>
> Setting the block size in io_rw_ext_helper() has several drawbacks,
> namely:
>
> 1. Reduces the flexibility of drivers to manage what commands are
> performed. 2. A performance penalty on the first transfer.
> 3. Greater code complexity.
> 4. Non-intuitive location for card initialization code.
>
> Sure we could just through hoops and add (much) extra complexity to
> the core, to improve item 1 but 2, 3 and 4 are insoluble. Given that
> setting block size before the first command has /zero/ benefits[1],
> why bother?
3 and 4 are subjective, and for 2, the performance penalty has to come
some place. The upside, as explained, is that drivers aren't penalized
for setting the block size and then failing to use it. Something that
gives us the flexibility to write cleaner code.
As for benefits, there are other issues. We might want to deal with
things like alignment problems in the future.
>
> Your insistence on this stupid idea baffles me, particularly in the
> light of your other useful comments.
>
> I would also like to advise that until a larger number of function
> drivers become available that the core is kept as simple and as
> flexible as possible. Without knowing how different cards operate it
> is difficult to know what's common behaviour and what's card specific.
>
Agreed, we're doing a bit more guessing than one would like. But I
don't agree in keeping the core simple and flexible. Rather the
opposite. Any guarantee that we give drivers now and need to remove in
the future needs to be tested with all drivers that rely on it (a
difficult task as it often takes some effort to find people with
hardware and the ability to test patches).
As such, the guarantees should be kept at a minimum. Code is easily
changed, API is not.
IMO, the best way to achieve this is with an API that describes _what_
the drivers want to do, not _how_. Hence my insistence on allowing
drivers to specify the difference between "I want this data
transferred" and "I want this data transferred with an exact block size
of 32 bytes".
> My latest (and hopefully final) patch set follows.
>
These looks good. The only part I'm really attached to is the blksz ==
0 case, which you have.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
