Discussion:
linux-next: Tree for Oct 24
(too old to reply)
Thierry Reding
2013-10-24 16:40:03 UTC
Permalink
Hi all,

I've uploaded today's linux-next tree to the master branch of the
repository below:

git://gitorious.org/thierryreding/linux-next.git

A next-20131024 tag is also provided for convenience.

Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.

I'm somewhat short on time today, so I probably won't manage to send out
detailed conflict reports out today. I'll try to do that tomorrow,
though.

Thierry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Randy Dunlap
2013-10-24 20:10:03 UTC
Permalink
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
I'm somewhat short on time today, so I probably won't manage to send out
detailed conflict reports out today. I'll try to do that tomorrow,
though.
on i386:

drivers/tty/serial/xilinx_uartps.c: In function 'xuartps_clk_notifier_cb':
drivers/tty/serial/xilinx_uartps.c:436:7: error: 'PRE_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c:436:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/tty/serial/xilinx_uartps.c:446:36: error: dereferencing pointer to incomplete type
drivers/tty/serial/xilinx_uartps.c:461:7: error: 'POST_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c:470:24: error: dereferencing pointer to incomplete type
drivers/tty/serial/xilinx_uartps.c:475:7: error: 'ABORT_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c: In function 'xuartps_probe':
drivers/tty/serial/xilinx_uartps.c:1385:2: error: implicit declaration of function 'clk_notifier_register' [-Werror=implicit-function-declaration]
drivers/tty/serial/xilinx_uartps.c:1418:2: error: implicit declaration of function 'clk_notifier_unregister' [-Werror=implicit-function-declaration]


Full randconfig file is attached.
--
~Randy
Guenter Roeck
2013-10-25 05:10:02 UTC
Permalink
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see

Building arm:defconfig ... failed
--------------
Error log:
drivers/built-in.o: In function `mmc_gpio_request_cd':
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1

Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18

This is with "v3.12-rc5-7941-g765f88c".

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 08:40:02 UTC
Permalink
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.

Thierry
Olof Johansson
2013-10-25 13:20:01 UTC
Permalink
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.

Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mark Brown
2013-10-25 13:30:03 UTC
Permalink
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
The rule I was applying (which I think is the same as Stephen applies)
is that I'd fix anything that was definitely the result of a merge issue
(like the build failure in misc due to a sysfs API change in the sysfs
tree) but not anything that was just plain broken in the tree in
isolation.
Olof Johansson
2013-10-25 13:40:04 UTC
Permalink
Post by Mark Brown
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
The rule I was applying (which I think is the same as Stephen applies)
is that I'd fix anything that was definitely the result of a merge issue
(like the build failure in misc due to a sysfs API change in the sysfs
tree) but not anything that was just plain broken in the tree in
isolation.
Some of those might still make sense, but as many as possible of them
should be pushed down into the trees where they belong, even if
they're strictly not needed there (as long as they don't break the
standalone tree, of course).


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mark Brown
2013-10-25 15:50:02 UTC
Permalink
Post by Olof Johansson
Post by Mark Brown
The rule I was applying (which I think is the same as Stephen applies)
is that I'd fix anything that was definitely the result of a merge issue
(like the build failure in misc due to a sysfs API change in the sysfs
tree) but not anything that was just plain broken in the tree in
isolation.
Some of those might still make sense, but as many as possible of them
should be pushed down into the trees where they belong, even if
they're strictly not needed there (as long as they don't break the
standalone tree, of course).
Right, this is strictly for issues generated as a result of a change in
one tree that cause an issue when merged with another tree like adding a
user of an API in one tree that has had an incompatible change in
another.
Thierry Reding
2013-10-25 13:40:03 UTC
Permalink
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.

Except for very few occasions I've immediately sent out patches to the
respective subsystem maintainers, so they should've gotten picked up.
What's the difference if I do it as part of linux-next to if somebody
does it outside? At least this way they are part of the linux-next tree
so if I create the next one and cherry-pick the patches and they still
apply I can be reasonably sure that they haven't landed in the right
place yet.

Thierry
Olof Johansson
2013-10-25 13:50:03 UTC
Permalink
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.
Yeah, that's what happened with the GPIO subsystem on this release --
there are two build errors but your fix resolves one of them such at
the other one is exposed. It makes it confusing to bisect down to root
cause. I'd almost rather have your tree just being broken, but patches
submitted and sent in to the maintainer in question if you want to get
it fixed ASAP.

In particular, the gpio fix in the tree right now has no description, etc.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 14:20:02 UTC
Permalink
Post by Olof Johansson
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.
Yeah, that's what happened with the GPIO subsystem on this release --
there are two build errors but your fix resolves one of them such at
the other one is exposed. It makes it confusing to bisect down to root
cause. I'd almost rather have your tree just being broken, but patches
submitted and sent in to the maintainer in question if you want to get
it fixed ASAP.
I guess I could probably just push the final merge commit as a tree, but
it would require me to very strongly resist my compulsive urge not to
push something that doesn't even build.

I suppose if we could write that down into some kind of rule I could go
look at it until the compulsiveness wears down... =)
Post by Olof Johansson
In particular, the gpio fix in the tree right now has no description, etc.
Yes, I know. FWIW I fixed that up properly in today's tree, which I'm
almost ready to push out.

Thierry
Guenter Roeck
2013-10-25 15:10:01 UTC
Permalink
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.
Yeah, that's what happened with the GPIO subsystem on this release --
there are two build errors but your fix resolves one of them such at
the other one is exposed. It makes it confusing to bisect down to root
cause. I'd almost rather have your tree just being broken, but patches
submitted and sent in to the maintainer in question if you want to get
it fixed ASAP.
I guess I could probably just push the final merge commit as a tree, but
it would require me to very strongly resist my compulsive urge not to
push something that doesn't even build.
"Doesn't even build" is relative, though. After all, there still _are_
18 build failures out of 106 in my test builds alone. Where do you draw
the line ? arm failures are bad, who cares about blackfin ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 15:20:02 UTC
Permalink
Post by Guenter Roeck
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
Post by Thierry Reding
Post by Olof Johansson
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Post by Thierry Reding
Post by Guenter Roeck
Post by Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
Hmm ... I see
Building arm:defconfig ... failed
--------------
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.
Yeah, that's what happened with the GPIO subsystem on this release --
there are two build errors but your fix resolves one of them such at
the other one is exposed. It makes it confusing to bisect down to root
cause. I'd almost rather have your tree just being broken, but patches
submitted and sent in to the maintainer in question if you want to get
it fixed ASAP.
I guess I could probably just push the final merge commit as a tree, but
it would require me to very strongly resist my compulsive urge not to
push something that doesn't even build.
"Doesn't even build" is relative, though. After all, there still _are_
18 build failures out of 106 in my test builds alone. Where do you draw
the line ? arm failures are bad, who cares about blackfin ?
Well, I've been doing x86, ARM and PowerPC builds and of those only 3
are failing and I didn't fix them because I didn't really know how to.
But you're right, I guess one has to draw the line somewhere, and if
people prefer the tree to just be broken rather than with odd fixes on
top, then that's the way it going to be.

For now I've settled on pushing a branch which has only the fixes that
are required to make the trees work happily together and a separate tag
which has the patches that unbreak subsystem trees.

The reason I usually want linux-next to build is because I know that
various people rely on it for their daily work, so my reasoning was that
if I fix it before they even start using it, then they get to spend
their time with something more useful and only one person ends up fixing
the build issues instead of everyone.

Thierry
Guenter Roeck
2013-10-25 17:20:02 UTC
Permalink
Post by Thierry Reding
Post by Guenter Roeck
"Doesn't even build" is relative, though. After all, there still _are_
18 build failures out of 106 in my test builds alone. Where do you draw
the line ? arm failures are bad, who cares about blackfin ?
Well, I've been doing x86, ARM and PowerPC builds and of those only 3
are failing and I didn't fix them because I didn't really know how to.
But you're right, I guess one has to draw the line somewhere, and if
people prefer the tree to just be broken rather than with odd fixes on
top, then that's the way it going to be.
For now I've settled on pushing a branch which has only the fixes that
are required to make the trees work happily together and a separate tag
which has the patches that unbreak subsystem trees.
The reason I usually want linux-next to build is because I know that
various people rely on it for their daily work, so my reasoning was that
if I fix it before they even start using it, then they get to spend
their time with something more useful and only one person ends up fixing
the build issues instead of everyone.
Frankly, I don't even know what the best approach would be.
Ultimately you are stuck between a rock and a hard place: You want the tree
to build so people can use it, but each patch you apply yourself might
result in it not getting fixed in the contributing repository.

I think one problem we have is how to report breakages. Any summary
mail or web page doesn't help if no one looks at it. It does help lot
to send specific e-mail along the line of "Commit 'bla' caused build 'x'
to fail as follows" to the respective mailing list and patch authors,
but that takes a lot of time which at least I don't have. And people
might get annoyed by automated e-mails, so that might not be a good
idea either.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Geert Uytterhoeven
2013-10-25 18:10:02 UTC
Permalink
Post by Guenter Roeck
I think one problem we have is how to report breakages. Any summary
mail or web page doesn't help if no one looks at it. It does help lot
to send specific e-mail along the line of "Commit 'bla' caused build 'x'
to fail as follows" to the respective mailing list and patch authors,
but that takes a lot of time which at least I don't have. And people
might get annoyed by automated e-mails, so that might not be a good
idea either.
In theory, these blame emails can be automated using some git bisect
scripting.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:10:01 UTC
Permalink
Today's linux-next merge of the mfd-lj tree got conflicts in

sound/soc/codecs/mc13783.c

caused by commits 9f6f0af (ASoC: mc13783: add spi errata fix), fd792f8
(mfd: mc13xxx: Move SPI erratum workaround into SPI I/O function) and
2d9215c (ASoC: mc13783: Use regmap directly from ASoC).

I fixed it up and the diff turned up empty, so I think it can't be all
that wrong.

Thanks,
Thierry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:10:01 UTC
Permalink
Today's linux-next tree of the h8300-remove tree got a conflict in

drivers/parport/Kconfig

caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc drivers/parport/Kconfig
index f536685,dc82ef0..2225237
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@@ -41,8 -35,10 +41,7 @@@ if PARPOR

config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
-
+ depends on ARCH_MIGHT_HAVE_PC_PARPORT
-
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mark Salter
2013-10-25 13:40:02 UTC
Permalink
Post by Thierry Reding
Today's linux-next tree of the h8300-remove tree got a conflict in
drivers/parport/Kconfig
caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc drivers/parport/Kconfig
index f536685,dc82ef0..2225237
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@@ -41,8 -35,10 +41,7 @@@ if PARPOR
config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
-
+ depends on ARCH_MIGHT_HAVE_PC_PARPORT
-
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
Yes, that looks right. With the PC_PARPORT cleanup, h8300 doesn't need
to exclude itself. It is now excluded by default.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Guenter Roeck
2013-10-25 15:10:02 UTC
Permalink
Post by Thierry Reding
Today's linux-next tree of the h8300-remove tree got a conflict in
drivers/parport/Kconfig
caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc drivers/parport/Kconfig
index f536685,dc82ef0..2225237
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@@ -41,8 -35,10 +41,7 @@@ if PARPOR
config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
-
+ depends on ARCH_MIGHT_HAVE_PC_PARPORT
-
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
I dropped the patch (revert) causing the conflict.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:10:02 UTC
Permalink
Today's linux-next merge of the kvm-arm tree got a conflict in

arch/arm/kvm/reset.c

caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and 7999b4d
(ARM: KVM: drop limitation to 4 CPU VMs).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc arch/arm/kvm/reset.c
index d153e64,2c5add0..f558c07
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@@ -64,9 -62,7 +62,7 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
switch (vcpu->arch.target) {
case KVM_ARM_TARGET_CORTEX_A7:
case KVM_ARM_TARGET_CORTEX_A15:
- if (vcpu->vcpu_id > cortexa_max_cpu_idx)
- return -EINVAL;
- cpu_reset = &cortexa_regs_reset;
+ reset_regs = &cortexa_regs_reset;
vcpu->arch.midr = read_cpuid_id();
cpu_vtimer_irq = &cortexa_vtimer_irq;
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Marc Zyngier
2013-10-25 13:10:03 UTC
Permalink
Post by Thierry Reding
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm/kvm/reset.c
caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and 7999b4d
(ARM: KVM: drop limitation to 4 CPU VMs).
I fixed it up (see below). Please verify that the resolution looks good.
Looks good. Thanks Thierry.

M.
Post by Thierry Reding
Thanks,
Thierry
---
diff --cc arch/arm/kvm/reset.c
index d153e64,2c5add0..f558c07
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@@ -64,9 -62,7 +62,7 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
switch (vcpu->arch.target) {
- if (vcpu->vcpu_id > cortexa_max_cpu_idx)
- return -EINVAL;
- cpu_reset = &cortexa_regs_reset;
+ reset_regs = &cortexa_regs_reset;
vcpu->arch.midr = read_cpuid_id();
cpu_vtimer_irq = &cortexa_vtimer_irq;
break;
--
Jazz is not dead. It just smells funny...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:10:02 UTC
Permalink
Today's linux-next merge of the tip tree got conflicts in

tools/perf/config/Makefile
tools/perf/config/feature-tests.mak

caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.

I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?

Thanks,
Thierry
---
diff --cc tools/perf/config/Makefile
index 75b93d7,c516d6b..e4d06b2
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@@ -29,13 -29,9 +29,13 @@@ ifeq ($(ARCH),x86_64
NO_PERF_REGS := 0
LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
endif
+ifeq ($(ARCH),arm)
+ NO_PERF_REGS := 0
+ LIBUNWIND_LIBS = -lunwind -lunwind-arm
+endif

ifeq ($(NO_PERF_REGS),0)
- CFLAGS += -DHAVE_PERF_REGS
+ CFLAGS += -DHAVE_PERF_REGS_SUPPORT
endif

ifeq ($(src-perf),)
@@@ -93,20 -85,125 +89,126 @@@ CFLAGS += -std=gnu9

EXTLIBS = -lelf -lpthread -lrt -lm -ldl

- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -fstack-protector-all,-fstack-protector-all),y)
- CFLAGS += -fstack-protector-all
+ ifneq ($(OUTPUT),)
+ OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/
+ $(shell mkdir -p $(OUTPUT_FEATURES))
endif

- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wstack-protector,-Wstack-protector),y)
- CFLAGS += -Wstack-protector
+ feature_check = $(eval $(feature_check_code))
+ define feature_check_code
+ feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0)
+ endef
+
+ feature_set = $(eval $(feature_set_code))
+ define feature_set_code
+ feature-$(1) := 1
+ endef
+
+ #
+ # Build the feature check binaries in parallel, ignore errors, ignore return value and suppress output:
+ #
+
+ #
+ # Note that this is not a complete list of all feature tests, just
+ # those that are typically built on a fully configured system.
+ #
+ # [ Feature tests not mentioned here have to be built explicitly in
+ # the rule that uses them - an example for that is the 'bionic'
+ # feature check. ]
+ #
+ CORE_FEATURE_TESTS = \
+ backtrace \
+ dwarf \
+ fortify-source \
+ glibc \
+ gtk2 \
+ gtk2-infobar \
+ libaudit \
+ libbfd \
+ libelf \
+ libelf-getphdrnum \
+ libelf-mmap \
+ libnuma \
+ libperl \
+ libpython \
+ libpython-version \
+ libslang \
+ libunwind \
++ libunwind-debug-frame \
+ on-exit \
+ stackprotector \
+ stackprotector-all
+
+ #
+ # So here we detect whether test-all was rebuilt, to be able
+ # to skip the print-out of the long features list if the file
+ # existed before and after it was built:
+ #
+ ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+ test-all-failed := 1
+ else
+ test-all-failed := 0
+ endif
+
+ #
+ # Special fast-path for the 'all features are available' case:
+ #
+ $(call feature_check,all,$(MSG))
+
+ #
+ # Just in case the build freshly failed, make sure we print the
+ # feature matrix:
+ #
+ ifeq ($(feature-all), 0)
+ test-all-failed := 1
+ endif
+
+ ifeq ($(test-all-failed),1)
+ $(info )
+ $(info Auto-detecting system features:)
+ endif
+
+ ifeq ($(feature-all), 1)
+ #
+ # test-all.c passed - just set all the core feature flags to 1:
+ #
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
+ else
+ $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
+ endif
+
+ #
+ # Print the result of the feature test:
+ #
+ feature_print = $(eval $(feature_print_code)) $(info $(MSG))
+
+ define feature_print_code
+ ifeq ($(feature-$(1)), 1)
+ MSG = $(shell printf '...%30s: [ \033[32mon\033[m ]' $(1))
+ else
+ MSG = $(shell printf '...%30s: [ \033[31mOFF\033[m ]' $(1))
+ endif
+ endef
+
+ #
+ # Only print out our features if we rebuilt the testcases or if a test failed:
+ #
+ ifeq ($(test-all-failed), 1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_print,$(feat)))
+ $(info )
endif

- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-Wvolatile-register-var),y)
- CFLAGS += -Wvolatile-register-var
+ ifeq ($(feature-stackprotector-all), 1)
+ CFLAGS += -fstack-protector-all
+ endif
+
+ ifeq ($(feature-stackprotector), 1)
+ CFLAGS += -Wstack-protector
endif

- ifndef PERF_DEBUG
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ ifeq ($(DEBUG),0)
+ ifeq ($(feature-fortify-source), 1)
CFLAGS += -D_FORTIFY_SOURCE=2
endif
endif
@@@ -179,64 -274,55 +279,59 @@@ els
endif # NO_LIBELF

ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif
- ifeq ($(call try-cc,$(SOURCE_ELF_GETPHDRNUM),$(FLAGS_LIBELF),-DHAVE_ELF_GETPHDRNUM),y)
- CFLAGS += -DHAVE_ELF_GETPHDRNUM
- endif
+ CFLAGS += -DHAVE_LIBELF_SUPPORT

- # include ARCH specific config
- -include $(src-perf)/arch/$(ARCH)/Makefile
+ ifeq ($(feature-libelf-mmap), 1)
+ CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+ endif

- ifndef NO_DWARF
- ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
- msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
- NO_DWARF := 1
- else
- CFLAGS += -DDWARF_SUPPORT $(LIBDW_CFLAGS)
- LDFLAGS += $(LIBDW_LDFLAGS)
- EXTLIBS += -lelf -ldw
- endif # PERF_HAVE_DWARF_REGS
- endif # NO_DWARF
+ ifeq ($(feature-libelf-getphdrnum), 1)
+ CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+ endif

- endif # NO_LIBELF
+ # include ARCH specific config
+ -include $(src-perf)/arch/$(ARCH)/Makefile

- ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif # try-cc
+ ifndef NO_DWARF
+ ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
+ msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+ NO_DWARF := 1
+ else
+ CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
+ LDFLAGS += $(LIBDW_LDFLAGS)
+ EXTLIBS += -lelf -ldw
+ endif # PERF_HAVE_DWARF_REGS
+ endif # NO_DWARF
endif # NO_LIBELF

-# There's only x86 (both 32 and 64) support for CFI unwind so far
-ifneq ($(ARCH),x86)
+ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
endif

ifndef NO_LIBUNWIND
- # for linking with debug library, run like:
- # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
- ifdef LIBUNWIND_DIR
- LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
- LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
- endif
+ #
+ # For linking with debug library, run like:
+ #
+ # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+ #
+ ifdef LIBUNWIND_DIR
+ LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
+ LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
+ endif

- FLAGS_UNWIND=$(LIBUNWIND_CFLAGS) $(CFLAGS) $(LIBUNWIND_LDFLAGS) $(LDFLAGS) $(EXTLIBS) $(LIBUNWIND_LIBS)
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
- NO_LIBUNWIND := 1
- endif # Libunwind support
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND_DEBUG_FRAME),$(FLAGS_UNWIND),libunwind debug_frame),y)
- msg := $(warning No debug_frame support found in libunwind);
- CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
- endif # debug_frame support in libunwind
- endif # NO_LIBUNWIND
+ ifneq ($(feature-libunwind), 1)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
++ msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
+ NO_LIBUNWIND := 1
++ else
++ ifneq ($(feature-libunwind-debug-frame), 1)
++ msg := $(warning No debug_frame support found in libunwind);
++ CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
++ endif
+ endif
+ endif

ifndef NO_LIBUNWIND
- CFLAGS += -DLIBUNWIND_SUPPORT
+ CFLAGS += -DHAVE_LIBUNWIND_SUPPORT
EXTLIBS += $(LIBUNWIND_LIBS)
CFLAGS += $(LIBUNWIND_CFLAGS)
LDFLAGS += $(LIBUNWIND_LDFLAGS)
diff --cc tools/perf/config/feature-checks/Makefile
index 0000000,452b67c..abaf8f4
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@@ -1,0 -1,144 +1,148 @@@
+
+ FILES= \
+ test-all \
+ test-backtrace \
+ test-bionic \
+ test-dwarf \
+ test-fortify-source \
+ test-glibc \
+ test-gtk2 \
+ test-gtk2-infobar \
+ test-hello \
+ test-libaudit \
+ test-libbfd \
+ test-liberty \
+ test-liberty-z \
+ test-cplus-demangle \
+ test-libelf \
+ test-libelf-getphdrnum \
+ test-libelf-mmap \
+ test-libnuma \
+ test-libperl \
+ test-libpython \
+ test-libpython-version \
+ test-libslang \
+ test-libunwind \
++ test-libunwind-debug-frame \
+ test-on-exit \
+ test-stackprotector-all \
+ test-stackprotector
+
+ CC := $(CC) -MD
+
+ all: $(FILES)
+
+ BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ $@.c
+
+ ###############################
+
+ test-all:
+ $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-hello:
+ $(BUILD)
+
+ test-stackprotector-all:
+ $(BUILD) -Werror -fstack-protector-all
+
+ test-stackprotector:
+ $(BUILD) -Werror -fstack-protector -Wstack-protector
+
+ test-fortify-source:
+ $(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2
+
+ test-bionic:
+ $(BUILD)
+
+ test-libelf:
+ $(BUILD) -lelf
+
+ test-glibc:
+ $(BUILD)
+
+ test-dwarf:
+ $(BUILD) -ldw
+
+ test-libelf-mmap:
+ $(BUILD) -lelf
+
+ test-libelf-getphdrnum:
+ $(BUILD) -lelf
+
+ test-libnuma:
+ $(BUILD) -lnuma
+
+ test-libunwind:
+ $(BUILD) -lunwind -lunwind-x86_64 -lelf
+
++test-libunwind-debug-frame:
++ $(BUILD) -lunwind -lunwind-x86_64 -lelf
++
+ test-libaudit:
+ $(BUILD) -laudit
+
+ test-libslang:
+ $(BUILD) -I/usr/include/slang -lslang
+
+ test-gtk2:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ test-gtk2-infobar:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ grep-libs = $(filter -l%,$(1))
+ strip-libs = $(filter-out -l%,$(1))
+
+ PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
+ PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
+ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
+
+ test-libperl:
+ $(BUILD) $(FLAGS_PERL_EMBED)
+
+ override PYTHON := python
+ override PYTHON_CONFIG := python-config
+
+ escape-for-shell-sq = $(subst ','\'',$(1))
+ shell-sq = '$(escape-for-shell-sq)'
+
+ PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
+
+ PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+
+ test-libpython:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libpython-version:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libbfd:
+ $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-liberty:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
+
+ test-liberty-z:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz
+
+ test-cplus-demangle:
+ $(BUILD) -liberty
+
+ test-on-exit:
+ $(BUILD)
+
+ test-backtrace:
+ $(BUILD)
+
+ -include *.d
+
+ ###############################
+
+ clean:
+ rm -f $(FILES) *.d
diff --cc tools/perf/config/feature-checks/test-all.c
index 0000000,50d4318..ed8aa7b
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@@ -1,0 -1,106 +1,111 @@@
+ /*
+ * test-all.c: Try to build all the main testcases at once.
+ *
+ * A well-configured system will have all the prereqs installed, so we can speed
+ * up auto-detection on such systems.
+ */
+
+ /*
+ * Quirk: Python and Perl headers cannot be in arbitrary places, so keep
+ * these 3 testcases at the top:
+ */
+ #define main main_test_libpython
+ # include "test-libpython.c"
+ #undef main
+
+ #define main main_test_libpython_version
+ # include "test-libpython-version.c"
+ #undef main
+
+ #define main main_test_libperl
+ # include "test-libperl.c"
+ #undef main
+
+ #define main main_test_hello
+ # include "test-hello.c"
+ #undef main
+
+ #define main main_test_libelf
+ # include "test-libelf.c"
+ #undef main
+
+ #define main main_test_libelf_mmap
+ # include "test-libelf-mmap.c"
+ #undef main
+
+ #define main main_test_glibc
+ # include "test-glibc.c"
+ #undef main
+
+ #define main main_test_dwarf
+ # include "test-dwarf.c"
+ #undef main
+
+ #define main main_test_libelf_getphdrnum
+ # include "test-libelf-getphdrnum.c"
+ #undef main
+
+ #define main main_test_libunwind
+ # include "test-libunwind.c"
+ #undef main
+
++#define main main_test_libunwind_debug_frame
++# include "test-libunwind-debug-frame.c"
++#undef main
++
+ #define main main_test_libaudit
+ # include "test-libaudit.c"
+ #undef main
+
+ #define main main_test_libslang
+ # include "test-libslang.c"
+ #undef main
+
+ #define main main_test_gtk2
+ # include "test-gtk2.c"
+ #undef main
+
+ #define main main_test_gtk2_infobar
+ # include "test-gtk2-infobar.c"
+ #undef main
+
+ #define main main_test_libbfd
+ # include "test-libbfd.c"
+ #undef main
+
+ #define main main_test_on_exit
+ # include "test-on-exit.c"
+ #undef main
+
+ #define main main_test_backtrace
+ # include "test-backtrace.c"
+ #undef main
+
+ #define main main_test_libnuma
+ # include "test-libnuma.c"
+ #undef main
+
+ int main(int argc, char *argv[])
+ {
+ main_test_libpython();
+ main_test_libpython_version();
+ main_test_libperl();
+ main_test_hello();
+ main_test_libelf();
+ main_test_libelf_mmap();
+ main_test_glibc();
+ main_test_dwarf();
+ main_test_libelf_getphdrnum();
+ main_test_libunwind();
++ main_test_libunwind_debug_frame();
+ main_test_libaudit();
+ main_test_libslang();
+ main_test_gtk2(argc, argv);
+ main_test_gtk2_infobar(argc, argv);
+ main_test_libbfd();
+ main_test_on_exit();
+ main_test_backtrace();
+ main_test_libnuma();
+
+ return 0;
+ }
diff --cc tools/perf/config/feature-checks/test-libunwind-debug-frame.c
index 0000000,0000000..0ef8087
new file mode 100644
--- /dev/null
+++ b/tools/perf/config/feature-checks/test-libunwind-debug-frame.c
@@@ -1,0 -1,0 +1,16 @@@
++#include <libunwind.h>
++#include <stdlib.h>
++
++extern int
++UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
++ unw_word_t ip, unw_word_t segbase,
++ const char *obj_name, unw_word_t start,
++ unw_word_t end);
++
++#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
++
++int main(void)
++{
++ dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
++ return 0;
++}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Will Deacon
2013-10-25 13:30:03 UTC
Permalink
Post by Thierry Reding
Today's linux-next merge of the tip tree got conflicts in
tools/perf/config/Makefile
tools/perf/config/feature-tests.mak
caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
These came via my tree (arm perf) after discussion here:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html

Now that they've been pulled by rmk, we can't back them out with ugly
reverts, so I'm not sure what we can do to resolve in the ARM tree; it looks
like the perf Makefile has changed significantly in -tip.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2013-10-26 08:50:01 UTC
Permalink
Post by Will Deacon
Post by Thierry Reding
Today's linux-next merge of the tip tree got conflicts in
tools/perf/config/Makefile
tools/perf/config/feature-tests.mak
caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.

(Kernel side changes can go that route as well, as long as they are
perf related.)

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Will Deacon
2013-10-26 14:10:02 UTC
Permalink
Hi Ingo,

[adding rmk]
Post by Ingo Molnar
Post by Will Deacon
Post by Thierry Reding
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.
Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.

In future, I'll push back on any perf changes outside of arch/ in my tree,
but that doesn't help us get out of the current situation: the patches are
currently sitting in rmk's tree for 3.13, so that won't meet with -tip
(outside of next) until Linus pulls them both. What can we do about that?

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar
2013-10-27 07:20:01 UTC
Permalink
Post by Will Deacon
Hi Ingo,
[adding rmk]
Post by Ingo Molnar
Post by Will Deacon
Post by Thierry Reding
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.
Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.
That was a bit of unlucky timing.
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King - ARM Linux
2013-10-27 10:10:02 UTC
Permalink
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-28 07:50:01 UTC
Permalink
Post by Russell King - ARM Linux
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?
Hi Russell,

I've attached the relevant parts of the resolution, although I'm not
sure if anybody's actually confirmed that it's correct. FWIW, if I run

make tools/perf

I do get the expected output:

Auto-detecting system features:
... backtrace: [ on ]
... dwarf: [ on ]
... fortify-source: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
... gtk2-infobar: [ on ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ on ]
... libelf-getphdrnum: [ on ]
... libelf-mmap: [ on ]
... libnuma: [ OFF ]
... libperl: [ on ]
... libpython: [ on ]
... libpython-version: [ OFF ]
... libslang: [ OFF ]
... libunwind: [ on ]
... libunwind-debug-frame: [ OFF ]
... on-exit: [ on ]
... stackprotector: [ on ]
... stackprotector-all: [ on ]

Which I guess means that the version of libunwind that I have doesn't
enable debug-frame support, but that's as expected according to the
package build script.

Thierry
Russell King - ARM Linux
2013-10-28 08:50:02 UTC
Permalink
Post by Thierry Reding
Post by Russell King - ARM Linux
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?
Hi Russell,
I've attached the relevant parts of the resolution, although I'm not
sure if anybody's actually confirmed that it's correct.
I'm not sure whether that can happen any time before -final - Will is
(storm dependent) flying out to Linaro Connect today, and I've no idea
who to turn to for this to be tested for ARM.

I guess we have some time given that Linus has released -rc7 and his
comments during the Kernel Summit/in the rc7 announcement.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Thierry Reding
2013-10-25 13:10:03 UTC
Permalink
Today's linux-next merge of the c6x tree got a conflict in

arch/arm/Kconfig

caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
lockrefs using cmpxchg64) and commit d701884 (arm: select
ARCH_MIGHT_HAVE_PC_PARPORT).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
select CLONE_BACKWARDS
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:10:03 UTC
Permalink
Today's linux-next merge of the imx-mxs tree got a conflict in

arch/arm/mach-imx/mach-imx6q.c

caused by commits 6aec339 (PM / OPP: rename header to linux/pm_opp.h) and
0794410 (imx: add PCI fixup for PEX860X on Gateworks board).

I fixed it up (see below). Please verify that the resolution looks good.

Thanks,
Thierry
---
diff --cc arch/arm/mach-imx/mach-imx6q.c
index eae5642,1ac719d..bc98799
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@@ -23,8 -23,9 +23,10 @@@
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
- #include <linux/pm_opp.h>
+ #include <linux/opp.h>
+ #include <linux/pci.h>
#include <linux/phy.h>
++#include <linux/pm_opp.h>
#include <linux/reboot.h>
#include <linux/regmap.h>
#include <linux/micrel_phy.h>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mark Salter
2013-10-25 13:30:02 UTC
Permalink
Post by Thierry Reding
Today's linux-next merge of the c6x tree got a conflict in
arch/arm/Kconfig
caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
lockrefs using cmpxchg64) and commit d701884 (arm: select
ARCH_MIGHT_HAVE_PC_PARPORT).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
select CLONE_BACKWARDS
ARCH_USE_CMPXCHG_LOCKREF needs to come after ARCH_MIGHT_HAVE_PC_PARPORT
to keep things sorted alphabetically. Other than that, its fine.

--Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-25 13:40:03 UTC
Permalink
Post by Mark Salter
Post by Thierry Reding
Today's linux-next merge of the c6x tree got a conflict in
arch/arm/Kconfig
caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
lockrefs using cmpxchg64) and commit d701884 (arm: select
ARCH_MIGHT_HAVE_PC_PARPORT).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
select CLONE_BACKWARDS
ARCH_USE_CMPXCHG_LOCKREF needs to come after ARCH_MIGHT_HAVE_PC_PARPORT
to keep things sorted alphabetically. Other than that, its fine.
Right, I missed that. Will keep it in mind, although I guess today will
be my last tree for a while since Stephen mentioned that he would
probably take over on Monday.

Thierry
Russell King - ARM Linux
2013-10-26 13:30:01 UTC
Permalink
Post by Thierry Reding
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
Thanks. Generally we want these things to be arranged alphabetically to
reduce the longer term chances of hitting merge conflicts, but in this
case it wouldn't make any difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thierry Reding
2013-10-28 07:40:02 UTC
Permalink
Post by Russell King - ARM Linux
Post by Thierry Reding
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
Thanks. Generally we want these things to be arranged alphabetically to
reduce the longer term chances of hitting merge conflicts, but in this
case it wouldn't make any difference.
I was aiming for alphabetical order... guess I need to revisit my ABCs.

Thierry
Continue reading on narkive:
Loading...