er program. Eventually it will result in a call to what ever read
routine registered, but that must be a call back function or some thing.
Right?
- Siva
-Original Message-
From: Phillip Susi [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 27, 2007 12:10 PM
To: Siva Prasad
Cc: li
. Eventually it will result in a call to what ever read
routine registered, but that must be a call back function or some thing.
Right?
- Siva
-Original Message-
From: Phillip Susi [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 27, 2007 12:10 PM
To: Siva Prasad
Cc: linux-kernel
Hi,
How do the device nodes work as an interface between user and kernel
programs, and how to go debugging it?
This is as part of my debugging effort on an embedded board.
* It all started with the problem of "not printing" any thing that comes
from ramdisk (echo and printf statements), while
Hi,
How do the device nodes work as an interface between user and kernel
programs, and how to go debugging it?
This is as part of my debugging effort on an embedded board.
* It all started with the problem of not printing any thing that comes
from ramdisk (echo and printf statements), while
Hi Matthew,
I worked on some thing similar. For one of our customer product that
goes to defense and security markets, we had to support maximum possible
memory test. We implemented a mechanism of pre-test to test the memory
with walking 1's and 0's just before Linux kernel starts allocating
Hi Matthew,
I worked on some thing similar. For one of our customer product that
goes to defense and security markets, we had to support maximum possible
memory test. We implemented a mechanism of pre-test to test the memory
with walking 1's and 0's just before Linux kernel starts allocating
M
To: Siva Prasad
Cc: Clemens Koller; David Newall; linux-kernel@vger.kernel.org
Subject: RE: printf internals
On Wed, 2007-12-19 at 14:33 -0800, Siva Prasad wrote:
> Thank you very much for your response Clemens.
>
> I tried strace on a regular system. It does not show which tt
14, 2007 8:16 AM
To: David Newall
Cc: Siva Prasad; linux-kernel@vger.kernel.org
Subject: Re: printf internals
David Newall schrieb:
> Siva Prasad wrote:
>> I am looking at how exactly does the printf in user programs succeeds in
>> displaying characters to the
14, 2007 8:16 AM
To: David Newall
Cc: Siva Prasad; linux-kernel@vger.kernel.org
Subject: Re: printf internals
David Newall schrieb:
Siva Prasad wrote:
I am looking at how exactly does the printf in user programs succeeds in
displaying characters to the serial console.
Is it a student
Prasad
Cc: Clemens Koller; David Newall; linux-kernel@vger.kernel.org
Subject: RE: printf internals
On Wed, 2007-12-19 at 14:33 -0800, Siva Prasad wrote:
Thank you very much for your response Clemens.
I tried strace on a regular system. It does not show which tty, etc.,
as it uses the stdout (fd
Hi,
I am looking at how exactly does the printf in user programs succeeds in
displaying characters to the serial console.
printf uses /dev/console to write the data. Once written to
/dev/console, what happens to the string written?
Is there any way, I can get access to those prints/string
Hi,
I am looking at how exactly does the printf in user programs succeeds in
displaying characters to the serial console.
printf uses /dev/console to write the data. Once written to
/dev/console, what happens to the string written?
Is there any way, I can get access to those prints/string
Hi,
What is the primary difference between Ramdisk and NFS with respect to
the wait_queue's?
If I use ramdisk, every thing works fine, but with NFS (or you may read
as 'no ramdisk') kernel/sched.c:__wake_up_common() routines has a
problem. Basically the value of ">task_list->next" is out of our
Hi,
What is the primary difference between Ramdisk and NFS with respect to
the wait_queue's?
If I use ramdisk, every thing works fine, but with NFS (or you may read
as 'no ramdisk') kernel/sched.c:__wake_up_common() routines has a
problem. Basically the value of q-task_list-next is out of our
Sorry for the newbie question..
Is it true that the ipc calls like
msgget(),shmget()...
are not really system calls?
Cos in the file "asm/unistd.h" where the
system calls are listed as __NR_xxx we dont find
the appropriate listing for the ipc calls.
What I guessed was that all the ipc calls
Sorry for the newbie question..
Is it true that the ipc calls like
msgget(),shmget()...
are not really system calls?
Cos in the file asm/unistd.h where the
system calls are listed as __NR_xxx we dont find
the appropriate listing for the ipc calls.
What I guessed was that all the ipc calls are
16 matches
Mail list logo
