Messages in this thread | | | Date | Fri, 27 Jan 2012 22:24:03 +0400 | From | Cyrill Gorcunov <> | Subject | Re: [RFC c/r 2/4] [RFC] syscalls, x86: Add __NR_kcmp syscall v7 |
| |
On Fri, Jan 27, 2012 at 07:15:25PM +0100, Andi Kleen wrote: > > It takes up to 5 agruments - the pids of the two tasks (which > > characteristics should be compared), the comparision type and > > (in case of comparision of files) two file descriptors. > > Can you please write a manpage for it? That's really required > to evaluate the interface properly.
Sure, I'll try to (btw, where I should send it to? And in which format novadays mans are written? In plain old troff or some human readable asciidocs?) And... should I post man page on LKML as well?
> > As I understand it every time the kernel adds some new kind of state > this would need to be extended too? This would seem like a lot of work, > especially since you always need to synchronize kernel/user space. > How would the user space break if it doesn't know about some newly > added state?
Wait, maybe I should use kernel-doc here and put comments with example right on top of SYSCALL definition?
> > Maybe it would be better to put more of the relevant code into the > kernel to encapsulate this better. > > > > + case KCMP_SYSVSEM: > > +#ifdef CONFIG_SYSVIPC > > + ret = kcmp_ptr((long)task1->sysvsem.undo_list, > > + (long)task2->sysvsem.undo_list, > > + KCMP_SYSVSEM); > > I assume that's normally NULL. >
Hmm.. Andi, I seem not following. And?
> > +#ifdef CONFIG_X86_64 > > +static long syscall5(int nr, unsigned long arg0, unsigned long arg1, > > + unsigned long arg2, unsigned long arg3, > > + unsigned long arg4) > > Why not just use syscall() in glibc? >
Never heard of it. I'll take a look, thanks. But I suppose all this comments might be addressed in patch on top?
Cyrill
| |