[PATCH] XATTR support on JFFS2 (version. 5)
KaiGai Kohei
kaigai at ak.jp.nec.com
Wed May 10 08:03:40 EDT 2006
Hi,
>> Few suggestions for now (again cosmetic):
>>
>> 1. GC-related functions and summary-related functions should be moved to
>> gc.c and summary.c
>
> Then they'd need ifdefs. I'd prefer to keep them where they are, in
> separate files which aren't compiled if the XATTR options are disabled.
I also agree David's opinion.
In addition, those functions are deployed enough locally-separating
in xattr.c.
Sorry, I could not understand your dissatisfaction.
>> 2. JFFS2 uses namings we all are used to. E.g., c - JFFS2 superblock
>> structure, ref - struct jffs2_node_ref. I've noticed you use 'ref' as
>> jffs2_xattr_ref pointers which is just a bit confusing. I would suggest
>> you calling them 'xref' - this would improve readability a bit.
>
> Really, I don't think it matters.
>
>>> + delete_xattr_ref(c, ref);
>>> + delete_xattr_ref(c, xref);
>
>> It's minor, but still.
>
> It's not even 'minor'. It's total bullshit. If you can't look at the
> function name "delete_XATTR_REF" and work out what 'ref' is in that
> context, then you really shouldn't be trying to read the code. Life is
> hard; let's go shopping.
Is the 'raw' used as the common name for jffs2_raw_node_ref, not 'ref',
isn't it? Because I thought those are not confusable, I adopted 'ref'
as a name of jffs2_xattr_ref.
If we can arrive an agreement that it's confusable naming scheme,
I'll prepare to change the common name of jffs2_xattr_ref.
Both naming schemes are acceptable for me.
It's important to decide what should be decided at first, I think.
Thanks,
--
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai at ak.jp.nec.com>
More information about the linux-mtd
mailing list