Re: [PATCH][2/2] SquashFS

[Mws <mws@twisted-brains.org>]

[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]

hi everybody, hi pavel

>On Monday 21 March 2005 11:14, you 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?
> 
> 								Pavel
no - squashfs _is_ indeed an advantage for embedded systems in
comparison to cramfs. why does everybody think about huge systems 
with tons of ram, cpu power whatever - there are also small embedded systems
which have real small resources. 

some notes maybe parts are OT - but imho it must be said someday

- reviewing the code is absolutely ok. 
- adding comments helps the coder and also the users to understand 
  _how_ kernel coding is to be meant

- but why can't people just stop to blame every really good thing?

in this case it means:
	of course cramfs and squashfs are to different solutions for saving data
	in embedded environments like set-top-boxes, pda, ect., but there is 
        a need for having inventions as higher compression rates or more data security. 
	
in other cases that means:
       of course there are finished network drivers from Syskonnect/Marvel/Yukon 
       for the GBit network interfaces. 
       Also they were send to the ml. but nearly the same thing happened to them
       reviewing the code, critics, and rejection of their code. 
 
this all ends up in not supported hardware - or - someday supported hardware cause
somebody is in reel need of those features and just publishes the patches online like a 
DIY-Patchset for different kernel versions. 

Hasn't it been the aim of linux to run on different architectures, support lots of filesystems, 
partition types, network adapters, bus-systems whatever? 

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.

ready to take your comments :)

regards
marcel



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]