From: Stephen Rothwell <hidden> Date: 2011-08-22 01:30:59
Hi Dave,
On Wed, 17 Aug 2011 22:53:56 -0700 (PDT) David Miller [off-list ref] wrote:
From: Stephen Rothwell <redacted>
Date: Thu, 18 Aug 2011 15:22:14 +1000
quoted
Mikey asks: Will Dave take these updates if we get Acks from the
maintainers? :-)
I'm more than happy to :-)
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
This has no Acks yet, but produces a very similar .config to what we had
previously.
From: Stephen Rothwell <redacted>
Date: Mon, 22 Aug 2011 11:23:56 +1000
Subject: [PATCH] powerpc: update ppc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <redacted>
---
arch/powerpc/configs/ppc64_defconfig | 71 +++++++++++++--------------------
1 files changed, 28 insertions(+), 43 deletions(-)
@@ -75,7 +74,6 @@ CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # CONFIG_IPV6 is not set CONFIG_NETFILTER=y-CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_SCTP=m
@@ -331,7 +325,6 @@ CONFIG_USB=y CONFIG_USB_DEVICEFS=y CONFIG_USB_MON=m CONFIG_USB_EHCI_HCD=y-CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_EHCI_HCD_PPC_OF is not set CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=m
From: Stephen Rothwell <hidden> Date: 2011-08-23 01:40:19
Hi Dave,
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell [off-list ref] wrote:
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
And this today:
From: Stephen Rothwell <redacted>
Date: Tue, 23 Aug 2011 11:23:40 +1000
Subject: [PATCH] sparc: update sparc32_defconfig for net device movement
Signed-off-by: Stephen Rothwell <redacted>
---
arch/sparc/configs/sparc32_defconfig | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
@@ -64,26 +63,22 @@ CONFIG_SERIAL_SUNSU=y CONFIG_SERIAL_SUNSU_CONSOLE=y CONFIG_SPI=y CONFIG_SPI_XILINX=m-CONFIG_SPI_XILINX_PLTFM=m CONFIG_SUN_OPENPROMIO=m CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y-CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_ISO9660_FS=m CONFIG_PROC_KCORE=y CONFIG_ROMFS_FS=m CONFIG_NFS_FS=y CONFIG_ROOT_NFS=y-CONFIG_RPCSEC_GSS_KRB5=m CONFIG_NLS=y # CONFIG_ENABLE_WARN_DEPRECATED is not set CONFIG_DEBUG_KERNEL=y CONFIG_DETECT_HUNG_TASK=y # CONFIG_SCHED_DEBUG is not set-# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_KGDB=y CONFIG_KGDB_TESTS=y CONFIG_CRYPTO_NULL=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell <hidden> Date: 2011-08-23 01:41:33
Hi Dave,
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell [off-list ref] wrote:
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
And this today:
And this:
From: Stephen Rothwell <redacted>
Date: Tue, 23 Aug 2011 11:35:18 +1000
Subject: [PATCH] sparc: update sparc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <redacted>
---
arch/sparc/configs/sparc64_defconfig | 20 +++++++++-----------
1 files changed, 9 insertions(+), 11 deletions(-)
@@ -95,17 +93,19 @@ CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_NETDEVICES=y-CONFIG_NET_ETHERNET=y CONFIG_MII=m+CONFIG_NET_VENDOR_AMD=y CONFIG_SUNLANCE=m+CONFIG_NET_VENDOR_BROADCOM=y+CONFIG_BNX2=m+CONFIG_TIGON3=m+CONFIG_NET_VENDOR_INTEL=y+CONFIG_E1000=m+CONFIG_E1000E=m+CONFIG_NET_VENDOR_SUN=y CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_SUNVNET=m-CONFIG_NET_PCI=y-CONFIG_E1000=m-CONFIG_E1000E=m-CONFIG_TIGON3=m-CONFIG_BNX2=m CONFIG_NIU=m # CONFIG_WLAN is not set CONFIG_PPP=m
@@ -126,13 +126,13 @@ CONFIG_INPUT_SPARCSPKR=y # CONFIG_SERIO_SERPORT is not set CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_RAW=m+# CONFIG_LEGACY_PTYS is not set # CONFIG_DEVKMEM is not set CONFIG_SERIAL_SUNSU=y CONFIG_SERIAL_SUNSU_CONSOLE=y CONFIG_SERIAL_SUNSAB=y CONFIG_SERIAL_SUNSAB_CONSOLE=y CONFIG_SERIAL_SUNHV=y-# CONFIG_LEGACY_PTYS is not set CONFIG_FB=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_SBUS=y
@@ -206,10 +206,8 @@ CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_KERNEL=y CONFIG_LOCKUP_DETECTOR=y-CONFIG_DETECT_HUNG_TASK=y # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y-# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_KEYS=y
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: David Miller <davem@davemloft.net> Date: 2011-08-23 02:18:37
From: Stephen Rothwell <redacted>
Date: Tue, 23 Aug 2011 11:41:29 +1000
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
And this today:
And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig changes
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. Could you prepare a patch which does that?
From: Jeff Kirsher <hidden> Date: 2011-08-23 02:27:07
On Mon, 2011-08-22 at 19:13 -0700, David Miller wrote:
From: Stephen Rothwell <redacted>
Date: Tue, 23 Aug 2011 11:41:29 +1000
quoted
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell [off-list ref] wrote:
quoted
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
And this today:
And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig changes
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. Could you prepare a patch which does that?
I was just finishing up those patches (not including any defconfig
changes) and started looking at a patch to fix/resolve the issues that
Stephen is seeing.
Let me see what I can come up with tonight to resolve this.
Hi,
[Added linux-kbuild@ to the Cc: list.]
On Mon, Aug 22, 2011 at 10:13 PM, David Miller [off-list ref] wrote:
From: Stephen Rothwell <redacted>
Date: Tue, 23 Aug 2011 11:41:29 +1000
quoted
On Tue, 23 Aug 2011 11:40:11 +1000 Stephen Rothwell <sfr@canb.auug.org.a=
u> wrote:
quoted
quoted
On Mon, 22 Aug 2011 11:30:32 +1000 Stephen Rothwell <sfr@canb.auug.org.=
au> wrote:
quoted
quoted
quoted
Here's what I am applying as a merge fixup to the net tree today so t=
hat
quoted
quoted
quoted
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
And this today:
And this:
I'm starting to get uncomfortable with this whole situation, and I
feel more and more that these new kconfig guards are not tenable.
Changing defconfig files might fix the "automated test boot with
defconfig" case but it won't fix the case of someone trying to
automate a build and boot using a different, existing, config file.
It ought to work too, and I do know people really do this.
And just the fact that we would have to merge all of these defconfig chan=
ges
through the networking tree is evidence of how it's really not reasonable
to be doing things this way.
Jeff, I think we need to revert the dependencies back to what they were
before the drivers/net moves. =A0Could you prepare a patch which does tha=
t?
Are you implying we need some kind of way to migrate config ?
- Arnaud
Are you implying we need some kind of way to migrate config ?
The issue is that the dependencies for every single ethernet driver
have changed. Some dependencies have been dropped (f.e. NETDEV_10000
and some have been added (f.e. ETHERNET, NET_VENDOR_****)
So right now an automated (non-prompted, default to no on all new
options) run on an existing config results in all ethernet drivers
getting disabled because the new dependencies don't get enabled.
This wouldn't be so bad if it was just one or two drivers, but in
this case it's every single ethernet driver which will have and hit
this problem.
Are you implying we need some kind of way to migrate config ?
The issue is that the dependencies for every single ethernet driver
have changed. Some dependencies have been dropped (f.e. NETDEV_10000
and some have been added (f.e. ETHERNET, NET_VENDOR_****)
So right now an automated (non-prompted, default to no on all new
options) run on an existing config results in all ethernet drivers
getting disabled because the new dependencies don't get enabled.
This wouldn't be so bad if it was just one or two drivers, but in
this case it's every single ethernet driver which will have and hit
this problem.
Ok, I have patch which will resolve the issue. It is the last patch in
the series I am about to send out. What this patch does is set the
"new" Kconfig options to Y, so that current defconfig's can build
driver's that are currently set to build.
This will fix the issue, I have confirmed this with the x86_64
defconfig. It will be nice that eventually all configs get updated so
that not all the NET_VENDOR_* tags have to be enabled, but
understandably this is the best way to ensure that current defconfig's
will compile all expected drivers.