[9fans] Getting a file descriptor to become /dev/cons

[9fans] Getting a file descriptor to become /dev/cons

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1961 bytes --]

I have a situation where I want to take an already-open file descriptor, and make it become /dev/cons before I start a shell.
I can't mount it on /dev/cons because it's not a 9p server - just a simple pipe end.
If it was a named pipe, I could bind that.
fd2path on a pipe just produces: '#|/data' - not a unique name I could bind to. So no help there...
I thought I would put it in /srv with a unique name and then bind it over /dev/cons.
Starting with a shell that already has the file as fd #2, I tried this:
term% echo 2 >/srv/foo
term% bind /srv/foo /dev/cons
This *almost* works:
term% echo hello >>/dev/cons
hello
term% 
The problem is that the file in /srv doesn't quite behave like a named pipe end:
term% echo hello >/dev/cons
/dev/cons: rc: can't open: '/dev/cons' srv file already exists
term% 
I think this is from a check for OTRUNC on open in devsrv in the kernel, which I would guess is being done so people don't accidentally try to use a /srv name that's already in use (I had initially thought it might be a failure from create, or some permissions problem).
I tried setting the DMAPPEND bit on the /srv file, in the hopes that that would suppress the OTRUNC, but the kernel srv driver masks off that bit of the file mode, unfortunately.
I still haven't been brave enough to go messing with the plan9 kernel.

I'm thinking at this point that I could make a very small 9p file server, serving a file that essentially forwards to and from a file descriptor that the server is given when it starts. I'd mount that on /dev/cons, and I think I can probably make that work. But it seems clumsy, given that a more direct solution seems so close.

So I wondering: is there a better way to do this?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-Mdbe4e51c3e84c907521adf60
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6496 bytes --]

Re: [9fans] Getting a file descriptor to become /dev/cons

[Dan Cross]

On Wed, Oct 29, 2025 at 11:53 AM Alyssa M via 9fans <9fans@9fans.net> wrote:
> I have a situation where I want to take an already-open file descriptor, and make it become /dev/cons before I start a shell.
> I can't mount it on /dev/cons because it's not a 9p server - just a simple pipe end.
> If it was a named pipe, I could bind that.
> fd2path on a pipe just produces: '#|/data' - not a unique name I could bind to. So no help there...
> I thought I would put it in /srv with a unique name and then bind it over /dev/cons.
> Starting with a shell that already has the file as fd #2, I tried this:
>
> term% echo 2 >/srv/foo
> term% bind /srv/foo /dev/cons
>
> This *almost* works:
>
> term% echo hello >>/dev/cons
> hello
> term%
>
> The problem is that the file in /srv doesn't quite behave like a named pipe end:
>
> term% echo hello >/dev/cons
> /dev/cons: rc: can't open: '/dev/cons' srv file already exists
> term%
>
> I think this is from a check for OTRUNC on open in devsrv in the kernel, which I would guess is being done so people don't accidentally try to use a /srv name that's already in use (I had initially thought it might be a failure from create, or some permissions problem).
> I tried setting the DMAPPEND bit on the /srv file, in the hopes that that would suppress the OTRUNC, but the kernel srv driver masks off that bit of the file mode, unfortunately.
> I still haven't been brave enough to go messing with the plan9 kernel.
>
> I'm thinking at this point that I could make a very small 9p file server, serving a file that essentially forwards to and from a file descriptor that the server is given when it starts. I'd mount that on /dev/cons, and I think I can probably make that work. But it seems clumsy, given that a more direct solution seems so close.
>
> So I wondering: is there a better way to do this?

pipefile(1) does something very close to this already. Perhaps you can
use it directly? If not, perhaps its implementation may be useful as a
source of ideas. It appears that it just finds the pipe device to a
name of its own choosing, and then connects to the ends of that. I
suppose it depends on which namespace it is created in, and where you
want to use it from (useful thing about srvfs is that it allows two
unrelated namespaces to share a named thing).

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-M8408e85e6405eb809bfd97dc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Getting a file descriptor to become /dev/cons

[Jacob Moody]

On 10/29/25 09:35, Alyssa M via 9fans wrote:
> I have a situation where I want to take an already-open file descriptor, and make it become /dev/cons before I start a shell.
> I can't mount it on /dev/cons because it's not a 9p server - just a simple pipe end.
> If it was a named pipe, I could bind that.
> fd2path on a pipe just produces: '#|/data' - not a unique name I could bind to. So no help there...
> I thought I would put it in /srv with a unique name and then bind it over /dev/cons.
> Starting with a shell that already has the file as fd #2, I tried this:
> 
> term% echo 2 >/srv/foo
> term% bind /srv/foo /dev/cons
> 
> This *almost* works:
> 
> term% echo hello >>/dev/cons
> hello
> term% 
> 
> The problem is that the file in /srv doesn't quite behave like a named pipe end:
> 
> term% echo hello >/dev/cons
> /dev/cons: rc: can't open: '/dev/cons' srv file already exists
> term% 
> 
> I think this is from a check for OTRUNC on open in devsrv in the kernel, which I would guess is being done so people don't accidentally try to use a /srv name that's already in use (I had initially thought it might be a failure from create, or some permissions problem).
> I tried setting the DMAPPEND bit on the /srv file, in the hopes that that would suppress the OTRUNC, but the kernel srv driver masks off that bit of the file mode, unfortunately.
> I still haven't been brave enough to go messing with the plan9 kernel.
> 
> I'm thinking at this point that I could make a very small 9p file server, serving a file that essentially forwards to and from a file descriptor that the server is given when it starts. I'd mount that on /dev/cons, and I think I can probably make that work. But it seems clumsy, given that a more direct solution seems so close.
> 
> So I wondering: is there a better way to do this?
> 
> 


Can you give us some more context about why you're attempting to use an already open file descriptor as /dev/cons?
It's hard for me to say without the specifics but typically the expectation is that the parent process is responsible
for setting up the environment in the most compatible way before passing the buck off to a child (assuming that's what you
have going on here). While pipes do not have unique locations that is because new pipes are essentially generated on attach,
each walk to a fresh '#|' gives you a new set of pipes. However you can pin an instance by keeping the reference to the root
around. So something roughly like this:

bind '#|' /n/pipe
@{
        rfork n
        bind /n/pipe/data1 /dev/cons
        # start your child program here
}
>/n/pipe/data {
        # Do whatever you want from the parent
}

Keep in mind though that the parent has to keep the pipe open after first opening it, or else the program on the child's end
will get an EOF.

Essentially, instead of working backwards from a low context situation (just the fd), have the parent or caller do a bit more
work to setup with the environment where they do have the context.


Thanks,
moody


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-Mb18512aecd04b3f12d478416
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Getting a file descriptor to become /dev/cons

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2815 bytes --]

On Wednesday, October 29, 2025, at 4:09 PM, Dan Cross wrote:
> pipefile(1) does something very close to this already. Perhaps you can
use it directly? If not, perhaps its implementation may be useful as a
source of ideas.
Thanks for that! I'll have a closer look. The bugs section mentions that it ought to be rewritten as a user file server, so I guess it's a bit of a compromise.

On Wednesday, October 29, 2025, at 4:10 PM, Jacob Moody wrote:
> Can you give us some more context about why you're attempting to use an already open file descriptor as /dev/cons?
I'm porting my window system to plan 9. One of the ways its different from rio is that the programs that run in the separate windows share a namespace by default. That's not required, but rforking the namespace is not required by the window system either. It also doesn't have a /dev/cons as such, but some text-oriented programs on Plan 9 (e.g. p(1)) will depend on finding that in the namespace. So I want that to be possible for interoperability.

On Wednesday, October 29, 2025, at 4:10 PM, Jacob Moody wrote:
> Essentially, instead of working backwards from a low context situation (just the fd), have the parent or caller do a bit more
work to setup with the environment where they do have the context.
This seems like the way to go - but I also want to avoid rforking the namespace for all text windows just for the programs that need /dev/cons. I think sometimes it's nice for shells in windows to share a namespace... perhaps I'm just not thinking plan9y enough.
My text window program normally puts a distinct name in the shared namespace for each instance  e.g. /dev/tty1 - something I've used relatively rarely in practice, and I wasn't committing to recreate on plan 9. But perhaps I should. I can use named pipes on the Plan 9 version as you describe and, after an rfork, bind /dev/cons to whichever is the contextual one. 
I need to figure out how to find which named pipe should be bound to /dev/cons. I have an idea involving naming the named pipes with their qid.path, e.g. "/n/pipe3f941". I can recover the qid.path number in an fstat of one of the open fds, so I could then generate the name of the file to bind from that (is that a bit hokey??)
Alternatively I could "rfork e" and put the pipe path in an environment variable for later use. That seems nicer, but I'm not really sure I want my window system to "rfork e" for me either... 
Hmm. Not sure what's best at this point.

Many thanks for the advices! I think I have some possible ways forward now, but it's far from finished.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-M9d1461d61efeb3c813cddbaf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3729 bytes --]

Re: [9fans] Getting a file descriptor to become /dev/cons

[ori]

Quoth Alyssa M via 9fans <9fans@9fans.net>:
> I'm porting my window system to plan 9. One of the ways its different from rio is that the programs that run in the separate windows share a namespace by default. That's not required, but rforking the namespace is not required by the window system either. It also doesn't have a /dev/cons as such, but some text-oriented programs on Plan 9 (e.g. p(1)) will depend on finding that in the namespace. So I want that to be possible for interoperability.

I think it actually is necessary, or they will all end up reading from the same
/dev/cons.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-M506d7c5f9eeab09def00703f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Getting a file descriptor to become /dev/cons

[Alyssa M via 9fans]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

Well they would!
My idea (and it may not be a very good one, as I'm still not very fluent with plan 9) is to delay the namespace rfork until I want to bind /dev/cons for something that needs it. There's an rfork command in rc that can do the separation.
So I'd do something like:
term% rfork n
term% bind something /dev/cons
term% p longfile
or wrap it up in a script so I can say:
term% withconsole p longfile
or even just:
term% more longfile
;) which would do the whole thing. The trick is finding the contextual console...

I realise there's more to this than /dev/cons, though. Eventually I think I'd want something like drawterm. That's a bit daunting tbh. 
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-M9dfd57da6803373121541a5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2219 bytes --]