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.
> 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.
> 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.
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html