Message-ID: <423F496C.10004@twisted-brains.org>
Date: Mon, 21 Mar 2005 23:23:40 +0100
From: Mws <mws@twisted-brains.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Pavel Machek <pavel@suse.cz>
CC: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][2/2] SquashFS
References: <20050314170653.1ed105eb.akpm@osdl.org> <423727BD.7080200@grupopie.com> <20050321101441.GA23456@elf.ucw.cz> <200503211908.46602.mws@twisted-brains.org> <20050321185418.GC1390@elf.ucw.cz>
In-Reply-To: <20050321185418.GC1390@elf.ucw.cz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2002
Lines: 60

Pavel Machek wrote:

>Hi!
>
>  
>
>>>>>Also, this filesystem seems to do the same thing as cramfs.  We'd need to
>>>>>understand in some detail what advantages squashfs has over cramfs to
>>>>>justify merging it.  Again, that is something which is appropriate to the
>>>>>changelog for patch 1/1.
>>>>>          
>>>>>
>>>>Well, probably Phillip can answer this better than me, but the main 
>>>>differences that affect end users (and that is why we are using SquashFS 
>>>>right now) are:
>>>>                          CRAMFS          SquashFS
>>>>
>>>>Max File Size               16Mb               4Gb
>>>>Max Filesystem Size        256Mb              4Gb?
>>>>        
>>>>
>>>So we are replacing severely-limited cramfs with also-limited
>>>squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for
>>>sure, and 4Gb file size limit will hurt, too. Can those be fixed?
>>>      
>>>
>
>...
>  
>
>>but if there is a contribution from the outside - it is not taken "as is" and maybe fixed up, which
>>should be nearly possible in the same time like analysing and commenting the code - it ends up
>>in having less supported hardware. 
>>
>>imho if a hardware company does indeed provide us with opensource drivers, we should take these
>>things as a gift, not as a "not coding guide a'like" intrusion which
>>has to be defeated.
>>    
>>
>
>Remember that horse in Troja? It was a gift, too.
>									Pavel
>
>  
>
of course there had been a horse in troja., but thinking like that 
nowadays is a bit incorrect - don't you agree?

code is reviewed normally - thats what i told before and i stated as 
good feature - but there is no serious reason
to blame every code to have potential "trojan horses" inside and to 
reject it.

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