At 22:43 27/06/2001, Alexander Viro wrote:
>On Wed, 27 Jun 2001, Linus Torvalds wrote:
> > and then when ext2 calls down to the generic VFS layer it just passes
> >
> > &ext2_inode->inode
> >
> > down, and when it gets a "struct inode *" it uses "inode_to_ext2()" to
> > convert it to an ext2 inode pointer.
> >
> > This is what the "struct list_head" thing does, and it works remarkably
> > well. It allows for embedding a list (or a hundred) into any object. The
> > above would take the same approach, and allow embedding an inode (and
> > maybe several) into any object.
> >
> > Advantages: no extra memory use, no indirection, no memory allocation
> > overhead.
> >
> > Disadvantages: ??
>
>We get inode initilization (generic parts) spread all over the place and
>sooner or later it's going to bite us, for one thing.
>
>Basically, we have the logics that controls allocation/freeing of these
>beasts in VFS, but allocate/free them in filesystems. Such things tend to
>backfire.
If this is the only problem, we could always have this done in VFS instead
of the filesystems. This could be done in many ways but to give a concrete
example: extend existing register_filesystem() function by an "inode_size"
parameter (or push it into DECLARE_FSTYPE() and hence make it part of the
file_system_type struct. VFS can then create a slab cache and use the file
system type to determine which cache to operate on. But then again this
probably becomes more complicated than what we started with... Or another
example, extend get_empty_inode() to accept the size (or slab cache) of the
inode required or something...
Just a thought...
Anton
--
"Nothing succeeds like success." - Alexandre Dumas
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
