On Wed, Nov 14, 2012 at 08:03:49AM +0100, Stefani Seibold wrote:
> Am Freitag, den 09.11.2012, 10:32 +0800 schrieb Yuanhan Liu:
> > On Thu, Nov 08, 2012 at 01:37:15PM +0100, Stefani Seibold wrote:
> > > Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
>
> > Yes, it is. I will try lo
Am Freitag, den 09.11.2012, 10:32 +0800 schrieb Yuanhan Liu:
> On Thu, Nov 08, 2012 at 01:37:15PM +0100, Stefani Seibold wrote:
> > Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> Yes, it is. I will try log API then.
>
> Stefani, I found an issue while rework to current API. Say
On Thu, Nov 08, 2012 at 01:37:15PM +0100, Stefani Seibold wrote:
> Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> > On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> > > On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> > > wrote:
> > >
> > > > > Yes, and I g
Am Donnerstag, den 08.11.2012, 20:24 +0800 schrieb Yuanhan Liu:
> On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> > On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> > wrote:
> >
> > > > Yes, and I guess the same to give them a 64-element one.
> > > >
> > > > >
> > > > > If
On Tue, Oct 30, 2012 at 11:52:10PM -0700, Andrew Morton wrote:
> On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> wrote:
>
> > > Yes, and I guess the same to give them a 64-element one.
> > >
> > > >
> > > > If there's absolutely no prospect that the kfifo code will ever support
> > > > 10
Am Mittwoch, den 31.10.2012, 14:49 +0800 schrieb Yuanhan Liu:
> On Wed, Oct 31, 2012 at 07:30:33AM +0100, Stefani Seibold wrote:
> > Am Mittwoch, den 31.10.2012, 13:59 +0800 schrieb Yuanhan Liu:
> > > On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> > > > On Fri, 26 Oct 2012 15:56:5
Am Dienstag, den 30.10.2012, 23:52 -0700 schrieb Andrew Morton:
> On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> wrote:
>
> > > Yes, and I guess the same to give them a 64-element one.
> > >
> > > >
> > > > If there's absolutely no prospect that the kfifo code will ever support
> > > > 1
On Wed, 31 Oct 2012 10:11:06 +0200 Janne Kulmala wrote:
> On 10/31/2012 08:52 AM, Andrew Morton wrote:
> > On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold
> > wrote:
> >
> >>> Yes, and I guess the same to give them a 64-element one.
> >>>
>
> If there's absolutely no prospect that
On 10/31/2012 08:52 AM, Andrew Morton wrote:
On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold wrote:
Yes, and I guess the same to give them a 64-element one.
If there's absolutely no prospect that the kfifo code will ever support
100-byte fifos then I guess we should rework the API so tha
On Wed, 31 Oct 2012 07:30:33 +0100 Stefani Seibold wrote:
> > Yes, and I guess the same to give them a 64-element one.
> >
> > >
> > > If there's absolutely no prospect that the kfifo code will ever support
> > > 100-byte fifos then I guess we should rework the API so that the caller
> > > has
On Wed, Oct 31, 2012 at 07:30:33AM +0100, Stefani Seibold wrote:
> Am Mittwoch, den 31.10.2012, 13:59 +0800 schrieb Yuanhan Liu:
> > On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> > > On Fri, 26 Oct 2012 15:56:57 +0800
> > > Yuanhan Liu wrote:
> > >
> > > > Say, if we want to al
Am Mittwoch, den 31.10.2012, 13:59 +0800 schrieb Yuanhan Liu:
> On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> > On Fri, 26 Oct 2012 15:56:57 +0800
> > Yuanhan Liu wrote:
> >
> > > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> > > to allocate 8 byt
On Mon, Oct 29, 2012 at 01:59:35PM -0700, Andrew Morton wrote:
> On Fri, 26 Oct 2012 15:56:57 +0800
> Yuanhan Liu wrote:
>
> > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> > to allocate 8 bytes instead of 4 bytes.
> >
> > ...
> >
> > --- a/kernel/kfifo.c
> > +++ b/
On Fri, 26 Oct 2012 15:56:57 +0800
Yuanhan Liu wrote:
> Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> to allocate 8 bytes instead of 4 bytes.
>
> ...
>
> --- a/kernel/kfifo.c
> +++ b/kernel/kfifo.c
> @@ -39,11 +39,11 @@ int __kfifo_alloc(struct __kfifo *fifo, unsign
IMHO absent any reason to make the allocation change we should keep the
existing behaviour. Absent any reason to fiddle with the code we should
leave it alone.
It's delicate, tricky, tiny and works. Don't fiddle.
For the size question if the default behaviour is to pack them in
then a caller can
On Fri, Oct 26, 2012 at 03:39:46PM +0200, Stefani Seibold wrote:
> Am Freitag, den 26.10.2012, 20:33 +0800 schrieb Yuanhan Liu:
> > On Fri, Oct 26, 2012 at 11:30:27AM +0200, Stefani Seibold wrote:
> > > Am Freitag, den 26.10.2012, 15:56 +0800 schrieb Yuanhan Liu:
> > > > Say, if we want to allocate
Am Freitag, den 26.10.2012, 20:33 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 11:30:27AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 15:56 +0800 schrieb Yuanhan Liu:
> > > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> > > to allocate 8 bytes
On Fri, Oct 26, 2012 at 11:30:27AM +0200, Stefani Seibold wrote:
> Am Freitag, den 26.10.2012, 15:56 +0800 schrieb Yuanhan Liu:
> > Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> > to allocate 8 bytes instead of 4 bytes.
> >
> > I know it works with rounddown_pow_
Am Freitag, den 26.10.2012, 15:56 +0800 schrieb Yuanhan Liu:
> Say, if we want to allocate a filo with size of 6 bytes, it would be safer
> to allocate 8 bytes instead of 4 bytes.
>
> I know it works with rounddown_pow_of_two as well, since size is maintained
> in the kfifo internal part. But,
Say, if we want to allocate a filo with size of 6 bytes, it would be safer
to allocate 8 bytes instead of 4 bytes.
I know it works with rounddown_pow_of_two as well, since size is maintained
in the kfifo internal part. But, I'm quite curious why Stefani chose
rounddown_pow_of_two. To reduce me
20 matches
Mail list logo