From: Martin Dalecki <dalecki@evision-ventures.com>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: Ion Badulescu <ion@cs.columbia.edu>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [CFT] [JANITORIAL] Unbork fs.h
Date: Thu, 03 Jan 2002 17:28:57 +0100 [thread overview]
Message-ID: <3C3486C9.8080007@evision-ventures.com> (raw)
In-Reply-To: <200201031605.g03G57e22947@guppy.limebrokerage.com> <E16MAp4-00018b-00@starship.berlin>
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.
>>
>
>Hi,
>
>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.
next prev parent reply other threads:[~2002-01-03 16:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-03 12:47 [CFT] [JANITORIAL] Unbork fs.h Daniel Phillips
2002-01-03 14:03 ` Daniel Phillips
2002-01-03 15:45 ` Christoph Hellwig
2002-01-03 16:20 ` Daniel Phillips
2002-01-03 16:47 ` Alexander Viro
2002-01-03 17:25 ` Daniel Phillips
2002-01-03 18:25 ` Daniel Phillips
2002-01-03 18:35 ` Christoph Hellwig
2002-01-03 16:45 ` Alexander Viro
2002-01-03 18:04 ` Daniel Phillips
2002-01-03 16:05 ` Ion Badulescu
2002-01-03 16:34 ` Daniel Phillips
2002-01-03 16:28 ` Martin Dalecki [this message]
2002-01-03 16:45 ` Arnaldo Carvalho de Melo
2002-01-03 16:36 ` Arnaldo Carvalho de Melo
2002-01-03 17:05 ` Daniel Phillips
2002-01-03 17:07 ` Arnaldo Carvalho de Melo
2002-01-03 19:36 ` Andreas Dilger
2002-01-04 7:05 ` Daniel Phillips
2002-01-04 8:59 ` Andreas Dilger
2002-01-04 10:02 ` Jeff Garzik
2002-01-03 23:25 ` J.A. Magallon
2002-01-04 1:44 ` Daniel Phillips
2002-01-04 14:52 ` J.A. Magallon
2002-01-03 18:53 ` Daniel Phillips
2002-01-03 20:31 ` Ion Badulescu
-- strict thread matches above, loose matches on Subject: below --
2002-01-04 15:16 Andries.Brouwer
2002-01-04 22:20 ` Andreas Dilger
2002-01-04 23:33 ` Daniel Phillips
2002-01-04 16:45 Bryan Henderson
2002-01-04 22:15 ` Andreas Dilger
2002-01-05 1:07 Bryan Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3C3486C9.8080007@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=ion@cs.columbia.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@bonn-fries.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.