On Fri, Oct 26 2007, Linus Torvalds wrote:
>
>
> On Fri, 26 Oct 2007, Paul Mackerras wrote:
> >
> > Linus Torvalds writes:
> >
> > > Nobody should *ever* walk the list to find the length. Does anybody
> > > really
> > > do that? Yes, we pass the thing down, but do people *need* it?
> >
> > Ye
On Fri, 26 Oct 2007, Paul Mackerras wrote:
>
> Linus Torvalds writes:
>
> > Nobody should *ever* walk the list to find the length. Does anybody really
> > do that? Yes, we pass the thing down, but do people *need* it?
>
> Yes, I need it for devices that use the macintosh DBDMA
> (descriptor-ba
Linus Torvalds writes:
> Nobody should *ever* walk the list to find the length. Does anybody really
> do that? Yes, we pass the thing down, but do people *need* it?
Yes, I need it for devices that use the macintosh DBDMA
(descriptor-based DMA) hardware. The DBDMA hardware reads an array of
desc
On Thursday 25 October 2007 21:54:44 Rusty Russell wrote:
> On Thursday 25 October 2007 19:11:40 Jens Axboe wrote:
> > On Thu, Oct 25 2007, Rusty Russell wrote:
> > > What irritates me more is that scatterlists aren't quite generically
> > > useful. The virtio code wants to join a scatterlist creat
On Oct. 25, 2007, 17:40 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Thu, 25 Oct 2007, Rusty Russell wrote:
>> On Wednesday 24 October 2007 01:22:55 Linus Torvalds wrote:
>>> Well, I'd personally actually prefer to *not* have the count be passed
>>> down explicitly, because it's just to
On Thu, 25 Oct 2007, Rusty Russell wrote:
> On Wednesday 24 October 2007 01:22:55 Linus Torvalds wrote:
> >
> > Well, I'd personally actually prefer to *not* have the count be passed
> > down explicitly, because it's just too error prone.
>
> Well, the duplication is bad, but walking lists to fi
On Thursday 25 October 2007 19:11:40 Jens Axboe wrote:
> On Thu, Oct 25 2007, Rusty Russell wrote:
> > What irritates me more is that scatterlists aren't quite generically
> > useful. The virtio code wants to join a scatterlist created by
> > blk_rq_map_sg() with two others, yet it won't work becau
On Thu, Oct 25 2007, Rusty Russell wrote:
> On Wednesday 24 October 2007 01:22:55 Linus Torvalds wrote:
> > On Tue, 23 Oct 2007, Boaz Harrosh wrote:
> > > But since we do not do that, and every single API in the kernel that
> > > receives a scatterlist pointer also receives an sg_count parameter,
>
On Wednesday 24 October 2007 01:22:55 Linus Torvalds wrote:
> On Tue, 23 Oct 2007, Boaz Harrosh wrote:
> > But since we do not do that, and every single API in the kernel that
> > receives a scatterlist pointer also receives an sg_count parameter,
> > than I do not see what is so hacky about giving
On Wed, 24 Oct 2007, Jens Axboe wrote:
> >
> > As it no longer sets the page only, perhaps it's a good idea to rename
> > sg_set_page() to sg_set()?
>
> sg_set_buf() also sets length and offset, sg_set_page() is just a mirror
> of that. So I'd prefer to keep the naming.
I agree. And it's not l
On Wed, Oct 24, 2007 at 03:38:04PM +0200, Jens Axboe wrote:
> (please don't drop cc lists)
Sorry. Reactions of people to Cc vary...
> That doesn't make any sense. Both sg_set_buf() and sg_set_page() set the
> same thing in the sg entry, the input is just different. It has nothing
> to do with s
On Wed, Oct 24 2007, Olivier Galibert wrote:
> On Wed, Oct 24, 2007 at 11:12:42AM +0200, Jens Axboe wrote:
> > sg_set_buf() also sets length and offset, sg_set_page() is just a mirror
> > of that. So I'd prefer to keep the naming.
>
> Hmmm, sg_set_phys/sg_set_virt to be more symmetrical to
> sg_ph
On Wed, Oct 24, 2007 at 11:12:42AM +0200, Jens Axboe wrote:
> sg_set_buf() also sets length and offset, sg_set_page() is just a mirror
> of that. So I'd prefer to keep the naming.
Hmmm, sg_set_phys/sg_set_virt to be more symmetrical to
sg_phys/sg_virt?
OG.
-
To unsubscribe from this list: send
On Wed, Oct 24 2007, Geert Uytterhoeven wrote:
> On Wed, 24 Oct 2007, Jens Axboe wrote:
> > On Tue, Oct 23 2007, Linus Torvalds wrote:
> > > My biggest complaint right now is that a lot of users of the sg *filling*
> > > functions were mindlessly converted, so we have code like
> > >
> > > cryp
On Wed, 24 Oct 2007, Jens Axboe wrote:
> On Tue, Oct 23 2007, Linus Torvalds wrote:
> > My biggest complaint right now is that a lot of users of the sg *filling*
> > functions were mindlessly converted, so we have code like
> >
> > cryptoloop.c: sg_set_page(&sg_in, in_page);
> >
On Tue, Oct 23 2007, Linus Torvalds wrote:
> My biggest complaint right now is that a lot of users of the sg *filling*
> functions were mindlessly converted, so we have code like
>
> cryptoloop.c: sg_set_page(&sg_in, in_page);
> cryptoloop.c: sg_in.offset = in_
On Tue, Oct 23 2007, Geert Uytterhoeven wrote:
> On Tue, 23 Oct 2007, Ingo Molnar wrote:
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > > Linus' latest tree, which has your SG-list enhancements included,
> > > > certainly works fine here and does not have the problems of the
> > > > first
On Tue, Oct 23 2007, Geert Uytterhoeven wrote:
> On Tue, 23 Oct 2007, Ingo Molnar wrote:
> > * Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > > > Linus' latest tree, which has your SG-list enhancements included,
> > > > certainly works fine here and does not have the problems of the
> > > > first
On Tue, Oct 23 2007, Andi Kleen wrote:
> On Tue, Oct 23, 2007 at 10:20:17PM +0200, Jens Axboe wrote:
> > On Tue, Oct 23 2007, Andi Kleen wrote:
> > > Jens Axboe <[EMAIL PROTECTED]> writes:
> > >
> > > >> You might want to put a BUG_ON(page & 0x3); Make sure
> > > >> you're not loosing information.
On Tue, Oct 23, 2007 at 10:20:17PM +0200, Jens Axboe wrote:
> On Tue, Oct 23 2007, Andi Kleen wrote:
> > Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > >> You might want to put a BUG_ON(page & 0x3); Make sure
> > >> you're not loosing information. (The m68k problem)
> > >
> > > That's a really goo
On Tue, Oct 23 2007, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
>
> >> You might want to put a BUG_ON(page & 0x3); Make sure
> >> you're not loosing information. (The m68k problem)
> >
> > That's a really good idea, thanks Boaz! I'll add that.
>
> It would be even better if you re
Jens Axboe <[EMAIL PROTECTED]> writes:
>> You might want to put a BUG_ON(page & 0x3); Make sure
>> you're not loosing information. (The m68k problem)
>
> That's a really good idea, thanks Boaz! I'll add that.
It would be even better if you replaced all the magic numbers with defines
or better acc
On Tue, 23 Oct 2007, Ingo Molnar wrote:
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > Linus' latest tree, which has your SG-list enhancements included,
> > > certainly works fine here and does not have the problems of the
> > > first iteration.
> >
> > That's good to hear :-)
> >
> > I hav
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Mon, Oct 22 2007 at 20:11 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > Change the page member of the scatterlist structure to be an unsigned
> > long, and encode more stuff in the lower bits:
> >
> > - Bits 0 and 1 zero: this is a normal sg entry.
On Mon, Oct 22 2007 at 20:11 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> Change the page member of the scatterlist structure to be an unsigned
> long, and encode more stuff in the lower bits:
>
> - Bits 0 and 1 zero: this is a normal sg entry. Next sg entry is located
> at sg + 1.
> - Bit 0 s
On Tue, 23 Oct 2007, Boaz Harrosh wrote:
>
> A nice design is to have an struct like BIO. That holds a pointer to the
> array of scatterlists, size, ..., and a next and prev pointers to the next
> chunks. Than have all kernel code that now accepts scatterlist* and size
> accept a pointer to such
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > Linus' latest tree, which has your SG-list enhancements included,
> > certainly works fine here and does not have the problems of the
> > first iteration.
>
> That's good to hear :-)
>
> I have a series of pending patches where I've collected fallou
On Tue, Oct 23 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > It's all about the end goal - having maintainable and resilient code.
> > And I think the sg code will be better once we get past the next day
> > or so, and it'll be more robust. That is what matters to m
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> It's all about the end goal - having maintainable and resilient code.
> And I think the sg code will be better once we get past the next day
> or so, and it'll be more robust. That is what matters to me, not the
> simplicity of the patch itself.
Linus
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Tue, Oct 23 2007 at 11:55 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 23 2007, Boaz Harrosh wrote:
> >> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >>> On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On M
On Tue, Oct 23 2007 at 11:55 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, Boaz Harrosh wrote:
>> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
>>> On Tue, Oct 23 2007, Boaz Harrosh wrote:
On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EM
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 23 2007, Boaz Harrosh wrote:
> >> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]>
> >> wrote:
> >>> On Mon, 22 Oct 2007, Alan Cox wrote:
> >>>
On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, Boaz Harrosh wrote:
>> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>> On Mon, 22 Oct 2007, Alan Cox wrote:
>>>
For structures, not array elements or stack objects
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 22 Oct 2007, Alan Cox wrote:
> >
> >> For structures, not array elements or stack objects. Does gcc now get
> >> aligned correct as an attribute on a stack obje
On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Mon, 22 Oct 2007, Alan Cox wrote:
>
>> For structures, not array elements or stack objects. Does gcc now get
>> aligned correct as an attribute on a stack object ?
>
> I think m68k stack layout still guarantees
On Mon, 22 Oct 2007, Linus Torvalds wrote:
> On Mon, 22 Oct 2007, Alan Cox wrote:
> > For structures, not array elements or stack objects. Does gcc now get
> > aligned correct as an attribute on a stack object ?
>
> I think m68k stack layout still guarantees 4-byte-alignment, no?
The stack pointe
Matt Mackall wrote:
On Mon, Oct 22, 2007 at 11:52:51PM +0100, Alan Cox wrote:
On Mon, 22 Oct 2007 16:47:07 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
On Mon, Oct 22, 2007 at 05:21:30PM -0400, Jeff Garzik wrote:
Alan Cox wrote:
Why can't we just make the list one item longer than the entry
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 14:47:38 -0700 (PDT)
> On Mon, 22 Oct 2007, Alan Cox wrote:
>
> > Still doesn't answer the rather more important question - why not just
> > stick a NULL on the end instead of all the nutty hacks ?
>
> You still do need one bit for
On Mon, Oct 22, 2007 at 11:52:51PM +0100, Alan Cox wrote:
> On Mon, 22 Oct 2007 16:47:07 -0500
> Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Oct 22, 2007 at 05:21:30PM -0400, Jeff Garzik wrote:
> > > Alan Cox wrote:
> > > >Why can't we just make the list one item longer than the entry co
On Mon, 22 Oct 2007 16:47:07 -0500
Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 22, 2007 at 05:21:30PM -0400, Jeff Garzik wrote:
> > Alan Cox wrote:
> > >Why can't we just make the list one item longer than the entry count and
> > >stick a NULL on the end of it like normal people ?
> >
>
On Mon, 22 Oct 2007, Alan Cox wrote:
> For structures, not array elements or stack objects. Does gcc now get
> aligned correct as an attribute on a stack object ?
I think m68k stack layout still guarantees 4-byte-alignment, no?
> Still doesn't answer the rather more important question - why no
On Mon, Oct 22, 2007 at 05:21:30PM -0400, Jeff Garzik wrote:
> Alan Cox wrote:
> >Why can't we just make the list one item longer than the entry count and
> >stick a NULL on the end of it like normal people ?
>
> Certainly seems safer than the current "let's run off the end of the
> list if anyth
On Mon, 22 Oct 2007 13:44:43 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 22 Oct 2007, Alan Cox wrote:
> >
> > Why can't we just make the list one item longer than the entry count and
> > stick a NULL on the end of it like normal people ? Then you need one bit
> > which o
Alan Cox wrote:
Why can't we just make the list one item longer than the entry count and
stick a NULL on the end of it like normal people ?
Certainly seems safer than the current "let's run off the end of the
list if anything bad happens" setup... And I do not think allocating
n+1 scatterlis
On Oct. 22, 2007, 22:16 +0200, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Mon, 22 Oct 2007 12:49:40 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>>
>> On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
>>> Better safe than sorry...
>>>
>>> Is it possible that a chain entry pointer has bit 1
On Mon, 22 Oct 2007, Alan Cox wrote:
>
> Why can't we just make the list one item longer than the entry count and
> stick a NULL on the end of it like normal people ? Then you need one bit
> which ought to be safe for everyone (and if the bit is a macro any CPU
> warped enough to have byte align
On Mon, Oct 22, 2007 at 09:16:17PM +0100, Alan Cox wrote:
> On Mon, 22 Oct 2007 12:49:40 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
> > >
> > > Better safe than sorry...
> > >
> > > Is it possible that a chain entry point
On Mon, 22 Oct 2007 12:49:40 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
> >
> > Better safe than sorry...
> >
> > Is it possible that a chain entry pointer has bit 1 set on architectures
> > (e.g. m68k) where the natural alignment
On Mon, Oct 22 2007, Linus Torvalds wrote:
>
>
> On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
> >
> > Better safe than sorry...
> >
> > Is it possible that a chain entry pointer has bit 1 set on architectures
> > (e.g. m68k) where the natural alignment of 32-bit quantities is _2_ bytes,
> > no
On Mon, 22 Oct 2007, Geert Uytterhoeven wrote:
>
> Better safe than sorry...
>
> Is it possible that a chain entry pointer has bit 1 set on architectures
> (e.g. m68k) where the natural alignment of 32-bit quantities is _2_ bytes,
> not 4?
Better make sure that such alignment never happens... B
On Mon, 22 Oct 2007, Jens Axboe wrote:
> Change the page member of the scatterlist structure to be an unsigned
> long, and encode more stuff in the lower bits:
>
> - Bits 0 and 1 zero: this is a normal sg entry. Next sg entry is located
> at sg + 1.
> - Bit 0 set: this is a chain entry, the next
Change the page member of the scatterlist structure to be an unsigned
long, and encode more stuff in the lower bits:
- Bits 0 and 1 zero: this is a normal sg entry. Next sg entry is located
at sg + 1.
- Bit 0 set: this is a chain entry, the next real entry is at ->page_link
with the two low bi
52 matches
Mail list logo
