Dear Wolfgang, On Wed, Jan 11, 2012 at 12:11 AM, Wolfgang Denk <w...@denx.de> wrote: > I have to admit that I have no clear opinion here yet. > > The existing code is from a time when all architectures had a pretty > low limit on the command line size - IIRC even PPC had only 256 bytes > by then, hard coded. > > I think we have two options: > > 1) Try not to exceed any limits imposed by the Linux kernel. > Advantage: we can catch situations where the user overflows the > limits and print an error message (IIRC this needs to be > added), so the user gets aware of the pronlem. > Disadvantage: we need to add architecture specific definitions for > the command line size, and keep these in sync with any > related changes to the Linux kernel. We know in advance > that this will not work really well. > > 2) We just make sure not to overwrite array bounds in U-Boot, and > allow passing arbitrary sized buffers to the Linux kernel. > Advantage: the code in U-Boot can be simple and clean > Disadvantage: the resulting behaviour is not exactly user-friendly, > as a silent truncation in the Linux kernel is probably hard > to spot. > > Hm... > > I agree that the old code needs fixing. I think it would be nice if > we could adapt U-Boot behaviour, but I fear that actually it cannot > work at all, as we don't know which Linux kernel version the user will > use, and what their limits might be. > > So in the end 2) is probably the most sensible approach here.
Thank you for all of your time on this issue. I have just sent a patch implementing 2) with as little extra cruft as possible (I hope). Let me know if there is anything else you need here. Thanks! -Doug _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot