On Tue, Sep 04, 2012 at 01:10:31PM -0500, Rob Herring wrote: > On 09/03/2012 04:44 AM, Robie Basak wrote: > > I got to "highbank" because we need to distinguish the kernels and > > "highbank", "armadaxp" etc. are the existing Ubuntu kernel flavour names. > > That's a very short sighted view.
No, it's not a view at all. I just explained how I reached this suggestion. Also, note that I am NOT assuming a one-to-one mapping between kernel flavours and <subarch> (whatever subarch might mean). I explicitly define is as a separate namespace which will need to have a known mapping in Ubuntu to determine the kernel to use. > In 3.7, we will likely multi-platform > kernels starting with Versatile Express, Highbank and mvebu (Armada XP). > Perhaps OMAP will happen too. Assuming you wanted to support all these > platforms from a single kernel build, how would you manage it? With multiple default.arm-<whatever> names mapping to single Ubuntu kernel flavours as necessary. What am I missing? > Perhaps you always keep separate platforms and just symlink things back > to a common kernel? You could also argue that the command line options > will always be different, so we'll always need to have per platform > directories. Sure - we could do that. I don't think it'll matter too much how we do it provided that we can. > We could make the directory list be an environment variable to iterate > thru then it's not fixed in the bootloader. We'd still need to come up > with defaults though. This sounds good to me. One additional point that's just come up - we'd also like to know the MAC address, which at the point of serving a default.<something> file we won't statelessly know if the TFTP server is not in the same ethernet segment. How about also hitting something like pxelinux.cfg/01-<mac>.arm-<somthing> before pxelinux.cfg/01-<mac> first, and then the default fallback behaviour later? This would make my life a bit easier by not having to save state in between calls to know the MAC address at the time of serving the default file. Robie _______________________________________________ cross-distro mailing list [email protected] http://lists.linaro.org/mailman/listinfo/cross-distro
