As much as I hate to touch either subject, let alone both at

once...  Eric, would you mind explaining what exactly do you want

sysfs to do in presense of your "namespaces"?  On the "what does user

see if we do <...>" level.
	a) what happens if I do chdir("/sys/class/net/eth42/") and then

migrate?
	b) what happens to /sys/class/net/eth0/device visibility/things

it points to/etc.?
	c) what happens to open files?  E.g. to /sys/class/net - say it,

if migration happens between two getdents(2).
	d) what happens to visibility in other parts of sysfs?  E.g. to

things like

$ ls  /sys/devices/pci0000\:00/0000\:00\:0a.0/

bus     device  local_cpus  power      resource1         uevent

class   driver  modalias    resource   subsystem_device  vendor

config  irq     net:eth0    resource0  subsystem_vendor

$

See that net:eth0 in there?  Are all such suckers seen?
	e) while we are at it, wouldn't seeing the information in

/sys/devices/pci in general defeat whatever purpose you have in mind

for your stuff?
Context: we need sane locking for sysfs.  I think I have a more or less

workable scheme, but its feasibility depends big way on what netns needs

to have.

--

It is not a clean solution at all.  In particular, it leaves you with hell
Yes, I'm quite sure there's more coming.  Which is why I'm asking now,
Inode numbers?  Are you suggesting a wholesale replacement of all struct

file referenced by descriptor tables, all way down to inodes?  May I see
... and you have quite a bit of system state (starting with those net:eth0
Excuse me, _what_?  Are you seriously suggesting going through all dentry

trees, doing d_move() in each?  I want to see your locking.  It's promising

to be worse than devfs had ever been.  Much worse.

--