Messages in this thread | | | Date | Mon, 10 Nov 2008 22:46:09 -0800 | From | Andrew Morton <> | Subject | Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions. |
| |
On Tue, 11 Nov 2008 15:34:39 +0900 Kentaro Takeda <takedakn@nttdata.co.jp> wrote:
> Andrew Morton wrote: > >>> Note that I said "kmalloc", not "kzalloc". This function zeroes > >>> everything all the time, and surely that is not necessary. It's just a > >>> waste of CPU time. > >>> > >> Callers of tmy_alloc assume that allocated memory is zeroed. > > > > That isn't the point. For programmer convenience we could make > > __alloc_pages() and kmalloc() zero all the memory too. But we don't > > because it is slow. > Are you saying "make the callers of tmy_alloc() tolerable with > uninitialized memory"?
Well. That would be a desirable objective. I can understand the reasons for taking the easy way out. Given that Tomoyo doesn't seem to ever free memory again, one hopes that this function doesn't get called a lot, so the performance impact of zeroing out all that memory should be negligible.
I think. Maybe I misinterpreted tmy_alloc(), and perhaps it _is_ called frequently?
> >> Creating pseudo files for each variables is fine, though I don't see > >> advantage by changing from > >> "echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to > >> "echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory". > > > > Well for starters, the existing interface is ugly as sin and will make > > kernel developers unhappy. > > > > There is a pretty strict one-value-per-file rule in sysfs files, and > > "multiple tagged values in one file" violates that a lot. > /sys/kernel/security/ is not sysfs but securityfs. > Does "one-value-per-file rule" also apply to securityfs?
It should apply. It's not so much a matter of rules and regulations. One needs to look at the underlying _reasons_ why those rules came about. We got ourselves into a sticky mess with procfs with all sorts of ad-hoc data presentation and input formatting. It's inconsistent, complex, makes tool writing harder, etc.
So we recognised our mistakes and when sysfs (otherwise known as procfs V2 :)) came about we decided that sysfs files should not make the same mistakes.
So, logically, that thinking should apply to all new pseudo-fs files. Even, in fact, ones which are in /proc!
| |