On 06/26/2014 02:55 PM, David Daney wrote:
On 06/26/2014 12:55 PM, Deng-Cheng Zhu wrote:
On 06/26/2014 12:28 PM, David Daney wrote:
On 06/26/2014 12:11 PM, Deng-Cheng Zhu wrote:
From: Deng-Cheng Zhu <dengcheng.zhu@xxxxxxxxxx>
Since all the files are in arch/mips/kvm/, there's no need of the
prefixes
"kvm_" and "kvm_mips_".
I don't like this change.
It will leads me to confuse arch/mips/kvm/interrupt.h with
include/linux/interrupt.h
We have <linux/interrupt.h> and "interrupt.h".
x86 calls these things irq.c and irq.h, perhaps that would be a little
better.
There's also include/linux/irq.h
Yes, I know.
I simply wanted to let you know that if arch/mips/kvm/interrupt.h and
include/linux/interrupt.h are consufing, then arch/x86/kvm/irq.h and
include/linux/irq.h the same -- not even a little better.
There is precedence in x86 for some of the names though.
But really why churn up the code in the first place? the kvm_mips
prefix does tell us exactly what we are dealing with.
That's why people created the arch/mips/kvm directory, isn't it?
No. Segregating things into directories keeps code related to one
functional area together.
File names are different. They should carry as much meaning as possible.
Remember that directory path is also part of file info.
For examples of this look at some of these directories:
drivers/net/ethernet/intel/ixgb
drivers/i2c/busses
One can find way more examples not having prefixes. Look at kernel/events/.
In the beginning, Perf-events has things under kernel. Then people did
things like:
kernel/perf_event.c -> kernel/events/core.c
If it's kernel/events/perf_events_core.c, I think it looks ugly.
Other examples are kernel/sched/, mm/, and many more. When talking about
filemap.c, one may think it may be under fs/. But there's mm/filemap.c (not
mm/mm_filemap.c which seems, again, ugly). What I want to say is that:
Talking about a file should include its path.
Deng-Cheng
