Re: [CFT] [JANITORIAL] Unbork fs.h

From: Daniel Phillips (
Date: Thu Jan 03 2002 - 11:34:27 EST

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?

> > -static inline struct inode * new_inode(struct super_block *sb)
> > +static inline struct inode *new_inode (struct super_block *sb)
> Minor issue of coding style. I'd steer away from such gratuitious changes,
> especially since they divert from the commonly accepted practice of having
> no spaces between the name of the function and its arguments.

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).

In general, I allow myself the indulgence of cleaning up the odd line here
and there to be more pleasing to my eyes, so long as it's in the vicinity of
a substantive change and doesn't introduce a new patch hunk. You could think
of it as a perk that takes some of the sting out of doing the grunt work.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jan 07 2002 - 21:00:21 EST