:On Mon, 19 Jul 1999, John Milford wrote:
:
:> Unless I am misunderstanding you, mfs does what you are
:> describing.
:
:I'm pretty sure you're misunderstanding him. MFS is not even close.
:
:ron
You know, none of us are being clear :-)
The basic problem is that MFS is not a filesyst
On Mon, 19 Jul 1999, John Milford wrote:
> Unless I am misunderstanding you, mfs does what you are
> describing.
I'm pretty sure you're misunderstanding him. MFS is not even close.
ron
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of t
:On Mon, 19 Jul 1999, John Milford wrote:
:
:> Unless I am misunderstanding you, mfs does what you are
:> describing.
:
:I'm pretty sure you're misunderstanding him. MFS is not even close.
:
:ron
You know, none of us are being clear :-)
The basic problem is that MFS is not a filesys
On Mon, 19 Jul 1999, John Milford wrote:
> Unless I am misunderstanding you, mfs does what you are
> describing.
I'm pretty sure you're misunderstanding him. MFS is not even close.
ron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the
Matthew Dillon wrote:
>
> This seems like an unnecessary complication to me. It would be
> easier to simply make it a device that you can open(), read(), and
> write() as I first suggested.
>
> MFS is not a good template for any of this. MFS is very, very simple
> and the p
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> This seems like an unnecessary complication to me. It would be
> easier to simply make it a device that you can open(), read(), and
> write() as I first suggested.
>
> MFS is not a good template for any of this. MFS is very, very si
:
:Matthew Dillon wrote:
:
:>
:> No, MFS runs in supervisor mode. That mfs process that you see hanging
:> there is just placemarking the VM space.
:>
:> -Matt
:>
:
: Well, I think there is a little more to it than that. I
:believe it does
Matthew Dillon wrote:
>
> No, MFS runs in supervisor mode. That mfs process that you see hanging
> there is just placemarking the VM space.
>
> -Matt
>
Well, I think there is a little more to it than that. I
believe it does run in supe
:
:Matthew Dillon <[EMAIL PROTECTED]> wrote:
:
:>
:> No, MFS runs in supervisor mode. That mfs process that you see hanging
:> there is just placemarking the VM space.
:>
:> -Matt
:>
:
: Well, I think there is a little more to it than that.
Matthew Dillon <[EMAIL PROTECTED]> wrote:
>
> No, MFS runs in supervisor mode. That mfs process that you see hanging
> there is just placemarking the VM space.
>
> -Matt
>
Well, I think there is a little more to it than that. I
believe
:
:David,
:
: Unless I am misunderstanding you, mfs does what you are
:describing.
:
: --John
No, MFS runs in supervisor mode. That mfs process that you see hanging
there is just placemarking the VM space.
-Matt
To Unsub
:
:David,
:
: Unless I am misunderstanding you, mfs does what you are
:describing.
:
: --John
No, MFS runs in supervisor mode. That mfs process that you see hanging
there is just placemarking the VM space.
-Matt
To Unsu
David,
Unless I am misunderstanding you, mfs does what you are
describing.
--John
"David E. Cross" wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional way I have seen
> t
David,
Unless I am misunderstanding you, mfs does what you are
describing.
--John
"David E. Cross" <[EMAIL PROTECTED]> wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional
On Mon, 19 Jul 1999, Ronald G. Minnich wrote:
> Great idea. I liked it so much I bought the company -- er, I mean, I wrote
> something like this. It's private name spaces for Linux and FreeBSD (among
> others) and it allows you to mount things from remote file servers into
> your name space.
I
On Sun, 18 Jul 1999, Boris Popov wrote:
> On Sat, 17 Jul 1999, David E. Cross wrote:
> > I am looking at a project that will require a user based process to interact
> > with the system as if it were a filesystem. The traditional way I have
> > seen
>
> That type of file system is very
On Mon, 19 Jul 1999, Ronald G. Minnich wrote:
> Great idea. I liked it so much I bought the company -- er, I mean, I wrote
> something like this. It's private name spaces for Linux and FreeBSD (among
> others) and it allows you to mount things from remote file servers into
> your name space.
I
On Sun, 18 Jul 1999, Boris Popov wrote:
> On Sat, 17 Jul 1999, David E. Cross wrote:
> > I am looking at a project that will require a user based process to interact
> > with the system as if it were a filesystem. The traditional way I have seen
>
> That type of file system is very use
:
:Portal FS did give me a couple of starting points.. It looks interesting.
:Just for my own clarification... how would this be different than NFS
:(specifically local NFS)?
:
:--
:David Cross | email: cro...@cs.rpi.edu
:Systems Administrator/Research Programmer | We
:
:Portal FS did give me a couple of starting points.. It looks interesting.
:Just for my own clarification... how would this be different than NFS
:(specifically local NFS)?
:
:--
:David Cross | email: [EMAIL PROTECTED]
:Systems Administrator/Research Programmer | W
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesystem will allow you
> to do is pass back
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesystem will allow you
> to do is pass back
On Sat, 17 Jul 1999, David E. Cross wrote:
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interaction, etc). But I am just feeling arround for what people think
> about this. Any ideas/comments?
John Heidemann's papers on file system stacking layers refer to
On Sat, 17 Jul 1999, David E. Cross wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional way I have seen
[...]
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interac
On Sat, 17 Jul 1999, David E. Cross wrote:
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interaction, etc). But I am just feeling arround for what people think
> about this. Any ideas/comments?
John Heidemann's papers on file system stacking layers refer to
:> :
:> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
:> : gr...@freebsd.org _ __ ___ | _ ) __| \
:>
:> Actually, it isn't quite. All the portal filesystem will allow you
:> to do is pass back a descriptor. It does not allow you to simulate
:> a f
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesys
On Sat, 17 Jul 1999, David E. Cross wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional way I have seen
[...]
> I have a number of questions on more specific ideas (like caching, inode/vnode
> intera
:> :
:> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
:> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
:>
:> Actually, it isn't quite. All the portal filesystem will allow you
:> to do is pass back a descriptor. It does not allow you to simulate
:> a
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesy
:
:Look into the portal filesystem. This is what you want :)
:
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
: gr...@freebsd.org _ __ ___ | _ ) __| \
Actually, it isn't quite. All the portal filesystem will allow you
to do is pass back a descriptor. I
Look into the portal filesystem. This is what you want :)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/__
:
:Look into the portal filesystem. This is what you want :)
:
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
: [EMAIL PROTECTED] _ __ ___ | _ ) __| \
Actually, it isn't quite. All the portal filesystem will allow you
to do is pass back a descriptor.
Look into the portal filesystem. This is what you want :)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/_
I am looking at a project that will require a user based process to interact
with the system as if it were a filesystem. The traditional way I have seen
this done is as the system NFS mounting itself (ala AMD). I would really like
a more clean approach to this. What I am interested in is a 'Use
I am looking at a project that will require a user based process to interact
with the system as if it were a filesystem. The traditional way I have seen
this done is as the system NFS mounting itself (ala AMD). I would really like
a more clean approach to this. What I am interested in is a 'Us
36 matches
Mail list logo
