From: John Byrne <jbyrne@ka...> - 2001-08-27 21:29:23
> I have some doubts regarding some of the functions in Linux kernel. As
> fas as alpha is concerned there is lot of difference in the function
> naming and implementation when compared to x86. I am now changing many
> files in the linux kernel to have the functionality implemented.
> eg:- kernel_thread_with_pid ended up in adding functions like
> alpha_clone_with_pid. ( because this is how kernel_thread function is
> already implemented.....I am not sure whether i am doing the right
> thing. I am not an expert in assembly languages. Infact I am giving my
> frist try here on alpha...Some x86 I did long back)
The current implementation of the "with_pid" as an extra system call was
a mistake that we plan to rectify. Laura Ramirez will probably write to
you about this.
We may or may not need a hooked version of kernel_thread() that
allocates extra stack space for registers for process migration, but
that should be a straightforward change.
> Now the question. I am right now looking into file usercopy.c file.
> Since alpha doesn't have a similar counterpart, I started with
> /usr/include/asm/uaccess.h . But all the functions in this header file
> are 'extern inline' which I guess, if not able to inline will be taken
> only as a extern declaration. ( Correct me if I am wrong ).Now I am
> trying to find corresponding global function, but i am not able to
Ideally, "extern inline" would work as you suggest, except that the
people that write the code never expect inlining to fail; so there is no
need to define the global function. If you did, it would just fall out
of sync with the header because it was never compiled. What you need is
a method of generating the header and global from a single source, but
there is no real need for it at this time.
As far as I have been able to tell, Linus prefers "static inline", which
will always work, but hasn't been draconian about enforcing this on the
> Since this is involving lot of changes to linux kernel I doubt this is a
> right way of doing.Right now I am adding another file (!!!!!!!!!!!!!!)
> to linux kernel ( /usr/src/linux/arch/alpha/lib/usercopy.c ) in which I
> am planning to add all the functions,something similar to i386. I have
> got most of the functions done. But as I am going with the changes I am
> making, I am having further doubts regarding whether this is the right
> Can someone suggest me any other way?
SSI determines "remoteness" at the individual resource level --- as
opposed to MOSIX which mostly determines it at the process level. This
choice requires fairly invasive changes to the kernel of one form or
another. Given that it seems the project has a dozen or so conflicting
goals and everyone has their own taste in what is prettiest, the "best"
way of doing things has never become obvious and whatever works has
become the rule of the day.
From your email, I can't understand exactly what you are doing, but
there are really only a couple of choices:
1.) Modify the existing macros and function definitions.
2.) Rename the existing macros and function definitions; providing a
glue that calls handles the local/remote decision and calls the renamed
code as necessary for the local case.
Certainly, looking now at some of what I did for SSI/i386, I'm not sure
why I didn't choose to do (2) for at least some (the macros) of the
changes in uaccess.h.