Messages in this thread | | | Date | Thu, 18 Dec 2008 10:41:16 +0200 | From | Boaz Harrosh <> | Subject | Re: [PATCH 6/9] exofs: super_operations and file_system_type |
| |
Marcin Slusarz wrote: > On Tue, Dec 16, 2008 at 05:31:30PM +0200, Boaz Harrosh wrote: >> This patch ties all operation vectors into a file system superblock >> and registers the exofs file_system_type at module's load time. >> >> * The file system control block (AKA on-disk superblock) resides in >> an object with a special ID (defined in common.h). >> Information included in the file system control block is used to >> fill the in-memory superblock structure at mount time. This object >> is created before the file system is used by mkexofs.c It contains >> information such as: >> - The file system's magic number >> - The next inode number to be allocated >> >> Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> > > Some minor comments below. >
Thank you Marcin for your comments. They are all true and I will fix them.
Just as a side note, most of your comments are on code inherited from ext2. Though it is a good chance to fix them here.
>> --- <snip> >> + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); >> + if (!sbi) >> + return -ENOMEM; >> + sb->s_fs_info = sbi; >> + >> + /* use mount options to fill superblock */ >> + sbi->s_dev = osduld_path_lookup(opts->dev_name); >> + if (IS_ERR(sbi->s_dev)) { >> + ret = PTR_ERR(sbi->s_dev); >> + sbi->s_dev = NULL; >> + goto free_sbi; >> + } >> + >> + sbi->s_pid = opts->pid; >> + sbi->s_timeout = opts->timeout; >> + >> + /* fill in some other data by hand */ >> + memset(sb->s_id, 0, sizeof(sb->s_id)); > > wasn't it zeroed by kzalloc? >
That is a different kzalloc, though I agree that a memset is a bit hysterical for a strcpy
>> + strcpy(sb->s_id, "exofs");
Thanks Boaz
| |