Subject rfork N
I want to construct a new namespace for an app, including a new root dir.
I was hoping to do this with a few lines of script starting with rfork N,
however this seems to be a dead end.
I can still access kernel devices directly using the # escape in filenames,
which includes '#s/f
On Tue Aug 9 08:41:44 EDT 2011, st...@quintile.net wrote:
> Subject rfork N
>
> I want to construct a new namespace for an app, including a new root dir.
> I was hoping to do this with a few lines of script starting with rfork N,
> however this seems to be a dead end.
>
> I can still access kern
> don't you just want rfork Nm?
I don't think so, that is worse, this would really mean
I couldn't mount anything.
I don't mind the new app adding mounts if it wants to, but
I want it to start with a new root dir and children, so
I need to flush out the old namespace.
the problem is as soon as I
On Mon, Aug 8, 2011 at 8:03 PM, andrey mirtchovski
wrote:
>> Yes. How to these work in Lion? My old p9p build simply didn't display
>> anything devdraw related.
>
> i got the 9pserve fail once (no bus error, just '9pserve failed'), but
> it went away when i copied a binary from a different machine
Yes, rfork N is very nearly useless in rc.
In a C program it is more useful, because
you can open file descriptors you need
before and make system calls afterward.
Russ
> The only solution I can see is to write some C code, but
> I was hoping somone might see a trick I missed.
what are you really trying to accomplish?
- erik
> the problem is as soon as I do that I lost contact with the
> mount command and as its not a shell builtin this means I
> can never get back the namespace I have lost.
auth/newns
> auth/newns
Aha!
excellent, this is just what I need.
thanks
-Steve
Was the console hostdomain file ever used for anything? I can't
find anything in the userland source tree that references it.
Summary:
at new installation from live cd on old hardware, with pcf kernel
the keyboard did not
work until I added a line uartisato the pcf kernel config and
compiled a new kernel.
Context:
while installing plan 9 using live cd(*) on ancient hardware(**) I
noticed the following:
I was surprised to stumble across a handful of rc scripts in
/386/bin/aux. Shouldn't this directory contain only 386 binary
executables? With the exception of the vmware script, none of these
are specific to the 386 hardware platform in any way.
Shouldn't we have an /rc/bin/aux directory and do
On Tue Aug 9 18:26:01 EDT 2011, lyn...@orthanc.ca wrote:
> I was surprised to stumble across a handful of rc scripts in
> /386/bin/aux. Shouldn't this directory contain only 386 binary
> executables? With the exception of the vmware script, none of these
> are specific to the 386 hardware platfo
> one could make /lib/namespace
> more complicated to make /bin/aux a union directory as well, but that
> sounds like a lot of work for no particular gain.
The alternate pain is in the respective mkfiles. Munging the namespace
(once) seems like the cleaner approach in my view.
On Aug 9, 2011 6:30 PM, "erik quanstrom" wrote:
>
> On Tue Aug 9 18:26:01 EDT 2011, lyn...@orthanc.ca wrote:
> the tradition has been to copy scripts into /$cputype/bin/$somesubdir
> for every arch.
>
I've always been under the impression they went in /rc/bin/.
On Tue, Aug 9, 2011 at 3:54 PM, Jacob Todd wrote:
>
> On Aug 9, 2011 6:30 PM, "erik quanstrom" wrote:
>>
>> On Tue Aug 9 18:26:01 EDT 2011, lyn...@orthanc.ca wrote:
>> the tradition has been to copy scripts into /$cputype/bin/$somesubdir
>> for every arch.
>>
> I've always been under the impress
On Tue Aug 9 18:49:07 EDT 2011, lyn...@orthanc.ca wrote:
> > one could make /lib/namespace
> > more complicated to make /bin/aux a union directory as well, but that
> > sounds like a lot of work for no particular gain.
>
> The alternate pain is in the respective mkfiles. Munging the namespace
>
> to paraphrase russ, the bike shed is painted and the painter
> has left.
And there's nothing worse than a fucking art critic.
Please don't touch the artwork.
Do work carefully amongst the artwork.
> Please don't touch the artwork.
>
> Do work carefully amongst the artwork.
And never, ever, ask the artist for his motivation.
19 matches
Mail list logo
