From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8f646c8069d0c94b170f73daec7c7a42@terzarima.net>
From: Charles Forsyth <forsyth@terzarima.net>
Date: Wed,  8 Dec 2010 16:26:38 +0000
To: 9fans@9fans.net
In-Reply-To: <066486e67299fd5a3f2605c8df948616@plug.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] the futility of QTMOUNT
Topicbox-Message-UUID: 8969d012-ead6-11e9-9d60-3106f5b1d025

QTMOUNT allows exportfs to detect an attempt to open a /srv file
that has been opened and mounted somewhere on the system running exportfs
(i'll refer to that as the `called system' and the client of exportfs as
the `calling system').

exportfs opens the /srv file, mounts that file descriptor itself,
and then serves 9p itself to access the resulting name space,
when the caller mounts it (on the calling system), just as
if the caller had been able to open the /srv file directly to mount it
(on the calling system). that's needed because once a file is serving 9p,
it can't be read or written directly (see the CMSG flag on chans).

it isn't to do with exporting name spaces that contain remote elements.