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: Sat, 16 Jan 2016 11:52:03 +0100 [thread overview]
Message-ID: <569A20D3.2080304@openwrt.org> (raw)
In-Reply-To: <87wpr9x161.fsf@dell.be.48ers.dk>
On 2016-01-16 11:35, Peter Korsgaard wrote:
>>>>>> "Felix" == Felix Fietkau <nbd at openwrt.org> writes:
>
> >>> 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.
>
> Agreed, only the options absolutely needed should be forced on.
>
> >> 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.
>
> Out of interest, why is that? Devtmpfs got added 7 years ago (2.6.32) -
> And is easy to backport if really needed, is easier and more flexible
> than a bunch of static mknods, and probably smaller as well.
We don't need to backport anything. Our oldest kernel is 3.18, and we're
going to move everything to 4.4 soon ;)
> We changed to devtmpfs by default in Buildroot quite some time ago, and
> I'm pretty happy with it.
We need to have dynamically created device nodes anyway - for managing
permissions, being able to change names, etc. Because of that, devtmpfs
is not enough to provide a full /dev. Since it's not enough, and
creating the initial device nodes from our custom init is easy, we see
little value in keeping it. So we got rid of the extra bloat :)
- Felix
next prev parent reply other threads:[~2016-01-16 10:52 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
2016-01-16 10:35 ` Peter Korsgaard
2016-01-16 10:52 ` Felix Fietkau [this message]
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=569A20D3.2080304@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.