From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC 3/6] system: add mdev-only /dev management (without devtmpfs)
Date: Fri, 18 Sep 2015 17:47:29 +0200 [thread overview]
Message-ID: <55FC3211.3010009@lucaceresoli.net> (raw)
In-Reply-To: <8737yevmy7.fsf@dell.be.48ers.dk>
Dear Peter,
Peter Korsgaard wrote:
>>>>>> "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?
I work both on new products and on mature products. But the latter
receive consistent updates at times, which might add a lot more packages
or change the dependencies.
In both cases I want a recent a fairly recent set of packages.
A few months ago I had to bump a library to a version that was not yet
stable at that time, and thus not yet in Buildroot, because it
implemented a method that we needed in an 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+:
Nope. Maybe because I'm currently working mostly on ARM9 machines, and
ARM9 is definitely "mature".
However I had to forced an "old" Sourcery toolchain (2013.05) for an
ARM9 project because I was getting mysterious runtime errors with
2014.05, the latest available in BR at that time.
>>>> 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/)
Interesting. I'll have a look... sometime.
--
Luca
next prev parent reply other threads:[~2015-09-18 15:47 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
2015-09-18 15:47 ` Luca Ceresoli [this message]
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=55FC3211.3010009@lucaceresoli.net \
--to=luca@lucaceresoli.net \
--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.