On Wed, 20 Mar 2013 08:29:35 +0100 Eric Herman <[email protected]> wrote:
> On 03/20/2013 03:27 AM, Kirk Terrell wrote: > > On 03/19/2013 06:16 PM, Andrew Bradford wrote: > >> On Tue, 19 Feb 2013 19:35:23 -0800 > >> Kirk Terrell <[email protected]> wrote: > > >> Is it worth keeping ARM big endian around in the embedded book? > >> > >> If not, then that easily begs the question of if it's worth > >> keeping the wrt "arch" around since it's just MIPS but with a few > >> tweaks to support the WRT routers. > >> > >> I don't want to rip out useful things, but due to low developer > >> time for the embedded book, reducing the number of > >> configurations / archs supported seems like a reasonable thing to > >> do. Based on memory, most of the people building the embedded book > >> are doing so on ARM little endian armv5 or armv7-a with a few here > >> and there doing x86 or MIPS. > >> > >> What do you, and the list, think? > > The "arch" is still useful for several routers, e.g.: I have a > WL-700gE which is MIPS ... but personally, I follow the regular CLFS > book, not the embedded book. Thanks for that info. Since late 2010, when I started paying attention to the embedded book, I'm not sure I've actually seen any questions about MIPS for embedded. A reasonable number of people write to -support or -dev asking about x86 and ARM, though. > I have no idea if anyone does anything with ARM following the > embedded book. I have a RaspberryPi, but when I get around to it, > I'll probably be CLFSing it from the regular book. ARM's not in the normal CLFS book, it's only currently in the (quite outdated) sysroot and (only somewhat outdated) embedded books. Realistically, adding ARM to normal CLFS shouldn't be hard, it just hasn't been done, yet. > Since the books are not executable, and it's not simply a matter of > getting some hardware donated and pressing the "go" button, it > requires someone to invest non-trivial time and effort. I agree. QEMU can help here but it's not quite the same. > While it may be a bit disappointing, unless someone offers to invest > the time to maintain the various architectures for the embedded book, > I think it is very reasonable to remove them -- perhaps replace them > with a note that other architectures have been supported in the past. <snip> > P.S.: Too much do I see that I fall victim to letting the pursuit of > perfection undermine my ability to deliver something of value. > Generally, I think it is better to have progress on something small > than have something bigger and better which never delivers. I was thinking that maybe it makes the most sense to take the embedded book in a direction where it targets a few different very popular boards, like the Beagles, Panda, Raspberry Pi, etc. That way the book can be much more specific about what options to choose based on what board you have and there's probably a much higher likelihood of success for people just trying the embedded book out the first time. This is especially true for bootloaders and kernel builds if mainline doesn't yet support a popular board (which happens often). What do you think of that idea? -Andrew _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
