On 6/22/08, Russ Cox <[EMAIL PROTECTED]> wrote:
> Rob wrote the script below, called "namespace", years ago.
> It is essentially a script version of newns.
> You could do
>
> 9fs boot
> namespace /n/boot dossrv
>
> if you really wanted to, but that seems like overkill to me.
It sure wo
> Just FYI, you are mucking around in one of the
> least satisfactory parts of the system: dossrv, 9660srv, etc.
> The fact that they interpret the mount spec as a file name
> in their own name space means that if you already have
> dossrv running in one window and do
>
> import othermachin
> I was wondering if it would be possible to start dossrv in a new
> namespace, built from scratch, so I've been playing a bit with rfork
> (the rc builtin).
> However, when I do a 'rfork N', my namespace is empty after that (of
> course), but I'm not sure how to get it populated again? Since /bin
On 6/22/08, Russ Cox <[EMAIL PROTECTED]> wrote:
> What I wrote yesterday was correct but incomplete.
> In addition to the file descriptors, dossrv is holding
> up a reference to the window's name space, in which
> the window files are still accessible. If you do
>
> slay dossrv |rc # clean
> i think that dossrv's quirks are surprising. the
> redirection in 9fat: is superfluous since 9fat opens
> /dev/null on fds 0 and 1 and it makes this surprise
> move for fd 2:
>
> if(!chatty){
> close(2);
> open("#c/cons", OWRITE);
> }
>
> that's downrigh
> On 6/22/08, Russ Cox <[EMAIL PROTECTED]> wrote:
>> It is not waiting for dossrv to exit,
>> so much as it is waiting for all the open
>> file descriptors referring to that window's
>> /dev/cons to be closed. Dossrv just happens
>> to be the one holding them.
>>
>> Probably the various dossrv'ing
> But that's what 9fat: does (well, not literally, since it does 'dossrv
>>/dev/null [2]/dev/null', but it means the same). So then
> dossrv shouldn't be holding the window's /dev/cons open, right?
What I wrote yesterday was correct but incomplete.
In addition to the file descriptors, dossrv is ho
On 6/22/08, Russ Cox <[EMAIL PROTECTED]> wrote:
> It is not waiting for dossrv to exit,
> so much as it is waiting for all the open
> file descriptors referring to that window's
> /dev/cons to be closed. Dossrv just happens
> to be the one holding them.
>
> Probably the various dossrv'ing scripts
On 6/21/08, erik quanstrom <[EMAIL PROTECTED]> wrote:
> unmount /n/9fat if you think this is a problem.
Sorry, I should have mentioned this in my initial mail, but it also
happens when I unmount /n/9fat (and /n/9) before trying to exit.
> When I open a window in rio, run 9fat:, and then exit, the window gets
> 'stuck'. That is, it just sits there, I can't type anything in it
> anymore.
> Apparently, it is waiting for dossrv to exit (which gets started by
> 9fat:): when I open a second window, and run 'kill dossrv | rc', the
> firs
> It's happened to me quite often. I think rc should kill all
> subprocesses on exit
No. It shouldn't, and it doesn't.
> How I wish Plan 9 had kill -9! The kernel uses the note
>
> sys: killed
>
> internally, but notify(2) doesn't say so. I wonder...
Plan 9 is not Unix.
echo
On Jun 21, 2008, at 2:21 PM, Sander van Dijk wrote:
This (being unable to exit the window without killing dossrv) seems a
bit strange to me. I can of course destroy the window using the
'Delete' option in rio's menu, but I think that's not the 'right' way
to do it.
Am I doing something wrong (is
> This (being unable to exit the window without killing dossrv) seems a
> bit strange to me. I can of course destroy the window using the
> 'Delete' option in rio's menu, but I think that's not the 'right' way
> to do it.
> Am I doing something wrong (is there a way I can actually exit said
> windo
Hi,
When I open a window in rio, run 9fat:, and then exit, the window gets
'stuck'. That is, it just sits there, I can't type anything in it
anymore.
Apparently, it is waiting for dossrv to exit (which gets started by
9fat:): when I open a second window, and run 'kill dossrv | rc', the
first windo
14 matches
Mail list logo
