.
This patch just fixes this by using 'git rev-parse --show-cdup' to check that
the
current directory is the kernel git topdir. This has the advantage to not test
and rely
on git internal infrastructure directly.
Signed-off-by: Franck Bui-Huu
---
scripts/setlocalversion | 3 ++-
1 file changed, 2
On 12/02/2013 04:16 PM, Michal Marek wrote:
> On 2.12.2013 16:14, Franck Bui-Huu wrote:
>> On 12/02/2013 03:57 PM, Michal Marek wrote:
>>> On 2.12.2013 14:21, Franck Bui-Huu wrote:
>>>> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
>
On 12/02/2013 03:57 PM, Michal Marek wrote:
> On 2.12.2013 14:21, Franck Bui-Huu wrote:
>> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
>> index 0b5ccf3..c16e65d 100755
>> --- a/scripts/setlocalversion
>> +++ b/scripts/setlocalversion
>> @@ -43,7
.
This patch just fixes this by using 'git rev-parse --show-cdup' to check that
the
current directory is the kernel git topdir. This has the advantage to not test
and rely
on git internal infrastructure directly.
Signed-off-by: Franck Bui-Huu
---
scripts/setlocalversion | 3 ++-
1 file changed, 2
.
This patch just fixes this by using 'git rev-parse --show-cdup' to check that
the
current directory is the kernel git topdir. This has the advantage to not test
and rely
on git internal infrastructure directly.
Signed-off-by: Franck Bui-Huu fbui...@gmail.com
---
scripts/setlocalversion | 3 ++-
1 file
On 12/02/2013 03:57 PM, Michal Marek wrote:
On 2.12.2013 14:21, Franck Bui-Huu wrote:
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 0b5ccf3..c16e65d 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -43,7 +43,8 @@ scm_version()
fi
On 12/02/2013 04:16 PM, Michal Marek wrote:
On 2.12.2013 16:14, Franck Bui-Huu wrote:
On 12/02/2013 03:57 PM, Michal Marek wrote:
On 2.12.2013 14:21, Franck Bui-Huu wrote:
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 0b5ccf3..c16e65d 100755
--- a/scripts
.
This patch just fixes this by using 'git rev-parse --show-cdup' to check that
the
current directory is the kernel git topdir. This has the advantage to not test
and rely
on git internal infrastructure directly.
Signed-off-by: Franck Bui-Huu fbui...@gmail.com
---
scripts/setlocalversion | 3 ++-
1 file
Hi,
Josh Triplett wrote:
> [I did not see this patch go by on any mailing list, so I replied to
> the -mm mail and CCed LKML.]
>
Well I'm pretty sure to have always CC'ed LKML, see for example:
http://lkml.org/lkml/2008/2/19/150
http://lkml.org/lkml/2008/2/19/151
Thanks,
Hi,
Josh Triplett wrote:
[I did not see this patch go by on any mailing list, so I replied to
the -mm mail and CCed LKML.]
Well I'm pretty sure to have always CC'ed LKML, see for example:
http://lkml.org/lkml/2008/2/19/150
http://lkml.org/lkml/2008/2/19/151
Thanks,
From: Franck Bui-Huu <[EMAIL PROTECTED]>
This patch moves rcu-protected lists from list.h into a new header
file rculist.h.
This is done because list are a very used primitive structure all over
the kernel and it's currently impossible to include other header files
in this list.h w
From: Franck Bui-Huu <[EMAIL PROTECTED]>
This patch makes almost all list mutation primitives use
rcu_assign_pointer().
The main point of this being readability improvement.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
include/linux/rculist.h | 23 +---
From: Franck Bui-Huu [EMAIL PROTECTED]
This patch moves rcu-protected lists from list.h into a new header
file rculist.h.
This is done because list are a very used primitive structure all over
the kernel and it's currently impossible to include other header files
in this list.h without creating
From: Franck Bui-Huu [EMAIL PROTECTED]
This patch makes almost all list mutation primitives use
rcu_assign_pointer().
The main point of this being readability improvement.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
include/linux/rculist.h | 23 +--
1 files
Andrew Morton wrote:
> On Sun, 03 Feb 2008 09:45:25 +0100 Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Sat, 02 Feb 2008 14:32:41 +0100 Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
>>>> Do you think it's better ?
>>
Andrew Morton wrote:
> On Sat, 02 Feb 2008 14:32:41 +0100 Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
>> Do you think it's better ?
>
> Could. I'd suggest that you redo the header-file split patch around the
> 2.6.25-rc1 timeframe, test it carefully then let's get it in th
Andrew Morton wrote:
On Sat, 02 Feb 2008 14:32:41 +0100 Franck Bui-Huu [EMAIL PROTECTED] wrote:
Do you think it's better ?
Could. I'd suggest that you redo the header-file split patch around the
2.6.25-rc1 timeframe, test it carefully then let's get it in then.
Does the mm tree also have
Andrew Morton wrote:
On Sun, 03 Feb 2008 09:45:25 +0100 Franck Bui-Huu [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Sat, 02 Feb 2008 14:32:41 +0100 Franck Bui-Huu [EMAIL PROTECTED] wrote:
Do you think it's better ?
Could. I'd suggest that you redo the header-file split patch around
Andrew Morton wrote:
> On Thu, 17 Jan 2008 21:47:38 +0100
> Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
>
>> This patch moves rcu-protected lists from list.h into a new header
>> file rculist.h.
>
> I'm getting way too many compilation errors from this, perhaps
Andrew Morton wrote:
On Thu, 17 Jan 2008 21:47:38 +0100
Franck Bui-Huu [EMAIL PROTECTED] wrote:
This patch moves rcu-protected lists from list.h into a new header
file rculist.h.
I'm getting way too many compilation errors from this, perhaps because of
new rcu-list usages which weren't
From: Franck Bui-Huu <[EMAIL PROTECTED]>
This patch makes almost all list mutation primitives use
rcu_assign_pointer().
The main point of this being readability improvement.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
include/linux/rculist.h | 23 +---
From: Franck Bui-Huu <[EMAIL PROTECTED]>
This patch moves rcu-protected lists from list.h into a new header
file rculist.h.
This is done because list are a very used primitive structure all over
the kernel and it's currently impossible to include other header files
in this list.h w
Hi,
After reading the nice article contributed by Paul on LWN, I took a look
to the kernel RCU-protected list implementation to get a good idea on
how RCU protection mechanism can be used.
And it appears that the implementation doesn't use the RCU API as much
as it could: every updates of
From: Franck Bui-Huu [EMAIL PROTECTED]
This patch makes almost all list mutation primitives use
rcu_assign_pointer().
The main point of this being readability improvement.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
include/linux/rculist.h | 23 +--
1 files
Hi,
After reading the nice article contributed by Paul on LWN, I took a look
to the kernel RCU-protected list implementation to get a good idea on
how RCU protection mechanism can be used.
And it appears that the implementation doesn't use the RCU API as much
as it could: every updates of -next
From: Franck Bui-Huu [EMAIL PROTECTED]
This patch moves rcu-protected lists from list.h into a new header
file rculist.h.
This is done because list are a very used primitive structure all over
the kernel and it's currently impossible to include other header files
in this list.h without creating
Rafael J. Wysocki wrote:
> On Sunday, 18 of November 2007, Franck Bui-Huu wrote:
>> Rafael J. Wysocki wrote:
>> See the call to wait_even() made by apm_ioctl(). If any processes
>> run this, it will prevent the system to suspend...
>
> True, but does it actually h
Rafael J. Wysocki wrote:
On Sunday, 18 of November 2007, Franck Bui-Huu wrote:
Rafael J. Wysocki wrote:
See the call to wait_even() made by apm_ioctl(). If any processes
run this, it will prevent the system to suspend...
True, but does it actually happen in practice?
when several
Rafael J. Wysocki wrote:
> On Saturday, 17 of November 2007, Franck Bui-Huu wrote:
>> ok so now we agreed on this point, can we assert that a user
>> land thread waiting for an event in an UNINTERRUPTIBLE state
>> will prevent a suspend to happen ?
>
> Yes.
>
So t
Rafael J. Wysocki wrote:
On Saturday, 17 of November 2007, Franck Bui-Huu wrote:
ok so now we agreed on this point, can we assert that a user
land thread waiting for an event in an UNINTERRUPTIBLE state
will prevent a suspend to happen ?
Yes.
So this driver seems really broken
Rafael J. Wysocki wrote:
> On Saturday, 17 of November 2007, Franck Bui-Huu wrote:
>> Rafael J. Wysocki wrote:
>>> However, using PF_NOFREEZE to prevent this from happening doesn't seem to be
>>> a good idea.
>>>
>> Indeed but...
>>
>
Rafael J. Wysocki wrote:
> However, using PF_NOFREEZE to prevent this from happening doesn't seem to be
> a good idea.
>
Indeed but...
> I'd probably use wait_event_freezable() (defined in
> include/linux/freezer.h) for that.
...I would just revert this bits from now to make sure this driver
Rafael J. Wysocki wrote:
However, using PF_NOFREEZE to prevent this from happening doesn't seem to be
a good idea.
Indeed but...
I'd probably use wait_event_freezable() (defined in
include/linux/freezer.h) for that.
...I would just revert this bits from now to make sure this driver
work
Rafael J. Wysocki wrote:
On Saturday, 17 of November 2007, Franck Bui-Huu wrote:
Rafael J. Wysocki wrote:
However, using PF_NOFREEZE to prevent this from happening doesn't seem to be
a good idea.
Indeed but...
I'd probably use wait_event_freezable() (defined in
include/linux/freezer.h
On Nov 16, 2007 5:20 PM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> The freezer doesn't regard the current task as freezable.
>
Hmm, I don't get your point.
If I understood this driver correctly, several processes can be
waiting for a suspend event by reading /dev/apm_bios, apmd (the
Rafael,
Looking at commit:
831441862956fffa17b9801db37e6ea1650b0f69
Freezer: make kernel threads nonfreezable by default
it seems that you broke the apm emulation driver.
You removed PF_NOFREEZE flag setting in apm_ioctl(), which is
definitely not part of the apm kernel daemon
Rafael,
Looking at commit:
831441862956fffa17b9801db37e6ea1650b0f69
Freezer: make kernel threads nonfreezable by default
it seems that you broke the apm emulation driver.
You removed PF_NOFREEZE flag setting in apm_ioctl(), which is
definitely not part of the apm kernel daemon
On Nov 16, 2007 5:20 PM, Rafael J. Wysocki [EMAIL PROTECTED] wrote:
The freezer doesn't regard the current task as freezable.
Hmm, I don't get your point.
If I understood this driver correctly, several processes can be
waiting for a suspend event by reading /dev/apm_bios, apmd (the _user_
to be useless and allows
platforms such MIPS to do the randomization.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
Andrew,
I tried several times to poke people on the list to understand why
this dependency exists at all, but unfortunately got no answers.
So I'm subm
to be useless and allows
platforms such MIPS to do the randomization.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
Andrew,
I tried several times to poke people on the list to understand why
this dependency exists at all, but unfortunately got no answers.
So I'm submitting
Hello,
I have a couple questions about the process stack randomization but
I'm not sure who should be CCed for such questions.
I submitted a patch to enable 'inside the page' stack randomization on
MIPS few weeks ago and which has been now committed. But I noticed
that this patch is actually
Hello,
I have a couple questions about the process stack randomization but
I'm not sure who should be CCed for such questions.
I submitted a patch to enable 'inside the page' stack randomization on
MIPS few weeks ago and which has been now committed. But I noticed
that this patch is actually
Hi,
Jiri Kosina wrote:
> >
[snip]
> > +/* overriden by architectures supporting brk randomization */
> > +void __weak arch_randomize_brk(struct mm_struct *mm) { }
I was actually suggesting in my last email:
unsigned long randomize_brk(unsigned long brk)
therefore arch specific code
Hi,
Jiri Kosina wrote:
[snip]
+/* overriden by architectures supporting brk randomization */
+void __weak arch_randomize_brk(struct mm_struct *mm) { }
I was actually suggesting in my last email:
unsigned long randomize_brk(unsigned long brk)
therefore arch specific code don't
Hello Andrew,
Andrew Morton wrote:
> On Thu, 30 Aug 2007 17:10:03 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]>
> wrote:
>> Andrew, do you still strongly oppose to having ARCH_HAS_RANDOMIZE_BRK
>> macro instead please?
>>
>
> Not strongly, but the general opinion seems to be that ARCH_HAS_FOO
Hello Andrew,
Andrew Morton wrote:
On Thu, 30 Aug 2007 17:10:03 +0200 (CEST) Jiri Kosina [EMAIL PROTECTED]
wrote:
Andrew, do you still strongly oppose to having ARCH_HAS_RANDOMIZE_BRK
macro instead please?
Not strongly, but the general opinion seems to be that ARCH_HAS_FOO is
sucky.
Jiri Kosina wrote:
> On Thu, 30 Aug 2007, Mike Frysinger wrote:
>
>> Blackfin too please :) i think v850 also falls into this category, but
>> i'm not terribly familiar with it ...
>
> Andrew, do you still strongly oppose to having ARCH_HAS_RANDOMIZE_BRK
> macro instead please?
>
you might
Arjan,
Franck Bui-Huu wrote:
> Arjan van de Ven wrote:
>> arch_align_stack aligns, on x86, within a 2 page range (this is for
>> cache coloring).
>
> OK, but for elf case this seems useless since the top of the stack is
> already randomized.
>
> It seems tha
Arjan,
Franck Bui-Huu wrote:
Arjan van de Ven wrote:
arch_align_stack aligns, on x86, within a 2 page range (this is for
cache coloring).
OK, but for elf case this seems useless since the top of the stack is
already randomized.
It seems that the randomization stuff (top of the stack
Jiri Kosina wrote:
On Thu, 30 Aug 2007, Mike Frysinger wrote:
Blackfin too please :) i think v850 also falls into this category, but
i'm not terribly familiar with it ...
Andrew, do you still strongly oppose to having ARCH_HAS_RANDOMIZE_BRK
macro instead please?
you might want to use
Hello Arjan,
Arjan van de Ven wrote:
> arch_align_stack aligns, on x86, within a 2 page range (this is for
> cache coloring).
OK, but for elf case this seems useless since the top of the stack is
already randomized.
It seems that the randomization stuff (top of the stack + stack
pointer inside
Hello Arjan,
Arjan van de Ven wrote:
arch_align_stack aligns, on x86, within a 2 page range (this is for
cache coloring).
OK, but for elf case this seems useless since the top of the stack is
already randomized.
It seems that the randomization stuff (top of the stack + stack
pointer inside a
Hello folks,
I recently pick up the implementation of arch_align_stack() from x86
architectures to make it available for mips.
But now I just realised that this function seems useless because of
the way it's used.
Currently, this function seems to be only used to randomize the stack
pointer
Hello folks,
I recently pick up the implementation of arch_align_stack() from x86
architectures to make it available for mips.
But now I just realised that this function seems useless because of
the way it's used.
Currently, this function seems to be only used to randomize the stack
pointer
Hi,
On 7/9/07, Ralf Baechle <[EMAIL PROTECTED]> wrote:
On Sat, Jul 07, 2007 at 03:03:30AM +0200, Adrian Bunk wrote:
> "extern inline" will have different semantics with gcc 4.3,
> and "static inline" is correct here.
The idea was to have a linker error in case gcc should deciede for some
Hi,
On 7/9/07, Ralf Baechle [EMAIL PROTECTED] wrote:
On Sat, Jul 07, 2007 at 03:03:30AM +0200, Adrian Bunk wrote:
extern inline will have different semantics with gcc 4.3,
and static inline is correct here.
The idea was to have a linker error in case gcc should deciede for some
reason not
Hi,
On 6/19/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
This patch removes the few leftovers of the MOMENCO_JAGUAR_ATX removal.
thanks for catching it,
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/Kconfig|2 +-
include/asm-mips/war.h |7 +++
2 files
Hi,
On 6/19/07, Adrian Bunk [EMAIL PROTECTED] wrote:
This patch removes the few leftovers of the MOMENCO_JAGUAR_ATX removal.
thanks for catching it,
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/Kconfig|2 +-
include/asm-mips/war.h |7 +++
2 files changed,
Hi Thomas,
Thomas Gleixner wrote:
> i386 and sparc64 have the identical code to update the cmos clock.
> Move it into kernel/time/ntp.c as there are other architectures
> coming along with the same requirements.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> Cc: Chris Wright <[EMAIL
Hi Thomas,
Thomas Gleixner wrote:
i386 and sparc64 have the identical code to update the cmos clock.
Move it into kernel/time/ntp.c as there are other architectures
coming along with the same requirements.
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Cc: Chris Wright [EMAIL PROTECTED]
From: Franck Bui-Huu <[EMAIL PROTECTED]>
Stacktrace support on MIPS doesn't use frame pointers. Since this
option considerably increases the size of the kernel code, force
lockdep to not use it.
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
lib/Kconfig.debug |2 +-
1 f
From: Franck Bui-Huu [EMAIL PROTECTED]
Stacktrace support on MIPS doesn't use frame pointers. Since this
option considerably increases the size of the kernel code, force
lockdep to not use it.
Signed-off-by: Franck Bui-Huu [EMAIL PROTECTED]
---
lib/Kconfig.debug |2 +-
1 files changed, 1
On 1/22/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Please revert 2.6.19's 99a10a60ba9bedcf5d70ef81414d3e03816afa3f (shown
below) for 2.6.20. Nadia Derbey has reported that mmap of /dev/kmem no
longer works with the kernel virtual address as offset, and Franck has
confirmed that his patch came
On 1/22/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Please revert 2.6.19's 99a10a60ba9bedcf5d70ef81414d3e03816afa3f (shown
below) for 2.6.20. Nadia Derbey has reported that mmap of /dev/kmem no
longer works with the kernel virtual address as offset, and Franck has
confirmed that his patch came
On 1/19/07, Hugh Dickins <[EMAIL PROTECTED]> wrote:
Apology surely accepted, it's a confusing area (inevitably: in a driver
for mem, the distinction between addresses and offsets become blurred).
But please note, the worst of it was, that your patch comment gave no
hint that you were knowingly
On 1/19/07, Hugh Dickins [EMAIL PROTECTED] wrote:
Apology surely accepted, it's a confusing area (inevitably: in a driver
for mem, the distinction between addresses and offsets become blurred).
But please note, the worst of it was, that your patch comment gave no
hint that you were knowingly
Hi,
Hugh Dickins wrote:
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering
Hi,
Hugh Dickins wrote:
On Thu, 18 Jan 2007, Nadia Derbey wrote:
Trying to mmap /dev/kmem with an offset I take from /boot/System.map,
I get an EIO error on a 2.6.20-rc4.
This is something that used to work on older kernels.
Had a look at mmap_kmem() in drivers/char/mem.c, and I'm wondering
On 12/20/06, Franck Bui-Huu <[EMAIL PROTECTED]> wrote:
- when mmaping your frame buffer , be sure that the virtual
address returned by mmap() to the application shares the
same cache lines than the ones the kernel
is using.
Well thinking more about it, this wouldn'
On 12/20/06, Franck Bui-Huu [EMAIL PROTECTED] wrote:
- when mmaping your frame buffer , be sure that the virtual
address returned by mmap() to the application shares the
same cache lines than the ones the kernel
is using.
Well thinking more about it, this wouldn't work
On 12/17/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
Ok. I now see what you mean. In typical cases, only one path is used
to write. Meaning an app will decide to use the mmap path or the slow
write path and the kernel only ever reads from its pte entry (unless
fbcon is used which is not suited for
On 12/17/06, Jaya Kumar [EMAIL PROTECTED] wrote:
Ok. I now see what you mean. In typical cases, only one path is used
to write. Meaning an app will decide to use the mmap path or the slow
write path and the kernel only ever reads from its pte entry (unless
fbcon is used which is not suited for
On 12/12/06, Jaya Kumar <[EMAIL PROTECTED]> wrote:
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I
On 12/12/06, Jaya Kumar [EMAIL PROTECTED] wrote:
I think that PTEs set up by vmalloc are marked cacheable and via the
above nopage end up as cacheable. I'm not doing DMA. So the accesses
are through the cache so I don't think cache aliasing is an issue for
this case. Please let me know if I
Hi,
[EMAIL PROTECTED] wrote:
> Hi Geert, James, FBdev, MM folk,
>
> Appended is my attempt to support the Hecuba/E-Ink display. I've added
> some code to do deferred IO. This is there in order to hide the latency
> associated with updating the display (500ms to 800ms). The method used
> is to
Hi,
[EMAIL PROTECTED] wrote:
Hi Geert, James, FBdev, MM folk,
Appended is my attempt to support the Hecuba/E-Ink display. I've added
some code to do deferred IO. This is there in order to hide the latency
associated with updating the display (500ms to 800ms). The method used
is to fake a
On 11/17/06, James Simmons <[EMAIL PROTECTED]> wrote:
Are those actually numbers? If they are the problem isn't byte reversal
but bit shifting.
1010100 = 54
0101010 = 2A
It's not byte reversal, but _bits_ of each bytes have been inversed
(bit7->bit0, bit6->bit1, bit5->bit2, bit4->bit3,
On 11/17/06, James Simmons [EMAIL PROTECTED] wrote:
Are those actually numbers? If they are the problem isn't byte reversal
but bit shifting.
1010100 = 54
0101010 = 2A
It's not byte reversal, but _bits_ of each bytes have been inversed
(bit7-bit0, bit6-bit1, bit5-bit2, bit4-bit3, bit3-bit4,
Dave Hansen wrote:
The only arch with phys_to_pfn() defined is UML, so the patch simply
won't compile anything but UML on current kernels (unless I'm missing
something).
oops, I forgot to send the part of the patch that defines these macros,
sorry.
Could you try to give us a more complete
Dave Hansen wrote:
The only arch with phys_to_pfn() defined is UML, so the patch simply
won't compile anything but UML on current kernels (unless I'm missing
something).
oops, I forgot to send the part of the patch that defines these macros,
sorry.
Could you try to give us a more complete
Hi,
As I described in my previous email, bootmem.c does improper
pfn convertions into phys addr. This simple patch fixes that.
Regards,
Franck.
---
This message contains confidential information and is intended only
Hi,
As I described in my previous email, bootmem.c does improper
pfn convertions into phys addr. This simple patch fixes that.
Regards,
Franck.
---
This message contains confidential information and is intended only
Dave Hansen wrote:
I suggest using something like discontigmem (or even sparsemem for that
matter) to properly handles holes in your address space.
I don't agree with you. First I don't see any advantages to use
"discontigmem" just
because physical ram address doesn't start to 0. I would embed
Dave Hansen wrote:
I suggest using something like discontigmem (or even sparsemem for that
matter) to properly handles holes in your address space.
I don't agree with you. First I don't see any advantages to use
discontigmem just
because physical ram address doesn't start to 0. I would embed
Hi,
I'm porting linux on an embedded system based on MIPS proc. I've
encountered several
problems and one of these is related to the physical memory which
doesn't start to 0.
This is actually not a big issue if code that makes physical address
convertions uses the
appropriate macros that do the
Hi,
I'm porting linux on an embedded system based on MIPS proc. I've
encountered several
problems and one of these is related to the physical memory which
doesn't start to 0.
This is actually not a big issue if code that makes physical address
convertions uses the
appropriate macros that do the
Second point, a lot of serial drivers call in their interrupt handler
"tty_flip_buffer_push" function. This function must no be called
in interrupt context. Why is it done anyway ?
Calling tty_flip_buffer_push() is fine from interrupt
as long as tty->low_latency is not set. It just queues
work
Ahaa! That's how the bug got introduced. It used to be an
array and then it got changed to a pointer! linux-2.4.26
also shows a local array.
Yes, just looked at the revision history in linux.bkbits.net and Linus
just fixed this 67 hours ago... So we're too late :)
ok, maybe next time :)
Hi,
Looking at TTY code, I noticed a weird test done in "opost_bock"
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr > sizeof(buf))
nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find
Hi,
Looking at TTY code, I noticed a weird test done in opost_bock
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr sizeof(buf))
nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find a
Ahaa! That's how the bug got introduced. It used to be an
array and then it got changed to a pointer! linux-2.4.26
also shows a local array.
Yes, just looked at the revision history in linux.bkbits.net and Linus
just fixed this 67 hours ago... So we're too late :)
ok, maybe next time :)
Second point, a lot of serial drivers call in their interrupt handler
tty_flip_buffer_push function. This function must no be called
in interrupt context. Why is it done anyway ?
Calling tty_flip_buffer_push() is fine from interrupt
as long as tty-low_latency is not set. It just queues
work for
92 matches
Mail list logo
