Re: [PATCH 1/4] scatterlist: new helper functions

[FUJITA Tomonori]

On Sun, 06 Mar 2011 17:14:30 +0200
Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote:

> On Sun, 2011-03-06 at 16:29 +0900, FUJITA Tomonori wrote:
> > On Fri,  4 Mar 2011 06:16:50 +0200
> > Maxim Levitsky <maximlevitsky@xxxxxxxxx> wrote:
> > 
> > > While developing memstick driver for legacy memsticks
> > > I found the need in few helpers that I think should be
> > > in common scatterlist library
> > > 
> > > The functions that were added:
> > > 
> > > * sg_nents/sg_total_len - iterate over scatterlist to figure
> > > out total length of memory it covers / number of entries.
> > 
> > You should invent a data structure per I/O request, something like
> > msb_request structure. Then you can store nents and total_len in
> > that.
> > 
> > That's what block subsystems and drivers do. I took a look at your
> > driver but I can't see why your driver can't do the same.
> I also need to break the request into small grained chunks.
> If I invent such structure, I will end up writing these helpers for it.
> 
> The I have this lifetime of a request:
> 
> I get arbitary sized request from block layer (I can of course control
> maximum size/number of segments in it, etc).
> 
> I break it into eraseblock sized chunks, and for each I translate the
> the LBA, into flash address.
> 
> Then I break it into flash page sized requests (512 bytes), and yet its
> better not to assume that such requests always contained in one sg
> entry.
> 
> Worse than that, I have to pass an sg list that spans always one 512
> page to lowlevel driver, because thats how Alex defined the interface.

This restriction is due to hardware specification or the software
design (e.g. memstick layer)? If it is due to the latter, why can't
you fix that?

Why can't the block layer split requests for you? It's better to let
the block layer handle that.


> Folks, really what the status of this, when to expect it to be merged?
> 
> If you think some of helper functions don't belong to scatterlist.c,
> just tell me to move them back to ms_block.c.
> 
> Andrew, please note again that richoh lowlevel driver doesn't need any
> helper functions, its patch is standalone and thus should be merged
> regardless.

I think that we need to make the design of the driver easily
understandable to kernel developers and maintainable by them. I don't
think that this is 'standalone or not' issue.

Adding a doc about why the driver is designed in such odd way would be
helpful. But I still think that we could design the driver in a better
way.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/