[lkml]   [2002]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [CFT] [JANITORIAL] Unbork fs.h
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?
>>>-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.
It is trust on that. Only the silly GNU indentation style introduced
something else. Look at the "core kernel" and
not the ugly drivers around it.

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

 \ /
  Last update: 2005-03-22 13:18    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean