Hi Wolfgang, Luigi, On Fri, Mar 28, 2008 at 11:33:58PM +0100, Wolfgang Denk wrote:
> Either the license is compatible, and the code can be included, or it > is not, then it cannot. In the latter case, the whole patch makes no > sense. Given my expertise with license compliance, I volunteer to look into the legal issues, to the point that if I have any doubt I will consult with my legal counsel on that subject. > > LMZA performs better than LZ on binary files. I will switch to > > LZMA to save flash memory space on my appliance. Of course, the > > LZMA is slower than LZ. > > But so far there is no code (board support) in U-Boot to use this > feature, right? And it's not used by the Linux kernel either? As for board support / LZMA: I don't know. But I'm pretty sure that I've seen LZMA compressed u-boot images before. LZMA is really popular with cheap consumer-grade embedded linux equipment, particularly DSL CPE and Wifi Routers. Most of them don't use u-boot, but only use it for the kernel image and the flash filesystem. They're using quite simple out-of-tree patches for that, though. I think this has come up on lkml before, and Linus didn't like it very much. Probably related to the fact that many core kernel hackers look at embedded as sort of a special case, when in reality I am quite sure that the total quantity of embedded systems running Linux is significantly larger than the number of Linux servers + desktops together... > And your patch does not even enable support for it in the mkimage > tool, so you cannot even create images that use the feature? That has obviously to be fixed. > How exactly is this code supposed to be used? some documentation would certainly be fine, yes. > > Anyway, if the LZMA SDK license is compatible with U-boot , I > > think that LZMA should be chosen by firmware developer when the > > flash memory space is a critical resource. > > Frankly, if you are so short with flash you have a h/w dsign problem. Yes and no. I tend to agree, but I also realize that there are economic incentives to keep the bom cost as low as possible, especially in large-quantity consumer equipment... You can just as well claim: If you're using suboptimal compression and wasting flash space, you have a software design problem ;) I think it makes a lot of sense to add LZMA support to u-boot, but obviously in a clean, consistent, documented way. It doesn't hurt, will not be compiled unless explicitly selected, and the API is zlib like, i.e. the code changes it requires are non-intrusive. Just my thoughs... -- - Harald Welte <[EMAIL PROTECTED]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
signature.asc
Description: Digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
