>i'm also not convinced that changing the namespace >of a running proecss is a safe operation, in general. >for example, wikifs creates lock files. suppose you >swap out the directory with someone holding the lock.
>what's the plan for dealing with this difficulty? A very good point, and I hope you don't think the response "trust the user to administer their system and accept that it is possible to do broken things" is trying to dodge the issue. It is unquestionably true that programs generally dont expect their namespace to be modified underneath them, and doing so could cause them to lose track of files they need, write data to the wrong place, etc. In my testing and work i have mostly been concerned with causing problems a layer down - inadvertently corrupting kernel memory structures, causing refcounting to go awry, things of that nature. If the potential problems are limited to the fact that rewriting process namespaces is sometimes a mistake, I don't think that is different than the fact that you can cause broken things to happen by doing other operations supported by /proc. For what it's worth, in my testing things have tended to work as I hoped and expected, even when trying things that felt a bit 'risky' like modifying the namespace of the exportfs process serving /mnt/term to the CPU connection to another machine. The fact that rewriting a namespace doesn't change the chan associated with a currently open file descriptor imposes a bit of sanity assurance that standard filesystem operatings won't go berserk just because they were in the middle of a write when you wrote a ns operation to their ns file. However, I admit to not having the comprehensive knowledge of Plan 9 kernel internals I'd need to make a definitive statement that my patches to this couldn't potentially be used to cause unintended behavior inside the kernel. Again, thanks for the interest. ~Mycroftiv
