Date:	Fri, 17 Aug 2007 15:46:24 -0700
From:	David Brownell <david-b@...bell.net>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	"Hennerich, Michael" <Michael.Hennerich@...log.com>,
	"Bryan Wu" <bryan.wu@...log.com>, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH 01/12] Blackfin arch: add peripheral resource allocation support

On Friday 17 August 2007, Robin Getz wrote:
> On Fri 17 Aug 2007 17:10, David Brownell pondered:
> > On the other hand, maybe you want your "typical" customer to
> > be more of a systems integrator than anything else.
> 
> We are getting yelled at by our customers (I was on the phone yesterday), 
> because the kernel build environment we distribute (the default) was not 
> inside Eclipse, and someone couldn't push a button on a GUI rather than 
> typing "make".

Press the "enter" button after typing "make".  ;)


> While Linux and other open source software is free, for some taking advantage 
> of its benefits can require a significant investment in time. Linux is 
> powerful, rich, and flexible. It is these very characteristics that make 
> Linux so appealing that also create a significant level of complexity.

Yes.

 
> We are seeing more and more "first time buyers" jumping from bare metal - no 
> OS, to Linux. For them - the ease of not having to write configuration files 
> gives them a warm fuzzy feeling when they boot their board, and it 
> just "works".

There's certainly a lot to be said for having things
just work the first time when you're making such a big
transition in tools.  On the other hand, at some point
the training wheels need to come off!



> > > >That said, how you handle pinmux on Blackfin is your business.
> > > >
> > > >But you should know that this approach seems idiosyncratic and
> > > >more complex than needed:  when pin config is done early and as
> > > >part of board setup, drivers don't need to care about it or to
> > > >handle any pinmux errors.  And heck, products can sometimes be
> > > >shipped with the bootloader having done all pinmux setup, so
> > > >Linux won't need to worry about it at all.  That can help ship
> > > >multiple board revisions using the same kernel.
> > > 
> > > This works for fixed function boards.
> > 
> > That is, for typical products embedding Linux...
> 
> We have multiple customers shipping the same bootloader/kernel binary on 
> different products, and the only difference is the /etc/rc file - which 
> drivers they install, and a few things in userspace.

Be careful there.  Remember that the driver model is predicated
on knowing the devices first, and *then* matching drivers.  I
expect you *will* see problems if you get people thinking system
config comes from a "which driver" selection rather than "here's
the exact hardware that's available".  Maybe configfs should be
used for device config.


> Could this be smaller - sure - but NAND is cheap (according to them) compared 
> to the effort and cost of maintaining and testing multiple kernel versions 
> for every product.
>  
> Could this be faster - sure - but it is done at init - and then never again. 
> We have a ~2-3 second boot time - maybe we shave off a few ms - things go 
> pretty fast at 600MHz.

I'm more used to clock rates less than 1/3 that much.  :)

- Dave


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists