From: nbd@openwrt.org (Felix Fietkau)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH 2/2] arc770: move arc patches to taregt/linux/generic
Date: Fri, 15 Jan 2016 15:29:32 +0100 [thread overview]
Message-ID: <5699024C.5010300@openwrt.org> (raw)
In-Reply-To: <C2D7FE5348E1B147BCA15975FBA23075F4E851F3@us01wembx1.internal.synopsys.com>
On 2016-01-15 14:17, Vineet Gupta wrote:
> On Friday 15 January 2016 06:29 PM, Felix Fietkau wrote:
>>>>>> +Subject: [PATCH 1/2] openwrt: arc - remove dependency on DEVTMPFS
>>>>>> >>>> +
>>>>>> >>>> +OpenWRT builds initramfs so that it doesn't require DEVTMPFS so dropping
>>>>>> >>>> +this dependency.
>>> >
>>> > Really ? AFAIKR (circa 2012) DEVTMPFS was *needed* for dynamic device nodes and
>>> > that included the common case of initramfs NOT having static device nodes.
>>> >
>>> > So back then I added the code in question to kernel Kconfig because initramfs was
>>> > my primary workflow and occassionally I would fail to include DEVTMPFS causing
>>> > userspace boot to go bonkers (FWIW I was using the buildroot trick of a pre-init
>>> > script which would automount devtmpfs before exec'ing the real init)
>>> >
>>> > Now arguably I can add DEVTMPFS to defconfigs, but then we don't need the kconfig
>>> > dependency framework at all.
>>> >
>>> > Another idea is to add DEVTMPFS unconditionally to Kconfig, but I fail to remember
>>> > why I didn't do it at the time. Does anyone know if it interferes with real rootfs
>>> > backed by real devices ?
>> OpenWrt works just fine without DEVTMPFS - doesn't matter if initramfs
>> is enabled or not.
>
> The discussion is about adding a patch to up upstream ARC kernel, not specific to
> openwrt.
Right. I belive that the upstream kernel should not arbitrarily force
DEVTMPFS support for some architectures, as long as there are user space
implementations (such as OpenWrt) that can do without it.
> BTW if openwrt builds for initramfs, it has to enable DEVTMPFS under the hood.
> Perhaps there are dependencies in openwrt build system which take care of that
> already - o/w it just won't work (assuming dynamic dev nodes).
Incorrect. OpenWrt does not use DEVTMPFS, it does not even get compiled
into the image. We would like to keep it that way.
Our user space takes care of creating all required device nodes very
early during boot.
- Felix
next prev parent reply other threads:[~2016-01-15 14:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1452813142-9857-1-git-send-email-abrodkin@synopsys.com>
[not found] ` <1452813142-9857-3-git-send-email-abrodkin@synopsys.com>
[not found] ` <5698CDBD.2010908@openwrt.org>
2016-01-15 10:49 ` [PATCH 2/2] arc770: move arc patches to taregt/linux/generic Alexey Brodkin
2016-01-15 12:25 ` Vineet Gupta
2016-01-15 12:59 ` Felix Fietkau
2016-01-15 13:17 ` Vineet Gupta
2016-01-15 14:29 ` Felix Fietkau [this message]
2016-01-16 10:35 ` Peter Korsgaard
2016-01-16 10:52 ` Felix Fietkau
2016-01-16 11:00 ` Peter Korsgaard
2016-01-16 14:12 ` Felix Fietkau
2016-01-20 8:05 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5699024C.5010300@openwrt.org \
--to=nbd@openwrt.org \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.