Re: Xfree86 4.2

[Daniel Wagner <wagi@gmx.ch>]

Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:

> Maybe Daniel wants to summarize what we discussed at the party about what
> needs to be done to get a foot into this issue.

Sir, yes, sir! 

Ok, let's start thing some basic things.  First of all you don't need
to write a complete new ext2 translator.  I'm sure this is something
you're already knew.  The current implementation maps the whole
filesystem into memory but unlike fatfs which has all metadata at the
beginning of the partition the ext2fs has the metadata distributed over
the whole partition.  In the fatfs case you can use bigger partition
than 2 GB because (most) metadata of large partition fits beneath 2
GB.  The rest of the address space can be used with a "simple" buffer
algorithm .  Ext2fs is bit more complicated because metadata and data
can be mixed, e.g. directory entries names are in a normal data block
stored.  So the one possible solution is to have one big buffer
manager which keeps track of block mappings in memory.  For example if
the ext2fs needs to access a certain block, ext2fs would first ask the
buffer manager to map it into memory and expects from the manager the
exact position in memory.  Then ext2fs can read/write the block.  Of
course you have to take care that all address calculation are correct
(relative offsets).  Luckily you can find all these spots where you
have to change the calculation quite easy because all these spots must
be protected from the pager.  So you have to look for
'diskfs_catch_exception()' and 'diskfs_end_catch_exception()' blocks
(there are only a few: 8). And of course any call out of these spots
must also be checked for correct addressing.

So that was the easy part.  The difficult thing is the buffer manager (BM).
There are some interesting problems to solve.  First, the block and
page size problem:

block < page:  Should BM trying to fill pages in order to keep down
               the internal fragmantation?  
block = page:  Easy.
block > page:  So BM has to allocate more than one page and this
               memory block should be contiginius. 

And as you can see the block and page size is not fix.  Next problem
is how BM maps several continuous blocks into memory:

- No (interesting) blocks map so far: BM can freely 
  decide where to map the blocks (no restriction) on demand. 

- (Some continues) blocks are already mapped: There is a request for a
  larger region of blocks.  BM has to expand the mapped region
  (maybe in both direction).  

- Two blocks (or block regions) are already mapped: There is a request
  for a region which includes both blocks.  If these already mapped
  blocks have not alignment properly BM has to rearrange them first, etc.

I have just written down some of the cases, I'm sure there are some
more interesting ones :)  And there are more question like: What happens
if there is no space left for mapping.

I can't remember more right now from what we have discussed, maybe
Marcus wants to add some more.  hehe

cheers,
daniel