[ORLinux] [PATCH] Support for CLONE_SETTLS flag.

[Christian Svensson]

* arch/openrisc/kernel/process.c:
(copy_thread): Support for CLONE_SETTLS flag.
---
arch/openrisc/kernel/process.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 55210f3..12056bf 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -142,6 +142,13 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
childregs->sp = usp;
}

+ /*
+ * If CLONE_SETTLS is set, set "tp" in the new task to "r7",
+ * which is passed in as arg #5 to sys_clone().
+ */
+ if (clone_flags & CLONE_SETTLS)
+ childregs->gpr[10] = regs->gpr[7];
+
childregs->gpr[11] = 0; /* Result from fork() */

/*

[Jonas Bonn]

Hi Christian,

Post by Christian Svensson
(copy_thread): Support for CLONE_SETTLS flag.

You'll need to provide a meaningful commit message... including a
Signed-off-by: tag.

Post by Christian Svensson
---
arch/openrisc/kernel/process.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/openrisc/kernel/process.c b/arch/openrisc/kernel/process.c
index 55210f3..12056bf 100644
--- a/arch/openrisc/kernel/process.c
+++ b/arch/openrisc/kernel/process.c
@@ -142,6 +142,13 @@ copy_thread(unsigned long clone_flags, unsigned long usp,
childregs->sp = usp;
}
+ /*
+ * If CLONE_SETTLS is set, set "tp" in the new task to "r7",
+ * which is passed in as arg #5 to sys_clone().
+ */
+ if (clone_flags & CLONE_SETTLS)
+ childregs->gpr[10] = regs->gpr[7];
+
childregs->gpr[11] = 0; /* Result from fork() */
/*

The patch itself looks good, but...

This is based on an old kernel and this is an area where we've seen a
lot of changes recently. Could you resubmit this patch for a recent
kernel? (I could easily massage this into the latest kernel for you,
but I think it would be a good exercise for you to do so yourself...).

I just fixed up a bad bug in the kernel today so the kernel I'd
recommend you do your work on at this point is:

git://openrisc.net/jonas/linux

i) since you are working on eglibc which supports the generic syscall
interface, you should use the 'for-upstream' branch
ii) however, if you want to use our old uClibc which still lacks the
generic syscall interface, you should use the 'master' branch

/Jonas

[Christian Svensson]

Hello,

Post by Jonas Bonn
a meaningful commit message... including a
Signed-off-by: tag.

Right, I'm used to the "short and many" changes flow from the other
things. No problem, I will shape up :-).

Post by Jonas Bonn
This is based on an old kernel and this is an area where we've seen a lot of
changes recently. Could you resubmit this patch for a recent kernel?

Honestly I'd forgotten that I worked on an old kernel. I will put some
effort in getting things working with the provided repo.

Post by Jonas Bonn
(I could easily massage this into the latest kernel for you, but I think it
would be a good exercise for you to do so yourself...).

It's no problem :-).

I'll submit two new patches when I get things up to speed.

Regards,
Christian

[Christian Svensson]

Hi,

I thought I would get this and the atomic functions finally upstreamed.
Is the above still valid? Should I rebase my patch for the "for-upstream"
branch?

Post by Christian Svensson
Hello,

Post by Jonas Bonn
a meaningful commit message... including a
Signed-off-by: tag.

Right, I'm used to the "short and many" changes flow from the other
things. No problem, I will shape up :-).

Post by Jonas Bonn
This is based on an old kernel and this is an area where we've seen a

lot of

Post by Jonas Bonn
changes recently. Could you resubmit this patch for a recent kernel?

Honestly I'd forgotten that I worked on an old kernel. I will put some
effort in getting things working with the provided repo.

Post by Jonas Bonn
(I could easily massage this into the latest kernel for you, but I think

it

Post by Jonas Bonn
would be a good exercise for you to do so yourself...).

It's no problem :-).
I'll submit two new patches when I get things up to speed.
Regards,
Christian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openrisc.net/pipermail/linux/attachments/20140111/233a4b85/attachment.html>

[Jonas Bonn]

Hi Christian,

Post by Christian Svensson
Hi,
I thought I would get this and the atomic functions finally upstreamed.
Is the above still valid? Should I rebase my patch for the "for-upstream"
branch?

Yes, my previous comments apply. Please rebase your patch on either
the for-upstream or master branch of my repo.

Thanks,
Jonas