We now have to to include linux/slab.h explicitly for kmalloc & friends.
Files that build against host headers already get their prototypes via
um_malloc.h, linux/slab.h may even be unavailable.
Signed-off-by: Jan Kiszka <[email protected]>
---
arch/um/drivers/line.c | 1 +
arch/um/os-Linux/helper.c | 1 -
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index 64cda95..7a656bd 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -6,6 +6,7 @@
#include "linux/irqreturn.h"
#include "linux/kd.h"
#include "linux/sched.h"
+#include "linux/slab.h"
#include "chan_kern.h"
#include "irq_kern.h"
#include "irq_user.h"
diff --git a/arch/um/os-Linux/helper.c b/arch/um/os-Linux/helper.c
index 06d6ccf..b6b1096 100644
--- a/arch/um/os-Linux/helper.c
+++ b/arch/um/os-Linux/helper.c
@@ -8,7 +8,6 @@
#include <errno.h>
#include <sched.h>
#include <linux/limits.h>
-#include <linux/slab.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include "kern_constants.h"
Hello,
On 04/19/2010 01:37 AM, Jan Kiszka wrote:
> We now have to to include linux/slab.h explicitly for kmalloc & friends.
> Files that build against host headers already get their prototypes via
> um_malloc.h, linux/slab.h may even be unavailable.
Hmmm... my test um build was okay but I don't know much about details
of um builds. I suppose this patch will go through um tree?
Thanks.
--
tejun
Tejun Heo wrote:
> Hello,
>
> On 04/19/2010 01:37 AM, Jan Kiszka wrote:
>> We now have to to include linux/slab.h explicitly for kmalloc & friends.
>> Files that build against host headers already get their prototypes via
>> um_malloc.h, linux/slab.h may even be unavailable.
>
> Hmmm... my test um build was okay but I don't know much about details
> of um builds.
We may use different configs. Also, your userland includes have to lack
slab.h.
> I suppose this patch will go through um tree?
Good question. Does such a tree exist? I'm sitting on a few more um
cleanups & fixes, and so far I'm working against Linus' tree as I failed
to find anything more recent.
Jan
On 04/19/2010 04:35 PM, Jan Kiszka wrote:
> Good question. Does such a tree exist? I'm sitting on a few more um
> cleanups & fixes, and so far I'm working against Linus' tree as I failed
> to find anything more recent.
Well, in that case, I'll route this one through percpu.
Thanks.
--
tejun
On 04/19/2010 01:37 AM, Jan Kiszka wrote:
> We now have to to include linux/slab.h explicitly for kmalloc & friends.
> Files that build against host headers already get their prototypes via
> um_malloc.h, linux/slab.h may even be unavailable.
>
> Signed-off-by: Jan Kiszka <[email protected]>
applied to percpu#for-linus/next. Will push to Linus in a few days.
Thanks.
--
tejun
On Mon, 19 Apr 2010, Jan Kiszka wrote:
> > I suppose this patch will go through um tree?
>
> Good question. Does such a tree exist? I'm sitting on a few more um
> cleanups & fixes, and so far I'm working against Linus' tree as I failed
> to find anything more recent.
If these are simple-enough cleanups and/or compile fixes, feel free to
send them to [email protected].
--
Jiri Kosina
SUSE Labs, Novell Inc.
Jiri Kosina wrote:
> On Mon, 19 Apr 2010, Jan Kiszka wrote:
>
>>> I suppose this patch will go through um tree?
>> Good question. Does such a tree exist? I'm sitting on a few more um
>> cleanups & fixes, and so far I'm working against Linus' tree as I failed
>> to find anything more recent.
>
> If these are simple-enough cleanups and/or compile fixes, feel free to
> send them to [email protected].
>
Some are trivial, but most aren't. Will check if I can split the formers
out, but I guess it's simpler to keep the queue.
Thanks,
Jan
On Mon, 19 Apr 2010, Jan Kiszka wrote:
> >>> I suppose this patch will go through um tree?
> >> Good question. Does such a tree exist? I'm sitting on a few more um
> >> cleanups & fixes, and so far I'm working against Linus' tree as I failed
> >> to find anything more recent.
> >
> > If these are simple-enough cleanups and/or compile fixes, feel free to
> > send them to [email protected].
> >
> Some are trivial, but most aren't. Will check if I can split the formers
> out, but I guess it's simpler to keep the queue.
Well, if Jeff isn't actively maintaining UML any more, either you can take
over the maintainership yourself, or feed the non-trivial patches through
Andrew Morton.
--
Jiri Kosina
SUSE Labs, Novell Inc.
On Mon, Apr 19, 2010 at 10:12:04PM +0200, Jiri Kosina wrote:
> Well, if Jeff isn't actively maintaining UML any more, either you can take
> over the maintainership yourself, or feed the non-trivial patches through
> Andrew Morton.
Yes, these generally go through Andrew.
Jeff
--
Work email - jdike at linux dot intel dot com
Jeff Dike wrote:
> On Mon, Apr 19, 2010 at 10:12:04PM +0200, Jiri Kosina wrote:
>> Well, if Jeff isn't actively maintaining UML any more, either you can take
>> over the maintainership yourself, or feed the non-trivial patches through
>> Andrew Morton.
>
> Yes, these generally go through Andrew.
OK, thanks. Just need to finish my IRQ handlers review / IRQF_DISABLED
cleanups, then I will roll it out.
Jan
PS: If you have any comments regarding the pthread topic, please let me
know.