1 |
2008/11/20 Ryan Tandy <tarpman@×××××.com>: |
2 |
> On Wed, Nov 19, 2008 at 11:13:46AM -0000, Gareth McClean wrote: |
3 |
>> a) Do any open source projects target the initial setup of an embedded |
4 |
>> system i.e. basics like manually configuring an Ethernet port, configuration |
5 |
>> of wireless networking or possibly other essentials like hostname, timezone, |
6 |
>> etc? |
7 |
> |
8 |
> ... |
9 |
>> b) If not, do you perform your 'out-of-the-box setup' i.e. did you create |
10 |
>> your own set of tools using packages like awk, sed, perl etc? |
11 |
> |
12 |
> Again, depending on the scale of the project, I use either a stripped |
13 |
> down Gentoo system or a simple Busybox-based system. |
14 |
> |
15 |
I just set up a control board and was also wondering about the best way to |
16 |
create a runtime root. Since a control board only requires a few packages, |
17 |
busybox ended up being really simple. I put the kernel and rootfs in ram |
18 |
and let the user manually extend it by mounting a drive |
19 |
on /usr/local where they can dump any extra binaries and libs they want. |
20 |
But I wouldn't recommend it for a system where you wanted to pile on |
21 |
packages up to the point of needing an x server. |
22 |
|
23 |
I also tried gentoo's crossdev to create a root fs, thinking that would be |
24 |
really easy just to xmerge in the right packages. But you end up with alot |
25 |
of cruft that way, and the other problem is most ebuilds aren't set up to |
26 |
work with cross-compiling out of the box (lots of bugs), so xmerge falls |
27 |
over alot. |
28 |
|
29 |
The other option I tried is openembedded. Which for me, was using a sledge |
30 |
hammer on a tiny nail. Probably really good as your embedded project scales |
31 |
up though - it gives you a way of defining your filesystem/package |
32 |
configuration. |
33 |
|
34 |
>> c) How are you communicating with the user during the installation process? |
35 |
> |
36 |
> Most of the systems I'm used to aren't designed to be installed by a |
37 |
> user - at least the software side of things. |
38 |
> |
39 |
>> c) Are there any intentions to migrate the Linux 'system configuration' into |
40 |
>> a machine readable format like XML. |
41 |
> |
42 |
> No. Do you have any idea how long it takes to read and write XML? |
43 |
> |
44 |
>> Ignore that that might sound like a call to implement the equivalent |
45 |
>> of the windows registry |
46 |
> |
47 |
> It doesn't, although it does sound like unnecessary overhead. |
48 |
> |
49 |
>> and focus on the fact I am concerned about the potential issues of |
50 |
>> processing unstructured, human readable text files |
51 |
> |
52 |
> Which issues? All of the base system configuration files seem fairly |
53 |
> structured to me. At any rate I'd much rather be parsing simple text |
54 |
> files than XML. Which files are you having trouble with? |
55 |
> |
56 |
>> and want an easy/reliable way to programmatically change the system |
57 |
>> configuration and manage future system updates. |
58 |
> |
59 |
> Most people that I know of solve these problems with shell or |
60 |
> perl/python/language-of-the-moment scripts. |
61 |
> |
62 |
> Bear in mind that these are just my opinions; other people on the list |
63 |
> will doubtless disagree with them. :) |
64 |
> |
65 |
> Thanks, |
66 |
> Ryan |
67 |
> |
68 |
> |