Re: Understanding version 4 packs

From: Nicolas Pitre <nico@cam.org>
Date: Mar 26, 2007, 18:43 UTC
Message-ID: <alpine.LFD.0.83.0703261417520.3041@xanadu.home>
In-Reply-To: <e5bfff550703261010u67aa1207j1c6f0200bb7744a@mail.gmail.com>

On Mon, 26 Mar 2007, Marco Costalba wrote:

> I fail to see wher's the losing on space saving. More, you probably
> have many paths both under 'drivers' and 'drivers/usb' and for each
> added path it would be possible to avoid to store the prefix ('driver'
> or 'driver/usb').

I'm under the impression you don't understand how tree objects work.

Show 8 quoted lines

> To better clarify, OBJ_DICT_TREE data *currently* looks like:
> 
> +------------+-------+-------+-------+-------+----
> | NR_ENTRIES | name1 | hash1 | name2 | hash2 | ...
> +------------+-------+-------+-------+-------+----
>  vint        2 bytes 4 bytes 2 bytes 4 bytes
> 
> where name1 is an index into the packfile's sole EXTOBJ_FILENAME_TABLE.

Exact.

Show 9 quoted lines

> The possible improve is to define OBJ_DICT_TREE like
> 
> +------------+-------+-------+-------+-------+----
> | NR_ENTRIES | dir1   | fiile1 | hash1| dir 2| fiile2|...
> +------------+-------+-------+-------+-------+----
>  vint        2 bytes 2 bytes 2 bytes 4 bytes
> 
> where dir1 is an index into a new EXTOBJ_DIRNAME_TABLE and file1 is an
> index in a new  EXTOBJ_FILENAME_TABLE.

You definitely don't understand how tree objects are used.

Tree objects have no notion of full path at all. They only contain directory component from a single path level only.

If you have the following files:

	drivers/Kconfig
	drivers/usb/Makefile
	drivers/usb/host/ehci.h
	drivers/usb/host/ehci-pci.c
	drivers/usb/host/ohci-pci.c
	kernel/sched.c

then you'll start with one tree objects for the root directory that contains:

	drivers (tree)
	kernel (tree)

Then a second tree object for the "drivers" directory that contains:

	Kconfig (blob)
	usb (tree)

Then a third tree object for the "usb" directory with:

	Makefile (blob)
	host (tree)

Then the fourth tree object with:

	ehci.h (blob)
	ehci-pci.c (blob)
	ohci-pci.c (blob)

And finally a fifth tree object for the "kernel" directory with:

	sched.c (blob)

Hence, the path component table would contain:

	drivers
	usb
	host
	Kconfig
	Makefile
	ehci.h
	ehci-pci.c
	ohci-pci.c
	sched.c

along with the mode bits for each of those path components, and this is what the new tree object would index into for each tree record.

Show 9 quoted lines

> EXTOBJ_FILENAME_TABLE is defined as the currently (but much smaller in
> size!!) and keeps only the file names, not the full paths, while
> EXTOBJ_DIRNAME_TABLE is defined as EXTOBJ_FILENAME_TABLE but without
> MODE field (associated to files only) and is used to store the dir
> names.
> 
> Decopuling dir names from file names could improve saving space
> because the length of proposed EXTOBJ_FILENAME_TABLE +
> EXTOBJ_DIRNAME_TABLE < current EXTOBJ_FILENAME_TABLE.

I hope the explanation above made it clear that what you're proposing cannot ever be smaller than current EXTOBJ_FILENAME_TABLE.

Nicolas