| Message ID | 1397849296-5517-1-git-send-email-rjbarnet@rockwellcollins.com |
|---|---|
| State | Rejected |
| Headers | show |
On Fri, Apr 18, 2014 at 9:28 PM, Ryan Barnett <rjbarnet@rockwellcollins.com> wrote: > From: Matt Poduska <mjpodusk@rockwellcollins.com> > > In the case where DEVTMPFS is desired for older kernels where the > support is experimental, it's still possible to enable the option in > the board's specific linux .config instead of relying on buildroot to > make the modification. Why? 2.6.32 is 5+ years old by now, and expecting modern SW to work with older kernels nowadays is probably not worth it. Udev has also required devtmpfs since quite a while, so I don't think you should read much into the "experimental" status. If the kernel really is that ancient that it doesn't have devtmpfs, then the .config mangling afaik becomes a noop, so I don't see what we gain by not doing it.
Dear Ryan Barnett, On Fri, 18 Apr 2014 14:28:16 -0500, Ryan Barnett wrote: > From: Matt Poduska <mjpodusk@rockwellcollins.com> > > In the case where DEVTMPFS is desired for older kernels where the > support is experimental, it's still possible to enable the option in > the board's specific linux .config instead of relying on buildroot to > make the modification. > > Signed-off-by: Matt Poduska <mjpodusk@rockwellcollins.com> > Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com> > --- > linux/linux.mk | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) Which problem is this fixing? I remember having used devtmpfs prior to 3.x, and it was working well. For versions prior to 2.6.32, the linux.mk code will set this option that doesn't exist, and the kconfig code of the kernel will simply get rid of it, without any consequences. So I'd like to understand the "why" of this patch :) Thanks! Thomas
Hi Ryan, Thomas, Thomas Petazzoni wrote: > Dear Ryan Barnett, > > On Fri, 18 Apr 2014 14:28:16 -0500, Ryan Barnett wrote: >> From: Matt Poduska <mjpodusk@rockwellcollins.com> >> >> In the case where DEVTMPFS is desired for older kernels where the >> support is experimental, it's still possible to enable the option in >> the board's specific linux .config instead of relying on buildroot to >> make the modification. >> >> Signed-off-by: Matt Poduska <mjpodusk@rockwellcollins.com> >> Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com> >> --- >> linux/linux.mk | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) > > Which problem is this fixing? I remember having used devtmpfs prior to > 3.x, and it was working well. For versions prior to 2.6.32, the And in fact I have targets here that are stuck on 2.6.37, they happily use devtmpfs and it works just fine. So I NACK this change, or if there's a strong motivation to apply it I would at least conceive a backward-compatibility path.
Luca, Peter, Thomas, All, Luca Ceresoli <luca@lucaceresoli.net> wrote on 04/22/2014 05:41:13 AM: > Hi Ryan, Thomas, > > Thomas Petazzoni wrote: >> Dear Ryan Barnett, >> >> On Fri, 18 Apr 2014 14:28:16 -0500, Ryan Barnett wrote: >>> From: Matt Poduska <mjpodusk@rockwellcollins.com> >>> >>> In the case where DEVTMPFS is desired for older kernels where the >>> support is experimental, it's still possible to enable the option in >>> the board's specific linux .config instead of relying on buildroot to >>> make the modification. >>> >>> Signed-off-by: Matt Poduska <mjpodusk@rockwellcollins.com> >>> Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com> >>> --- >>> linux/linux.mk | 8 +++++--- >>> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> Which problem is this fixing? I remember having used devtmpfs prior to >> 3.x, and it was working well. For versions prior to 2.6.32, the > > And in fact I have targets here that are stuck on 2.6.37, they happily > use devtmpfs and it works just fine. > > So I NACK this change, or if there's a strong motivation to apply it > I would at least conceive a backward-compatibility path. We recently ran into a issue where brought a board forward to use Buildroot 2014.02 that we kept at a kernel version of 2.6.33. Yes, I agree that we should be using a new kernel but the work to port to a newer version is too great but we needed to upgrade some package versions. The system was unable to boot because DEVTMPFS_MOUNT was enabled in kernel config. We traced the issue back to Buildroot automatically enabling these options in our kernel config. There was no way to not include this kernel config option when BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled. We will try to analyze to see if there is a better way to get around this issue but I'm OK with this patch being rejected. Since this is mostly for legacy support and who wants to do that ;) Thanks, -Ryan
>>>>> "rjbarnet" == rjbarnet <rjbarnet@rockwellcollins.com> writes: Hi, > We recently ran into a issue where brought a board forward to use Buildroot > 2014.02 that we kept at a kernel version of 2.6.33. Yes, I agree that we should > be using a new kernel but the work to port to a newer version is too great but > we needed to upgrade some package versions. The system was unable to boot > because DEVTMPFS_MOUNT was enabled in kernel config. We traced the issue back > to Buildroot automatically enabling these options in our kernel config. There > was no way to not include this kernel config option when > BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled. Huh, but we ONLY enable it if BR2_ROOTFS_DEVICE_CREATION_STATIC isn't enabled - So why not just enabled it?
Peter, Peter Korsgaard <jacmet@gmail.com> wrote on 04/24/2014 01:49:14 AM: > >>>>> "rjbarnet" == rjbarnet <rjbarnet@rockwellcollins.com> writes: > > Hi, > > > We recently ran into a issue where brought a board forward to use Buildroot > > 2014.02 that we kept at a kernel version of 2.6.33. Yes, I agree that we should > > be using a new kernel but the work to port to a newer version is too great but > > we needed to upgrade some package versions. The system was unable to boot > > because DEVTMPFS_MOUNT was enabled in kernel config. We traced the issue back > > to Buildroot automatically enabling these options in our kernel config. There > > was no way to not include this kernel config option when > > BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled. > > Huh, but we ONLY enable it if BR2_ROOTFS_DEVICE_CREATION_STATIC isn't > enabled - So why not just enabled it? I meant to say, "when BR2_ROOTFS_DEVICE_CREATION_STATIC is NOT enabled". Sorry for the confusion and thanks for the clarification. Thanks, -Ryan
>>>>> "Ryan" == Ryan Barnett <rjbarnet@rockwellcollins.com> writes: Hi, >> > was no way to not include this kernel config option when >> > BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled. >> >> Huh, but we ONLY enable it if BR2_ROOTFS_DEVICE_CREATION_STATIC isn't >> enabled - So why not just enabled it? > I meant to say, "when BR2_ROOTFS_DEVICE_CREATION_STATIC is NOT enabled". > Sorry for the confusion and thanks for the clarification. Ok, but the point of the other options are that they REALLY need devtmpfs support in the kernel, so if you don't want to use that then you should really select static /dev. mdev could be made to work without devtmpfs, but not in the setup we support.
Peter, Peter Korsgaard <jacmet@gmail.com> wrote on 04/24/2014 03:00:48 PM: >>>>>> "Ryan" == Ryan Barnett <rjbarnet@rockwellcollins.com> writes: > > Hi, > >>>> was no way to not include this kernel config option when >>>> BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled. >>> >>> Huh, but we ONLY enable it if BR2_ROOTFS_DEVICE_CREATION_STATIC isn't >>> enabled - So why not just enabled it? > >> I meant to say, "when BR2_ROOTFS_DEVICE_CREATION_STATIC is NOT enabled". >> Sorry for the confusion and thanks for the clarification. > > Ok, but the point of the other options are that they REALLY need > devtmpfs support in the kernel, so if you don't want to use that then > you should really select static /dev. > > mdev could be made to work without devtmpfs, but not in the setup we > support. Looking back the configuration that was causing the issue, this is the exact corner case that we need to support - mdev without devtmpfs. Thanks, -Ryan
diff --git a/linux/linux.mk b/linux/linux.mk index e270705..694ea16 100644 --- a/linux/linux.mk +++ b/linux/linux.mk @@ -183,9 +183,11 @@ define LINUX_CONFIGURE_CMDS $(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_SOURCE,\"$(BINARIES_DIR)/rootfs.cpio\",$(@D)/.config) $(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_UID,0,$(@D)/.config) $(call KCONFIG_SET_OPT,CONFIG_INITRAMFS_ROOT_GID,0,$(@D)/.config)) - $(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),, - $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config) - $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config)) + # Kernels prior to 2.6.32 don't support DEVTMPFS, which is also experimental prior to 3.x + $(if $(findstring x2.6.,x$(LINUX_VERSION)),, + $(if $(BR2_ROOTFS_DEVICE_CREATION_STATIC),, + $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS,$(@D)/.config) + $(call KCONFIG_ENABLE_OPT,CONFIG_DEVTMPFS_MOUNT,$(@D)/.config))) $(if $(BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV), $(call KCONFIG_ENABLE_OPT,CONFIG_INOTIFY_USER,$(@D)/.config)) $(if $(BR2_PACKAGE_KTAP),