On Fri, Jan 9, 2009 at 2:05 AM, Roman V. Shaposhnik r...@sun.com wrote:
Multiplexing. If devices exposed channel interface, and got
exported there would be no kernel protecting from clients
sending random sequences of 9P messages (on a single host
you can't mount a channel and then continue
On Mon, 2009-01-05 at 11:00 +, roger peppe wrote:
i've sometimes thought that the trick used by #d etc could
be made more transparent by providing a genuine capability
service for fds, in the form of a system call, for instance
getfdcap(int fd, char *buf, int len)
then instead of
On Tue, 2009-01-06 at 18:15 -0500, erik quanstrom wrote:
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours (I agree that remote mounting of the kernel
services,
On Thu, 2009-01-08 at 18:48 -0500, erik quanstrom wrote:
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to
the example that prompted the `fish' remark was: cd location; pwd shows
location.
This just means that these services need to be mounted at the canonical
there is no point binding #a or #D into the name space.
they can be used only locally and might as well
be accessed directly. they might be considered similar to
push in streams. #s has a similar difficulty to #a and #D
On Tue, 2009-01-06 at 20:37 +, Charles Forsyth wrote:
This just means that these services need to be mounted at the canonical
there is no point binding #a or #D into the name space.
they can be used only locally and might as well
be accessed directly. they might be considered similar to
Although in the alternative universe I can see how implementing #X
as *channels* capable of 9P messages, could enable things like mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours (I agree that remote mounting of the kernel
services, which
mounting
them on external hosts and letting these hosts manipulate physical
devices attached to yours
That's the function of import/export and is one of Plan 9's strong
suits. Surely I cannot have been fooled all these years?
++L
i've sometimes thought that the trick used by #d etc could
be made more transparent by providing a genuine capability
service for fds, in the form of a system call, for instance
getfdcap(int fd, char *buf, int len)
then instead of just writing the fd itself, you'd write
the capability - thus
I don't believe you can write a race-free implementation of
the pipe system call using #|.
Could you, please, elaborate on what particular race do you have
in mind? Indeed, I ran into a problem with devpipe implementation,
but it isn't a race, its a dreaded implicit -attach that namec()
I'm confused. Is there any part of syspipe() that can NOT
be done from userspace? Why does it have to be a syscall?
Thanks,
Roman.
P.S. I would also argue that sysdup() would seem to be superfluous
if more feature-rich devdup was available.
On Sat, Jan 3, 2009 at 9:04 PM, Roman V. Shaposhnik r...@sun.com wrote:
I'm confused. Is there any part of syspipe() that can NOT
be done from userspace? Why does it have to be a syscall?
P.S. I would also argue that sysdup() would seem to be superfluous
if more feature-rich devdup was
14 matches
Mail list logo
