Daniel Phillips wrote:
> On January 7, 2002 04:19 pm, Daniel Phillips wrote:
> > - You are dreferencing a pointer, and have two allocations for every
> > inode instead of one.
> Oh no, you only have one allocator, and you have the filesystem do it, with
> per-sb methods. Why is this better than having the VFS do it? Does this
> imply you might have different sized inodes with different mounts of the same
> The per-fs cost with my variant is: 4-8 bytes per filesystem, period. No
> methods needed, and the object management code doesn't get replicated through
> all the filesystems.
Having the VFS allocate objects by passing in object sizes in structs is
ugly to the extreme. So I have similar objections as Al here.
The API change as I have implemented things is more flexible. Having
the fs perform the kmem cache allocation for its inodes is much more
clean than your version IMHO, and one of the big reasons why I did
things this way. If you dislike the size of ext2_alloc_inode some of
that code can probably go into a helper macro/function.
> Also, having the inode point at itself is a little, hmm, 'what's wrong with
> this picture', don't you think?
I am very much interested in a better solution... I could not figure
out how to get a private pointer from a struct inode*, without using a
nasty OFFSET_OF macro or a pointer to self as I implemented.
-- Jeff Garzik | Alternate titles for LOTR: Building 1024 | Fast Times at Uruk-Hai MandrakeSoft | The Took, the Elf, His Daughter and Her Lover | Samwise Gamgee: International Hobbit of Mystery - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:36 EST