From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Wed, 16 Sep 2015 09:32:32 +0200 [thread overview]
Message-ID: <8737yevmy7.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <55F89C46.3010904@lucaceresoli.net> (Luca Ceresoli's message of "Wed, 16 Sep 2015 00:31:34 +0200")
>>>>> "Luca" == Luca Ceresoli <luca@lucaceresoli.net> writes:
Hi,
>> Sure, I get that. I just question the sensibility of combining a 6+ year
>> old kernel with modern user space.
> I agree with you on the principle, but in the practice I have devices
> running very fine on 2.6.30 and some user space applications using
> C++11.
Ok, and are you actively doing system level development, or "just"
adjusting a single application on a mature product? E.G. are you
interested in getting the latest versions of all the libraries or rather
freeze the entire system except for your application?
> Yes, I used a fairly recent toolchain (gcc 4.8 IIRC), which is
> of course a bad idea, I know... But in the practice it works.
Then you presumably already had to backport kernel fixes to build with
4.8? E.G. I've worked on a system stuck on 2.6.37 where I had to
backport this to get it to run with gcc 4.7+:
commit 8428e84d42179c2a00f5f6450866e70d802d1d05
Author: Catalin Marinas <catalin.marinas@arm.com>
Date: Mon Nov 7 18:05:53 2011 +0100
ARM: 7150/1: Allow kernel unaligned accesses on ARMv6+ processors
Recent gcc versions generate unaligned accesses by default on ARMv6 and
later processors. This patch ensures that the SCTLR.A bit is always
cleared on such processors to avoid kernel traping before
alignment_init() is called.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: John Linn <John.Linn@xilinx.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: stable at vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> I had to spend a little time to check some packages that try to use
> kernel features not available in the running kernel. IIRC I only had
> issues with dhcpcd which tends to use recently-introduced
> syscalls. Other packaged run without problems.
I've personally had issues with network-manager (and dhcpcd like you
said) as well.
>> I agree that it isn't a _LOT_ of complexity, but it isn't non trivial
>> either.
> FWIW, it's even less complex in the v2 patchset that's half-brewed here.
True.
>> > I'm not sure how complicated it is to backport devtmpfs. However I
>> > would suspect that it isn't that easy.
>>
>> Take a look at 2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b in the
>> kernel. To me it looks quite self contained, so backporting it to
>> something close to 2.6.32 doesn't look too bad.
> I think I had a look a couple of years ago when I did the first project
> on the same SoC. I think I had a look and found it non trival, but the
> product to create had no hotplugging capabilities and no firmware
> loading needs, so I just went for a static /dev.
> Now I have a real goal, so I might try harder to look into backporting
> devtmpfs.
It seems doable to backport devtmpfs support to 2.6.30.
I just tried cherry-picking 6fcf53acccf85b4 + 2b2af54a5bb6f7e80ccf7 and
I only get a trivial conflict about some header files getting added to
init/main.c
To give it a quick test I tweaked our qemu_x86_defconfig to build 2.6.30
+ the two backports and booted it:
Welcome to Buildroot
buildroot login: root
# uname -a
Linux buildroot 2.6.30-00193-g9a8d49a #3 Wed Sep 16 09:27:23 CEST 2015 i686 GNU/Linux
# grep devtmpfs /proc/mounts
devtmpfs /dev devtmpfs rw,size=63272k,nr_inodes=15818 0 0
(I did have to fix the kernel a bit to get it to build with sourcery
codebench 2011.09, E.G. gcc 4.6.1 - But that was just s/-m elf_x86/-m32/)
>> I agree, the patches themselves are very nice work!
> Thanks both! :)
You're welcome.
--
Venlig hilsen,
Peter Korsgaard
next prev parent reply other threads:[~2015-09-16 7:32 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 21:28 [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 1/6] Move mounting /sys from fstab to inittab Luca Ceresoli
2015-09-09 9:12 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 2/6] system: clarify /dev management using devtmpfs + {mdev, eudev} Luca Ceresoli
2015-09-09 9:40 ` Arnout Vandecappelle
2015-09-09 10:53 ` Luca Ceresoli
2015-09-09 10:54 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs) Luca Ceresoli
2015-09-09 9:21 ` Arnout Vandecappelle
2015-09-09 12:29 ` Luca Ceresoli
2015-09-09 12:32 ` Arnout Vandecappelle
2015-09-09 13:54 ` Thomas Petazzoni
2015-09-14 13:47 ` Luca Ceresoli
2015-09-14 22:23 ` Arnout Vandecappelle
2015-09-15 22:35 ` Luca Ceresoli
2015-09-14 20:53 ` Peter Korsgaard
2015-09-14 21:34 ` Thomas Petazzoni
2015-09-14 21:38 ` Peter Korsgaard
2015-09-15 7:30 ` Thomas Petazzoni
2015-09-15 8:09 ` Peter Korsgaard
2015-09-15 9:41 ` Thomas Petazzoni
2015-09-15 12:01 ` Peter Korsgaard
2015-09-15 12:27 ` Arnout Vandecappelle
2015-09-15 12:32 ` Peter Korsgaard
2015-09-18 16:37 ` Luca Ceresoli
2015-09-15 13:03 ` Thomas Petazzoni
2015-09-15 13:14 ` Peter Korsgaard
2015-09-15 22:34 ` Luca Ceresoli
2015-10-01 9:36 ` Luca Ceresoli
2015-10-01 10:03 ` Peter Korsgaard
2015-09-15 22:31 ` Luca Ceresoli
2015-09-16 7:32 ` Peter Korsgaard [this message]
2015-09-18 15:47 ` Luca Ceresoli
2015-09-09 9:34 ` Arnout Vandecappelle
2015-09-09 11:23 ` Thomas Petazzoni
2015-09-09 11:29 ` Thomas Petazzoni
2015-09-09 20:33 ` Arnout Vandecappelle
2015-09-14 16:07 ` Luca Ceresoli
2015-09-14 16:05 ` Luca Ceresoli
2015-09-14 19:34 ` Thomas Petazzoni
2015-09-14 20:19 ` Arnout Vandecappelle
2015-09-15 22:07 ` Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 4/6] system: strip the initial /dev for mdev-only /dev management Luca Ceresoli
2015-09-08 21:28 ` [Buildroot] [RFC 5/6] docs/manual: document "Dynamic using mdev only" " Luca Ceresoli
2015-09-09 10:39 ` Arnout Vandecappelle
2015-09-08 21:28 ` [Buildroot] [RFC 6/6] **** DO NOT COMMIT THIS **** ugly stuff to test mdev-only " Luca Ceresoli
2015-09-09 9:26 ` [Buildroot] [RFC 0/6] mdev-only /dev management (without devtmpfs) Arnout Vandecappelle
2015-09-09 11:30 ` Thomas Petazzoni
2015-09-14 21:03 ` Peter Korsgaard
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=8737yevmy7.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@busybox.net \
/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.