Dave Quigley:
quoted text
> It is fine to have an overall document describing your FS but there are
> things you have missing. For example patch 62. Why do you have magic
> sysreq handling? What does it do? What problem is it solving? This isn't
> in your 01 patch and I can't tell its purpose at all from the patch.

It simply dumps some aufs status to console. Because I think it is a
nature of magic sysrq, and it is not a feature to solve a specific
problem, I didn't write much, just simply 
----------------------------------------------------------------------
.B sysrq=key
Specifies MagicSysRq key for debugging aufs.
You need to enable both of CONFIG_MAGIC_SYSRQ and CONFIG_AUFS_DEBUG.
If your linux version is linux\-2.6.24 and earlier, you need to enable
CONFIG_AUFS_SYSAUFS too.
Currently this is for developers only.
The default is `a'.
----------------------------------------------------------------------
in the aufs manual.


quoted text
> Another example is what are your sysfs entries for? A description of
> what they are for in either the main doc or as a patch comment is
> necessary. Why is your sysfs functionality broken out into two patches?

One of them is for lifetime management as the description
said. Generally an object correspoing to an entry might be under sysfs
is managed by kref. This management is independent from CONFIG_SYSFS,
and the former patch is compiled unconditionally.
The other is for the actual entires under sysfs, and compiled when SYSFS
is enabled only.
I don't think it is a good idea to make them in a single patch.

But I will re-send the entire aufs patch series in next week, after...
- make some simple header + source pairs in a single patch and try more
  description text, as you pointed out.
- remove some lines unnecessary for -mm tree, pointed out by Jan
  Engelhardt and Sam Ravnborg.
- future other things if someone will point out.


quoted text
> The point of posting these sets to LKML is so people will review them.
> If I have to read through a large document and then through each patch
> individually just to figure out what the patch is trying to accomplish
> before I can see how it is going about accomplishing it, then that is
> extra resistance to actually looking through the set.

I tried to do so...
I thought first document is important too, but the smaller patches in
the later is more preferable than larger ones. Addionally most of them
are totally new files. So I chose "one patch by one new file" way.

Anyway, I will re-send them in next week after trying some grouping.


Thank you
Junjiro Okajima
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/