I will be submitting a new filesystem for inclusion into the kernel as
soon as it is ready. (It mounts but doesn't like doing much else
right now.) I would like to get feedback now to mold the development
as we go along. Please comment on the technical approaches and other
inherent qualities or lack thereof. Let me know of any serious
obstacles to inclusion in the mainline. We will Lindent it and clean
it up quite a bit before really submitting.
You may find it at its very boring sourceforge site
https://sourceforge.net/projects/axfs/. Browse the source at
http://svn.sourceforge.net/axfs
Or get the tarball at
http://prdownloads.sourceforge.net/axfs/axfs-0.1.tar.gz?download
What is it?:
- AXFS for Advanced XIP File System.
- Intended to be a root filesystem for embedded systems
- Readonly
- Uses addressable memory such as NOR flash instead of a block device
- Borrows much from CRAMFS with Linear XIP patches
- Allows XIP* of individual pages instead of just individual files
- Uses filemap_xip.c where possible
* By XIP, eXecute In Place, we mean that when a file is mmap'd() the
pages are mapped directly to where they are stored in non volatile
storage, rather than copied to RAM in the page cache and mapped from
there
Why a new filesystem?
- XIP of kernel is mainline, but not XIP of applications. This
enables application XIP
- Cramfs linear XIP patches not suitable for submission and lack some
features of AXFS
- Design allows for tighter packing of data and higher performance
than XIP cramfs
(Warning - Long explaination of why XIP support is important follows.
Please read before flaming XIP.)
I've heard people say, "XIP is stupid. Why on earth would I use
expensive slow flash instead of cheap fast RAM?" Let me try explain
why it can be smart and why it is actually done in practice. In fact
many of the mobile handsets that run Linux use XIP CRAMFS today. If I
take libfoo.so which is about 2MiB and throw it in JFFS2, it
compresses to about 1MiB in flash. If I store libfoo.so as an XIP
file (uncompressed) in XIP CRAMFS or AXFS it takes up 2MiB of flash.
That is 1MiB extra flash for XIP. But the JFFS2 version would need
2MiB of RAM to store that library when used while the XIP system uses
0MiB. That means XIP uses +1MiB of flash and -2MiB of RAM for
libfoo.so. So for any extra flash used for XIP, it can save twice
that amount of RAM. The end result can be lower cost systems on the
small end. The secret is to choose what to make XIP and what to
compress on flash.
XIP can also increase performance. Processor caches make the slower
read speed, compared to RAM, of a NOR type flash often used for XIP
not important. However when an application 'bar' gets started and the
code is mmap()'ed into the process the XIP system creates page table
entries pointing to a physical address for all the code the process
needs. Without XIP, as I understand it, basically empty page tables
are created. As code is executed the system page faults and code is
fetched from the filesystem, for example JFFS2, in a rather long
process of copying to RAM, decompressing, and transfering to
userspace. And of course this happens, interrupting execution of
'bar', every time you access a new page of code. To misquote Linus
"bow down before me, you scum" Torvalds, "That cost is _bigger_ than
the cost of just copying the page in the first place." Code that is
XIP takes that a step farther, it _never_ faults and _never_ gets
copied.
To revisit the libfoo.so story lets say that the often used
application 'bar' only calls one function in libfoo and therefore only
pages in 1MiB of libfoo into RAM. Does this break the XIP argument?
(+1MB Flash for -1MB RAM) Not with AXFS! A system designer could
then choose to only XIP the specific pages within libfoo.so that are
actually accessed. In that way the 2:1 ratio is retained. The AXFS
effort will include some tools to help identify which pages do what,
to help system designers optimize thier systems for memory usage.
Am Tuesday 02 May 2006 23:53 schrieb Jared Hulbert:
> I will be submitting a new filesystem for inclusion into the kernel as
> soon as it is ready. ?(It mounts but doesn't like doing much else
> right now.) ?I would like to get feedback now to mold the development
> as we go along. ?Please comment on the technical approaches and other
> inherent qualities or lack thereof. ?Let me know of any serious
> obstacles to inclusion in the mainline. ?We will Lindent it and clean
> it up quite a bit before really submitting.
>
> You may find it at its very boring sourceforge site
> https://sourceforge.net/projects/axfs/. ?Browse the source at
> http://svn.sourceforge.net/axfs
> Or get the tarball at
> http://prdownloads.sourceforge.net/axfs/axfs-0.1.tar.gz?download
>
>
> What is it?:
> - AXFS for Advanced XIP File System.
> - Intended to be a root filesystem for embedded systems
> - Readonly
> - Uses addressable memory such as NOR flash instead of a block device
> - Borrows much from CRAMFS with Linear XIP patches
> - Allows XIP* of individual pages instead of just individual files
> - Uses filemap_xip.c where possible
>
> * By XIP, eXecute In Place, we mean that when a file is mmap'd() the
> pages are mapped directly to where they are stored in non volatile
> storage, rather than copied to RAM in the page cache and mapped from
> there
Nice, this is the first time I heard of anyone using filemap_xip on MTD.
> Why a new filesystem?
> - XIP of kernel is mainline, but not XIP of applications. ?This
> enables application XIP
ext2fs does have XIP of applications, but of course only works on
block devices, not MTD. Is there more missing than an implementation
of block_device_operations::direct_access for mtd_blktrans_ops?
Why can't you get the same result with a combination of cramfs for
data files and ext2 with -o xip for your mmapped binaries?
> - Cramfs linear XIP patches not suitable for submission and lack some
> features of AXFS
Is that a fundamental problem of cramfs, or rather a problem of the
implementation of the linear XIP patches for it? IOW, can't you just
do a better patch to add filemap_xip support to cramfs?
> - Design allows for tighter packing of data and higher performance
> than XIP cramfs
why? by how much?
Arnd <><
On 5/2/06, Jared Hulbert <[email protected]> wrote
>
> Why a new filesystem?
> - XIP of kernel is mainline, but not XIP of applications. This
> enables application XIP
>From what I recall, XIP of the kernel off of MTD is limited to ARM. I
assume AXFS suffers the same restriction?
josh
> Nice, this is the first time I heard of anyone using filemap_xip on MTD.
Actually we don't use the MTD. Well, we may use it to provide the
physical address of the volume, thats not really _using_ it.
> ext2fs does have XIP of applications, but of course only works on
> block devices, not MTD. Is there more missing than an implementation
> of block_device_operations::direct_access for mtd_blktrans_ops?
It works on very specific block devices to be clear. Yeah, as I
understand it, the hardware to enable it is missing.
> Why can't you get the same result with a combination of cramfs for
> data files and ext2 with -o xip for your mmapped binaries?
Not having the block device driver is by design. In this case I don't
need a block device because the entire "disk" or binary image is in
readonly memory already. I don't need to fetch blocks. This is
readonly so I don't need to write blocks either. A block device
driver would do what for me?
Also ext2 doesn't do compression, and it doesn't let me pick out
specific pages in files to XIP or compress.
> Is that a fundamental problem of cramfs, or rather a problem of the
> implementation of the linear XIP patches for it?
A little of both. The architecture of cramfs doesn't lend itself to
the page by page XIP without really changing the fundamental layout of
cramfs. Why mess with it?
>IOW, can't you just
> do a better patch to add filemap_xip support to cramfs?
I started out with that goal. This seemed like the best option after
we did the deep dive into how to go about it.
>> - Design allows for tighter packing of data and higher performance
>> than XIP cramfs
>
> why? by how much?
Data packing:
1) When mkcramfs is writing files to the image it mixes compress and
XIP files. XIP files are page aligned. Compressed files are not. I
think it was about 3.3% wasted I measured on an actual production
linux phone.
2) Choosing page by page to XIP or compress means you can save space,
but it depends on what is more precious, RAM or Flash, given real
designs (ie - you don't buy 36MiB of RAM you get 32MiB or 64MiB)
Performance:
1) The way we are storing the metadata should make for quicker access.
2) Being able to store specific pages of RO data from an otherwise XIP
file such that they end up in RAM has speed thing up for us a great
deal in the lab.
On 5/2/06, Jared Hulbert <[email protected]> wrote:
> > Nice, this is the first time I heard of anyone using filemap_xip on MTD.
>
> Actually we don't use the MTD. Well, we may use it to provide the
> physical address of the volume, thats not really _using_ it.
Can you explain a bit more? If you aren't going to use the MTD, why
rely on it at all?
> >> - Design allows for tighter packing of data and higher performance
> >> than XIP cramfs
> >
> > why? by how much?
>
> Data packing:
> 1) When mkcramfs is writing files to the image it mixes compress and
> XIP files. XIP files are page aligned. Compressed files are not. I
> think it was about 3.3% wasted I measured on an actual production
> linux phone.
> 2) Choosing page by page to XIP or compress means you can save space,
> but it depends on what is more precious, RAM or Flash, given real
> designs (ie - you don't buy 36MiB of RAM you get 32MiB or 64MiB)
>
> Performance:
> 1) The way we are storing the metadata should make for quicker access.
> 2) Being able to store specific pages of RO data from an otherwise XIP
> file such that they end up in RAM has speed thing up for us a great
> deal in the lab.
Have you done comparisons vs. squashfs at all? It does better at both
performance and compression that cramfs, so I'm curious.
josh
On Tue, 2 May 2006, Josh Boyer wrote:
> On 5/2/06, Jared Hulbert <[email protected]> wrote
> >
> > Why a new filesystem?
> > - XIP of kernel is mainline, but not XIP of applications. This
> > enables application XIP
>
> From what I recall, XIP of the kernel off of MTD is limited to ARM.
It doesn't have to.
Nicolas
> Can you explain a bit more? If you aren't going to use the MTD, why
> rely on it at all?
I plan to could do 'mount -t axfs /dev/mtdblock2 /mnt/axfs' and use
the mtd to get the address to flash from map->cached or maybe
mtd->point. Personally I think this is a clean approach to mounting
this fs. Right now we do it like linear cramfs 'mount -t cramfs -o
physaddr=0xDEADBEEF /dev/null /mnt/axfs' and then map flash ourselves
with ioremap(). I'd like to enable a mode like this to in case you
don't have MTD. But I prefer the former.
> Have you done comparisons vs. squashfs at all? It does better at both
> performance and compression that cramfs, so I'm curious.
Haven't done any performance testing on squashfs. I did see some
compression analysis that basically showed that squashfs did compress
better but paid for that flash saving in extra RAM.
Accidentally replied just to Josh, sorry. Included what was offline.
>>> From what I recall, XIP of the kernel off of MTD is limited to ARM. I
>>> assume AXFS suffers the same restriction?
>>
>> I'm fairly certian it won't. I don't see anything in the code (that
>> we aren't going to remove) that would cause that. All it needs is
>> direct memory access to the volume. I'll find out soon, I'm trying to
>> test it on a X86 UML system.
>>
>> The XIP awareness in the MTD isn't a requirement for XIP, it's a
>> requirement to XIP from flash you are going to write, erase or
>> otherwise mess with.
>
>So you're relying on the fact that the underlying flash chip won't
>change from the Read Array state? What happens if someone tries to
>use AXFS on an MTD partition, which can cover only a portion of a
>chip. That is a fairly common occurance for read-only root
>filesystems. Other partitions (say JFFS2) on that chip will cause the
>chip state to change...
Right. So that is exactly the case XIP Awareness is in the MTD to
fix, and it does so such that AXFS doesn't have to worry about it.
On Tue, 2006-05-02 at 22:04 -0700, Jared Hulbert wrote:
> I plan to could do 'mount -t axfs /dev/mtdblock2 /mnt/axfs' and use
> the mtd to get the address to flash from map->cached or maybe
> mtd->point. Personally I think this is a clean approach to mounting
> this fs. Right now we do it like linear cramfs 'mount -t cramfs -o
> physaddr=0xDEADBEEF /dev/null /mnt/axfs' and then map flash ourselves
> with ioremap(). I'd like to enable a mode like this to in case you
> don't have MTD. But I prefer the former.
It makes sense. If you're going to use MTD drivers for other partitions
of the flash, you want to be able to co-ordinate with it so you know
when the flash is being written to. You want to be able to use its
partitioning rather than hard-coding the physical address and length of
what might be a dynamic partition. You want the MTD driver to know that
the device in question is in use.
--
dwmw2
On 5/2/06, Nicolas Pitre <[email protected]> wrote:
> On Tue, 2 May 2006, Josh Boyer wrote:
>
> > On 5/2/06, Jared Hulbert <[email protected]> wrote
> > >
> > > Why a new filesystem?
> > > - XIP of kernel is mainline, but not XIP of applications. This
> > > enables application XIP
> >
> > From what I recall, XIP of the kernel off of MTD is limited to ARM.
>
> It doesn't have to.
Yes, I realize that all that is needed is support from other archs. A
more general form of the question would be does AXFS depend on
ARCH_MTD_XIP?
josh
On Wed, 2006-05-03 at 05:41 -0500, Josh Boyer wrote:
> Yes, I realize that all that is needed is support from other archs. A
> more general form of the question would be does AXFS depend on
> ARCH_MTD_XIP?
That's for kernel XIP, which needs special magic for putting certain
functions into RAM instead of the flash, polling for interrupts, etc.
For general _userspace_ XIP we don't necessarily need to do that. We
only need to mark those pages as absent in the page tables if we ever
schedule to userspace while the flash is in a mode other than read mode.
Then handle the page fault by switching the flash back or waiting for
it.
--
dwmw2
This is excellent (in description, at least).
I have several embedded-systems clients crying out for this kind of support,
and for exactly the same (low-cost) reasons.
Is this stable enough for production use now?
Thanks
On Tue, 2 May 2006 14:53:06 -0700, Jared Hulbert wrote:
>
> I will be submitting a new filesystem for inclusion into the kernel as
> soon as it is ready. (It mounts but doesn't like doing much else
> right now.) I would like to get feedback now to mold the development
> as we go along. Please comment on the technical approaches and other
> inherent qualities or lack thereof.
o Document the on-medium format
o Lindent
o Remove whitespace damage
o Consider saving a zlib workspace by moving it out of your code and
sharing the infrastructure with cramfs and jffs2
J?rn
--
"[One] doesn't need to know [...] how to cause a headache in order
to take an aspirin."
-- Scott Culp, Manager of the Microsoft Security Response Center, 2001
> o Document the on-medium format
Right. Working on that.
> o Consider saving a zlib workspace by moving it out of your code and
> sharing the infrastructure with cramfs and jffs2
Hmmm. Can you explain what you mean by this. That would require
modifying each of the 3 filesystems.
> Is this stable enough for production use now?
No. It barely mounts. I do think it should prove fairly stable
quickly but it will be a while before I'd use it for production.
>We
> only need to mark those pages as absent in the page tables if we ever
> schedule to userspace while the flash is in a mode other than read mode.
> Then handle the page fault by switching the flash back or waiting for
> it.
Where would we do this? In each MTD driver? A new generic aops function?
On Wed, 3 May 2006 08:31:50 -0700, Jared Hulbert wrote:
>
> >o Consider saving a zlib workspace by moving it out of your code and
> > sharing the infrastructure with cramfs and jffs2
>
> Hmmm. Can you explain what you mean by this. That would require
> modifying each of the 3 filesystems.
Correct. It is not a must-fix, but having seperate workspaces for all
the filesystems seems wasteful.
J?rn
--
Unless something dramatically changes, by 2015 we'll be largely
wondering what all the fuss surrounding Linux was really about.
-- Rob Enderle
On Wed, 2006-05-03 at 08:45 -0700, Jared Hulbert wrote:
> > We only need to mark those pages as absent in the page tables if we ever
> > schedule to userspace while the flash is in a mode other than read mode.
> > Then handle the page fault by switching the flash back or waiting for
> > it.
>
> Where would we do this? In each MTD driver? A new generic aops function?
Probably a helper function with callbacks into the MTD driver. You ask
the MTD device driver to map a certain range of itself to userspace, and
it does so. Then it handles the page faults, etc.
--
dwmw2
On Wed, 3 May 2006, Jared Hulbert wrote:
> > We
> > only need to mark those pages as absent in the page tables if we ever
> > schedule to userspace while the flash is in a mode other than read mode.
> > Then handle the page fault by switching the flash back or waiting for
> > it.
>
> Where would we do this? In each MTD driver? A new generic aops function?
First, is it worth it?
IOW, are there real setups out there wishing to have user space XIP
while the kernel itself isn't XIP?
Because right now you only need to turn on CONFIG_MTD_XIP for XIP user
space to just work, regardless of whether the kernel itself is XIP or
not. And of course CONFIG_MTD_XIP is mandatory if you want to write to
flash with a XIP kernel.
Nicolas
> Correct. It is not a must-fix, but having seperate workspaces for all
> the filesystems seems wasteful.
Agreed. So we copy the cramfs uncompress routines line for line.
That optimization seems like low hanging fruit.
To consolidate them how should that be approached? Create
fs/uncompress.c? Modify axfs and cramfs to use it?
On Wed, 2006-05-03 at 11:57 -0400, Nicolas Pitre wrote:
> First, is it worth it?
Quite possibly not. Even if you don't actually have kernel XIP, you may
well decide just not to schedule userspace while the flash isn't in READ
mode. Tearing down PTEs is painful.
--
dwmw2
On Wed, 3 May 2006, David Woodhouse wrote:
> On Wed, 2006-05-03 at 11:57 -0400, Nicolas Pitre wrote:
> > First, is it worth it?
>
> Quite possibly not. Even if you don't actually have kernel XIP, you may
> well decide just not to schedule userspace while the flash isn't in READ
> mode.
And we already have code to do just that.
Nicolas
> What is it?:
> - Borrows much from CRAMFS with Linear XIP patches
Apropos borrowing: borrow the compression from Squashfs.
> I've heard people say, "XIP is stupid. Why on earth would I use
> expensive slow flash instead of cheap fast RAM?"
> [...] If I
> take libfoo.so which is about 2MiB and throw it in JFFS2, it
> compresses to about 1MiB in flash. If I store libfoo.so as an XIP
> file (uncompressed) in XIP CRAMFS or AXFS it takes up 2MiB of flash. That is
> 1MiB extra flash for XIP. But the JFFS2 version would need
> 2MiB of RAM to store that library when used while the XIP system uses
> 0MiB. That means XIP uses +1MiB of flash and -2MiB of RAM for
> libfoo.so. So for any extra flash used for XIP, it can save twice
> that amount of RAM. The end result can be lower cost systems on the
> small end. The secret is to choose what to make XIP and what to
> compress on flash.
If 2 MB of RAM are cheaper [as you say] than 1 MB of Flash, where's the
advantage when XIP uses more flash?
Jan Engelhardt
--
On Wed, 3 May 2006 08:58:36 -0700, Jared Hulbert wrote:
>
> Agreed. So we copy the cramfs uncompress routines line for line.
> That optimization seems like low hanging fruit.
>
> To consolidate them how should that be approached? Create
> fs/uncompress.c? Modify axfs and cramfs to use it?
And jffs2, yes. And possibly lib/ is better than fs/.
J?rn
--
You ain't got no problem, Jules. I'm on the motherfucker. Go back in
there, chill them niggers out and wait for the Wolf, who should be
coming directly.
-- Marsellus Wallace
> Apropos borrowing: borrow the compression from Squashfs.
We borrow much more than the compression from cramfs. We plan to
borrow some ideas about compression from squashfs.
> > I've heard people say, "XIP is stupid. Why on earth would I use
> > expensive slow flash instead of cheap fast RAM?"
> > [...] If I
> > take libfoo.so which is about 2MiB and throw it in JFFS2, it
> > compresses to about 1MiB in flash. If I store libfoo.so as an XIP
> > file (uncompressed) in XIP CRAMFS or AXFS it takes up 2MiB of flash. That is
> > 1MiB extra flash for XIP. But the JFFS2 version would need
> > 2MiB of RAM to store that library when used while the XIP system uses
> > 0MiB. That means XIP uses +1MiB of flash and -2MiB of RAM for
> > libfoo.so. So for any extra flash used for XIP, it can save twice
> > that amount of RAM. The end result can be lower cost systems on the
> > small end. The secret is to choose what to make XIP and what to
> > compress on flash.
>
> If 2 MB of RAM are cheaper [as you say] than 1 MB of Flash, where's the
> advantage when XIP uses more flash?
I didn't mean to suggest I thought 2MB of RAM is cheaper 1MB. People
say that, yes. I say that is false. Mwave.com will sell you several
1GB SD card flash at <$40 while 1GB of DDR2 will cost >$100. That's
actually a strawman argument, just to demonstrate what is possible ;)
The economics are different at the embedded side, the RAM isn't the
same as what is used in PCs and neither is the Flash. Also the prices
are mostly laid out in contracts between large companies and are not
public. I don't really want to get into a discussion of Flash pricing
and economics, I don't think it appropriate for this forum. Please
lets leave it at some people have done this, are doing it, and want to
do it in the future (see Mark Lords comment earlier). It gets
complicated. Some systems it makes sense for, some it doesn't.
We took Familiar Linux 0.8.3 Opie verision and built two versions, one
that used jffs2 on NAND and another that used XIP cramfs on NOR. We
optimized the XIP cramfs to only uncompress commonly used libraries
and binaries. The XIP build used 8MiB more flash. It saved about
20MiB of RAM and was 3X faster at bootup. (Summary support on jffs2
closed the gap to 2X boot up but made the jffs2 use _more_ flash than
the XIP). The jffs2 version volume wouldn't run the PIM apps and the
browser and Quake at the same time with only 32MiB of RAM. The XIP
version would. The jffs2 version used 42MiB and the XIP 50MiB.
Rounding to rational chip sizes that's 32MiB RAM/64MiB Flash versus
64MiB RAM/64MiB Flash.
The point of axfs is to reduce that 8MiB to the absolute minimum. In
general application XIP give the system designer the to flexible trade
Flash for RAM and RAM for Flash to squeeze the system into the optimal
cheapest it can be. AXFS will give more flexiblity with a mainstream
solution.
> And jffs2, yes.
jffs2 with it's new pluggable compression seems like a lot of work.
> And possibly lib/ is better than fs/.
right.
On Wed, 2006-05-03 at 18:38 +0200, Jan Engelhardt wrote:
> If 2 MB of RAM are cheaper [as you say] than 1 MB of Flash, where's
> the advantage when XIP uses more flash?
Power consumption.
--
dwmw2
On 5/3/06, Jared Hulbert <[email protected]> wrote:
>
> We took Familiar Linux 0.8.3 Opie verision and built two versions, one
> that used jffs2 on NAND and another that used XIP cramfs on NOR. We
Erm, why was one built on NAND and one on NOR? You're comparing
apples to oranges now.
You're also comparing different price points. Depending on various
factors, NAND flash can be 3x cheaper than NOR. But I agree that
economics should be left out of this discussion. There are people
that want to use XIP, and economics has nothing to do with the
technology that enables that to happen.
> optimized the XIP cramfs to only uncompress commonly used libraries
> and binaries. The XIP build used 8MiB more flash. It saved about
> 20MiB of RAM and was 3X faster at bootup. (Summary support on jffs2
> closed the gap to 2X boot up but made the jffs2 use _more_ flash than
> the XIP). The jffs2 version volume wouldn't run the PIM apps and the
If the NAND device was a small block device, summary support won't
really help at all there.
> browser and Quake at the same time with only 32MiB of RAM. The XIP
> version would. The jffs2 version used 42MiB and the XIP 50MiB.
> Rounding to rational chip sizes that's 32MiB RAM/64MiB Flash versus
> 64MiB RAM/64MiB Flash.
JFFS2 does incur a bit of DRAM overhead. There are a couple things
kicking around that might help that consumption, but not in the
magnitude you're mentioning here.
josh
> Erm, why was one built on NAND and one on NOR? You're comparing
> apples to oranges now.
The assumption I'm making is that if you don't use XIP that NAND
becomes an economically attractive and technically feasible option to
store the code. The idea was to dive into the tradeoffs of the
options. It reflects what I believe is the reality of what design
decisions are being looked at by customers of my current employer.
Comparing apples and oranges is appropriate when one is investigating
spherical fruits :)
On 5/3/06, Jared Hulbert <[email protected]> wrote:
> > Erm, why was one built on NAND and one on NOR? You're comparing
> > apples to oranges now.
>
> The assumption I'm making is that if you don't use XIP that NAND
> becomes an economically attractive and technically feasible option to
> store the code. The idea was to dive into the tradeoffs of the
> options. It reflects what I believe is the reality of what design
> decisions are being looked at by customers of my current employer.
>
> Comparing apples and oranges is appropriate when one is investigating
> spherical fruits :)
Heh, ok. That makes sense if you're investigating the economic options.
josh
Hi!
> Also ext2 doesn't do compression, and it doesn't let me
> pick out
> specific pages in files to XIP or compress.
Patches for compressed ext2 exist; and it has many other nice uses,
too...
> >why? by how much?
>
> Data packing:
> 1) When mkcramfs is writing files to the image it mixes
> compress and
> XIP files. XIP files are page aligned. Compressed
> files are not. I
> think it was about 3.3% wasted I measured on an actual
> production
> linux phone.
Which one, btw? I guess I need a new phone :-)
--
Thanks, Sharp!
> Patches for compressed ext2 exist; and it has many other nice uses,
> too...
True.
> Which one, btw? I guess I need a new phone :-)
I can't disclose that. There are several Linux phones availiable,
mostly in Asia though. I have actually seen some of the GSM Linux
phones in use in the US. I suppose they ought to work in Europe.
Some are very nice. I would suggest for a kernel hacker to make sure
you get one that you can telnet into or get terminal app on. There is
something disappointing about a Linux machine of any kind without a
proper shell. :)