On 7/9/07, Rajat Jain <[EMAIL PROTECTED]> wrote:
Hi,
>>
>> Can we always rely on the fact that gcc will pad the following structure?
>>
>> typedef struct {
>> int descrp; SYSCALL64_STRUCT_ATTR;
>> (Automatic padding here?)
>> long long pos; SYSCALL64_STRUCT_ATTR;
>> int
On 7/9/07, Rajat Jain <[EMAIL PROTECTED]> wrote:
Hi,
Perhaps a little offtopic but no harm in trying ...
Can we always rely on the fact that gcc will pad the following structure?
typedef struct {
int descrp; SYSCALL64_STRUCT_ATTR;
(Automatic padding here?)
long long pos; SYS
On 5/17/07, Ratnadeep Joshi <[EMAIL PROTECTED]> wrote:
> All,
>
> Following definition of notifier_chain_register is from kernel/sys.c
> and for kernel 2.6.20.1 .
>
> static int notifier_chain_register(struct notifier_block **nl,
> struct notifier_block *n)
> {
> while
Hi All,
Following definition of notifier_chain_register is from kernel/sys.c
and for kernel 2.6.20.1 .
static int notifier_chain_register(struct notifier_block **nl,
struct notifier_block *n)
{
while ((*nl) != NULL) {
if (n->priority > (*nl)->priority)
On 4/24/07, Rick Brown <[EMAIL PROTECTED]> wrote:
Hi list,
I read that the kernel does not differentiate between threads and
processes. That means, we can say that on a Linux system, the
threading is purely provided by user level thread libraries, right?
So as long as relevant system calls do n
On 4/19/07, Rajat Jain <[EMAIL PROTECTED]> wrote:
Hi,
> ... the kernel thread is as sensitive as the kernel itself
> for the page faults. It _should not_ fault, unless ofcourse if its a
> vmalloc'ed area .. and that happens every other kernel path anyway
I have a doubt about the vmalloc'ed
