On Mon, Jun 06, 2005 at 09:59:39PM +1000, Herbert Xu wrote:
> On Sat, Jun 04, 2005 at 12:58:53PM +0100, Christoph Hellwig wrote:
> >
> > the usage of 16bit counters in bio_vec doesn't make sense, and if did
> > all others would have to move to 32bit aswell (in case we started
> > supporting page sizes that aren't addressable by 16bits)
>
> You know what? The more I think about this the more I think that your
> idea is brilliant. The reason is that the two main users of crypto API
> happen to be in possession of bio_vec and skb_frag_t respectively.
>
> Had we merged the three structures, they would not have to copy the
> structures as they do now or even worse, process the buffers one-by-one
> as dmcrypt is doing.
>
> Back to the topic of 16-bit vs. 32-bit counters. Could we do something
> like this?
>
> #if (PAGE_SHIFT > 16) || (BITS_PER_LONG > 32)
what is the BITS_PER_LONG check for?
> typedef unsigned int page_offset_t
> #else
> typedef unsigned short page_offset_t
> #endif
the name is a) a little long and b) easy to confuse with pgoff_t as used in
the pagecache. I'm not sure what a better name would be.
We probably shouldn't care about this as the networking code didn't handle
larger offsets either.
|