linux-kernel - Re: [PATCH 4/5] mm: add numa node symlink for cpu devices in sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.1.00.0910201407190.27248@chino.kir.corp.google.com>
Date:	Tue, 20 Oct 2009 14:09:45 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Alex Chiang <achiang@...com>
cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] mm: add numa node symlink for cpu devices in sysfs

On Tue, 20 Oct 2009, Alex Chiang wrote:

> * David Rientjes <rientjes@...gle.com>:
> > On Mon, 19 Oct 2009, Alex Chiang wrote:
> > 
> > > You can discover which CPUs belong to a NUMA node by examining
> > > /sys/devices/system/node/$node/
> > > 
> > 
> > You mean /sys/devices/system/node/node# ?
> 
> Hm, in PCI land, I've been using $foo to indicate a variable in
> documentation I've written, but I can certainly use foo# if
> that's the preferred style.
> 

I'm referring to the directories in /sys/devices/system/node/ being 
'node13' for example, and not '13' as your changelog indicates.

> > > However, it's not convenient to go in the other direction, when looking at
> > > /sys/devices/system/cpu/$cpu/
> > > 
> > 
> > .../cpu/cpu# ?
> > 

Same here.

> > The return values of register_cpu_under_node() and 
> > unregister_cpu_under_node() are always ignored, so it would probably be 
> > best to convert these to be void functions.  That doesn't mean you can 
> > simply ignore the result of the first sysfs_create_link(), though: the 
> > second should probably be suppressed if the first returns an error.
> > 
> 
> I didn't want to change too much in the patch. Changing the
> function signature seems a bit overeager, but if you have strong
> feelings, I can do so.
> 

It's entirely up to you if you want to change them to be void.  I thought 
it would be cleaner if the first patch in the series would convert them to 
void on the basis that the return value is never actually used and then 
the following patches simply return on error conditions.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/