Some comments on your patch ...
1) It's easier for others to read patches if they are inline text,
or at least attached as text, not as base64. See further the
kernel source file: Documentation/SubmittingPatches. If your
company's email client has difficulty attaching patches without
mangling them, then perhaps you will have better luck with a
dedicated patch sending program, such as one I support:
http://www.speakeasy.org/~pj99/sgi/sendpatchset
2) > cpumask_scnprintf(buf, NR_CPUS+1, cpu_core_map[cpu]);
The 2nd arg, "NR_CPUS+1", is wrong. It should be the length
of the buffer (1st arg, "buf"). Unfortunately, you probably
aren't passed that length by sysfs. Your routine was likely
passed a page, so assuming a size of PAGE_SIZE/2 would work
(big enough to print a cpumask, small enough not to allow
buffer overrun.)
3) The patch needs to include reasonable documentation (not
just the patch header that goes in the source control log,
but also documentation that will into the source file and/or
into the Documentation directory.) Unfortunately, it seems
that the rest of /sys/devices/system is not directly documented
under Documentation, except as it pertains to such subjects as
cpufreq, laptop, numastat and hotplug. So until someone takes
on the challenge of documenting the rest of this /sys hierarchy,
I see no obvious place to add such items as you propose.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]