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
pgpCLHSCz2wEB.pgp
Description: PGP signature
