On Thu, 3 Jan 2002, Daniel Phillips wrote:
> On January 3, 2002 05:05 pm, Ion Badulescu wrote:
> > Daniel Phillips wrote:
> >
> > > +static struct file_system_type ext2_fs = {
> > > + owner: THIS_MODULE,
> > > + fs_flags: FS_REQUIRES_DEV,
> > > + name: "ext2",
> > > + read_super: ext2_read_super,
> > > + super_size: sizeof(struct ext2_sb_info),
> > > + inode_size: sizeof(struct ext2_inode_info)
> > > +};
> >
> > While we're at it, can we extend this model to also include details about
> > the other filesystem data structures with (potential) private info, i.e.
> > struct dentry and struct file? ext2 might not use them, but other
> > filesystems certainly do.
>
> Could you be more specific about what you mean, please?
If we're going to have specific slabs for each specific filesystem's inode
and superblock structures, why shouldn't we do the same with the struct
file and struct dentry? Right now, if a filesystem needs to stick some
information in there, it has to allocate and then dereference
file->private_data and dentry->d_fsdata, and I thought this cleanup was
trying to avoid that, right?
Something like this, added to the end of the filesystem declaration:
+ dentry_size: sizeof(struct ext2_dentry_info),
+ file_size: sizeof(struct ext2_file_info)
Obviously the above is only an example, since ext2 doesn't have those
structures -- so it would simply use 0 instead.
>From the filesystems in the tree, only intermezzo actually allocates
them, so it's not as pressing a matter as it was for inodes. A few others
(ab)use the private pointer to store an integer value, without actually
allocating a private structure.
Stackable filesystems, on the other hand, make extensive use of all these
private data pointers to store the links to the stacking level immediately
underneath. Alas, they're not in the tree... :-)
> That's good advice and I'm likely to adhere to it - if you can show that
> having no spaces between the name of the function and its arguments really is
> the accepted practice. I've seen both styles on my various travels though
> the kernel, and I prefer the one with the space. Much as I prefer to put
> spaces around '+' (but not around '.', go figure).
Well... I said "minor point" and it degenerated into a full-fledged
thread, while nobody actually cared much about the real code... :-)
I know the issue has been hashed to death already, but basically the
common practice I was referring to is to *have* a space after a C keyword
(for, while, return), but *not* after a function name.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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:22 EST