MTP:[EMAIL PROTECTED]]
Sent: Saturday, October 30, 1999 10:56 AM
To: Alton, Matthew
Subject: Re: BSD XFS Port BSD VFS Rewrite
On Thu, 5 Aug 1999, Alton, Matthew wrote:
I am currently conducting a thorough study of the VFS subsystem
in preparation for an all-out effort to port
stem.
-Original Message-
From: Andrzej Bialecki [SMTP:[EMAIL PROTECTED]]
Sent: Saturday, October 30, 1999 10:56 AM
To: Alton, Matthew
Subject: Re: BSD XFS Port BSD VFS Rewrite
On Thu, 5 Aug 1999, Alton, Matthew wrote:
I am currently conducting a thorough study of the V
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there
On Wed, 18 Aug 1999, Terry Lambert wrote:
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Yes, but we need subsecond in the filesystems. Think about make(1) on
a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made
In message [EMAIL PROTECTED], Terry Lambert writes:
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John Heidemann's
network proxy
In message pine.sol.3.96.990818104932.14430d-100...@marcy.nas.nasa.gov, Bill
Studenmund writes:
I doubt we need more than 64 bit times. 2^63 seconds works out to
292,279,025,208 years, or 292 (american) billion years. Current theories
put the age of the universe at I think 12 to 16 billion
In message pine.bsf.3.95.990818105716.12306a-100...@current1.whistle.com,
Julian Elischer writes:
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable
2. Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks, would we want to keep track both of
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
: Matt doesn't represent the FreeBSD project, and even if he rewrites
: the VFS subsystem so he can understand it, his rewrite would face
: considerable resistance on its way into FreeBSD. I don't think
: there is reason to rewrite it, but there
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there certainly are areas
that need fixing.
You are
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there
In message 199908181848.laa14...@usr02.primenet.com, Terry Lambert writes:
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his
In message 199908181737.laa03...@mt.sri.com, Nate Williams writes:
Both struct timespec and struct timeval are major mistakes, they
make arithmetic on timestamps an expensive operation. Timestamps
should be stored as integers using an fix-point notations, for
instance 64bits with 32bit
On Wed, 18 Aug 1999, Terry Lambert wrote:
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same time.
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Yes, but we need subsecond in the filesystems. Think about make(1) on
a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
worth
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
: Matt doesn't represent the FreeBSD project, and even if he rewrites
: the VFS subsystem so he can understand it, his rewrite would face
: considerable resistance on its way into FreeBSD. I don't think
: there is reason to rewrite it, but there
2. Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks, would we want to keep track both of
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there certainly are areas
that need fixing.
You are
"Daniel C. Sobral" wrote:
Terry Lambert wrote:
That's kind of the point. No other VFS stacking system out there
plays by FreeBSD's revamped rules.
I look around and I see no standards. It is still time to be
experimental.
Since someone complained of my meekness, let me restate
Daniel C. Sobral wrote:
Terry Lambert wrote:
That's kind of the point. No other VFS stacking system out there
plays by FreeBSD's revamped rules.
I look around and I see no standards. It is still time to be
experimental.
Since someone complained of my meekness, let me restate that...
Terry Lambert wrote:
That's kind of the point. No other VFS stacking system out there
plays by FreeBSD's revamped rules.
I look around and I see no standards. It is still time to be
experimental.
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@freebsd.org
-
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When is it going to be ready?
Don't hold your breath. Officially SGI has said by the end of the year,
: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: Re: BSD XFS Port BSD VFS Rewrite
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When is it going
Terry Lambert wrote:
Make sure that the system you are talking to over the proxy is
not assumed to be a FreeBSD system (e.g. don't assume that the
vfs_default stuff exists on the other end of the proxy, or that
it would be functional).
Now, Terry, that is ridiculous. One has to
On Wed, Aug 18, 1999 at 08:43:14PM +, Terry Lambert wrote:
Nope. The problem is that while stacking (null, umap, and overlay fs's)
work, we don't have the coherency issues worked out so that upper layers
can cache data. i.e. so that the lower fs knows it has to ask the uper
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When is it going to be ready?
Don't hold your breath. Officially SGI has said by the end of the year,
: 'hack...@freebsd.org'; 'f...@freebsd.org'
Subject: Re: BSD XFS Port BSD VFS Rewrite
Glad to hear somebody is willing to dive in to XFS.
Right now I am one of three people working on the XFS to linux port, so I
have
pretty good view of what is currently happening.
When
Terry Lambert wrote:
Make sure that the system you are talking to over the proxy is
not assumed to be a FreeBSD system (e.g. don't assume that the
vfs_default stuff exists on the other end of the proxy, or that
it would be functional).
Now, Terry, that is ridiculous. One has to
On Thu, 19 Aug 1999, Alton, Matthew wrote:
Do you have access to more of the code than is currently posted on SGI's
web page? I am willing to sign an NDA in order to get access to all
relevant source. I would like to assist in porting XFS to Linux also. I
would
very much like to see SGI
On Wed, Aug 18, 1999 at 08:43:14PM +, Terry Lambert wrote:
Nope. The problem is that while stacking (null, umap, and overlay fs's)
work, we don't have the coherency issues worked out so that upper layers
can cache data. i.e. so that the lower fs knows it has to ask the uper
In message [EMAIL PROTECTED], Terry Lambert writes:
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the
In message [EMAIL PROTECTED], Bill
Studenmund writes:
Whew! That's reasuring. I agree there are things which need fixing. It'd
be nice if both NetBSD and FreeBSD could fix things in the same way.
Well, that still remains to be seen...
The use of the "vfs_default" to make unimplemented
Both struct timespec and struct timeval are major mistakes, they
make arithmetic on timestamps an expensive operation. Timestamps
should be stored as integers using an fix-point notations, for
instance 64bits with 32bit fractional seconds (the NTP timestamp),
or in the future 128/48.
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there
2. Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks, would we want to keep track both of
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made
In message [EMAIL PROTECTED], Terry Lambert writes:
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John Heidemann's
network proxy
On Wed, 18 Aug 1999, Terry Lambert wrote:
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same time. Otherwise, you just call VOP_LOCK
Terry,
It is very fine with this example, but I'm not even going to bother
much with it for several reasons, most of which you can find codified
in the development rules for X11 which you can find in Scheiflers
book.
But for the record: your example would get even shorter on
the code we had
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John Heidemann's
network proxy stacking layer (an NFS alternative), VOP's which
In message pine.sol.3.96.990816105106.27345h-100...@marcy.nas.nasa.gov, Bill
Studenmund writes:
On Sat, 14 Aug 1999, Terry Lambert wrote:
I am currently conducting a thorough study of the VFS subsystem
in preparation for an all-out effort to port SGI's XFS filesystem to
FreeBSD 4.x at such
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made the code
In message 199908181716.kaa12...@usr02.primenet.com, Terry Lambert writes:
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
In message pine.sol.3.96.990816105106.27345h-100...@marcy.nas.nasa.gov,
Bill
Studenmund writes:
On Sat, 14 Aug 1999, Terry Lambert wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can
In message pine.sol.3.96.990818101005.14430b-100...@marcy.nas.nasa.gov, Bill
Studenmund writes:
Whew! That's reasuring. I agree there are things which need fixing. It'd
be nice if both NetBSD and FreeBSD could fix things in the same way.
Well, that still remains to be seen...
The use of
Both struct timespec and struct timeval are major mistakes, they
make arithmetic on timestamps an expensive operation. Timestamps
should be stored as integers using an fix-point notations, for
instance 64bits with 32bit fractional seconds (the NTP timestamp),
or in the future 128/48.
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
In message pine.sol.3.96.990818101005.14430b-100...@marcy.nas.nasa.gov,
Bill Studenmund writes:
Whew! That's reasuring. I agree there are things which need fixing. It'd
be nice if both NetBSD and FreeBSD could fix things in the same way.
In message 199908181737.laa03...@mt.sri.com, Nate Williams writes:
Both struct timespec and struct timeval are major mistakes, they
make arithmetic on timestamps an expensive operation. Timestamps
should be stored as integers using an fix-point notations, for
instance 64bits with 32bit
In message pine.sol.3.96.990818104932.14430d-100...@marcy.nas.nasa.gov, Bill
Studenmund writes:
I doubt we need more than 64 bit times. 2^63 seconds works out to
292,279,025,208 years, or 292 (american) billion years. Current theories
put the age of the universe at I think 12 to 16 billion
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable resistance on its way into FreeBSD. I don't think
there is reason to rewrite it, but there certainly are areas
that need fixing.
You are
In message pine.bsf.3.95.990818105716.12306a-100...@current1.whistle.com,
Julian Elischer writes:
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his rewrite would face
considerable
2. Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks, would we want to keep track both of
:On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
:
: Matt doesn't represent the FreeBSD project, and even if he rewrites
: the VFS subsystem so he can understand it, his rewrite would face
: considerable resistance on its way into FreeBSD. I don't think
: there is reason to rewrite it, but there
The discussions between Kirk and matt over a glass of beer/drink
at kirk's party at USENIX and at the Bay area User's group.
On Wed, 18 Aug 1999, Nate Williams wrote:
Matt doesn't represent the FreeBSD project, and even if he rewrites
the VFS subsystem so he can understand it, his
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made
In message 199908181848.laa14...@usr02.primenet.com, Terry Lambert writes:
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John
On Wed, 18 Aug 1999, Terry Lambert wrote:
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same time.
On Wed, 18 Aug 1999, Poul-Henning Kamp wrote:
Yes, but we need subsecond in the filesystems. Think about make(1) on
a blinding fast machine...
Oh yes, I realize that. :-) It's just that I thought you were at one point
suggesting having 128 bits to the left of the decimal point (128 bits
worth
Right. That exported struct lock * makes locking down to the lowest-level
file easy - you just feed it to the lock manager, and you're locking the
same lock the lowest level fs uses. You then lock all vnodes stacked over
this one at the same time. Otherwise, you just call VOP_LOCK
You would have to de-collapse several VOP lists that have been
pre-collapsed.
You are talking gibberish here. Please show code where this is
a problem.
When you write a proxy stacking layer, such as John Heidemann's
network proxy stacking layer (an NFS alternative), VOP's which
Terry,
It is very fine with this example, but I'm not even going to bother
much with it for several reasons, most of which you can find codified
in the development rules for X11 which you can find in Scheiflers
book.
But for the record: your example would get even shorter on
the code we had
Terry,
It is very fine with this example, but I'm not even going to bother
much with it for several reasons, most of which you can find codified
in the development rules for X11 which you can find in Scheiflers
book.
But for the record: your example would get even shorter on
the code we
Terry Lambert wrote:
Make sure that the system you are talking to over the proxy is
not assumed to be a FreeBSD system (e.g. don't assume that the
vfs_default stuff exists on the other end of the proxy, or that
it would be functional).
Now, Terry, that is ridiculous. One has to assume that
On Tue, 17 Aug 1999 00:30:02 CST, Warner Losh wrote:
Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC.
!!!
I've been dethreading this subject line for a few days now, so I'm quite
relieved to see this, the one e-mail message which I happened to check in
on to make sure
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made the code a
--- Warner Losh [EMAIL PROTECTED] wrote:
In message
[EMAIL PROTECTED]
Brian McGroarty writes:
: So do the old and new Playstation models. The MIPS core is
: being manufactured by several companies: IDT alone has
: something like a dozen variants available with and without
: MMU, FP, 5000
On Tue, 17 Aug 1999, Bill Studenmund wrote:
I've compared the two, and making the NetBSD number match the FreeBSD
number is one of my goals. :-)
Any suggestions, or just plodfix?
It can be very cumbersome tracking down references being bumped by
vref/VREF and other operations.
Among the
On Tue, 17 Aug 1999, Terry Lambert wrote:
2.Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks,
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port BSD VFS Rewrite
} I don't see how the namei recursion method prevents catching // as a
} namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't inherit the fact that you
Don Lewis wrote:
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port BSD VFS Rewrite
} I don't see how the namei recursion method prevents catching // as a
} namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't
In message 19990816164048.28824.rocketm...@web1001.mail.yahoo.com
Brian McGroarty writes:
: So do the old and new Playstation models. The MIPS core is being
: manufactured by several companies: IDT alone has something like
: a dozen variants available with and without MMU, FP, 5000 vs
: 1
In message pine.bsf.3.96.990816201515.19879o-100...@haldjas.folklore.ee Narvi
writes:
: Nintendo 64 uses MIPS.
:
:
: Which doesn't matter all that much. MIPS cpus for nintendo could be made
: by say MISP, not SGI (and SGI sold/is trying to sell MIPS).
Acutally, the Nintendo 64 uses the
On Tue, 17 Aug 1999 00:30:02 CST, Warner Losh wrote:
Acutally, the Nintendo 64 uses the Vr4300 series of chips from NEC.
!!!
I've been dethreading this subject line for a few days now, so I'm quite
relieved to see this, the one e-mail message which I happened to check in
on to make sure that
I'm not familiar with the VFS_default stuff. All the vop_default_desc
routines in NetBSD point to error routines.
In FreeBSD, they now point to default routines that are *not* error
routines. This is the problem. I admit the change was very well
intentioned, since it made the code a
--- Warner Losh i...@village.org wrote:
In message
19990816164048.28824.rocketm...@web1001.mail.yahoo.com
Brian McGroarty writes:
: So do the old and new Playstation models. The MIPS core is
: being manufactured by several companies: IDT alone has
: something like a dozen variants available
On Tue, 17 Aug 1999, Michael Hancock wrote:
As I recall most of FBSD's default routines are also error routines, if
the exceptions were a problem it would would be trivial to fix.
I think fixing resource allocation/deallocation for things like vnodes,
cnbufs, and locks are a higher priority
On Tue, 17 Aug 1999, Bill Studenmund wrote:
I've compared the two, and making the NetBSD number match the FreeBSD
number is one of my goals. :-)
Any suggestions, or just plodfix?
It can be very cumbersome tracking down references being bumped by
vref/VREF and other operations.
Among the
On Tue, 17 Aug 1999, Terry Lambert wrote:
2.Advisory locks are hung off private backing objects.
I'm not sure. The struct lock * is only used by layered filesystems, so
they can keep track both of the underlying vnode lock, and if needed their
own vnode lock. For advisory locks,
Have you tried Heidemann's student's stacking layers? There is one
encryption, and one per-file compression with namespace hiding, that
I think it would be hard pressed to keep up with. But I'll give it
the benefit of the doubt. 8-).
Nope. The problem is that while stacking (null,
On Wed, 18 Aug 1999, Michael Hancock wrote:
Interesting, have you read the Heidemann paper that outlines a solution
that uses a cache manager?
You can probably find it somewhere here,
http://www.isi.edu/~johnh/SOFTWARE/UCLA_STACKING/
Nope. I've read his dissertation, and his discussion of
I forgot I had some old diffs that may be of help,
http://www.freebsd.org/~mch/vop1a.diff
You'll notice that just about everywhere that I moved vput() to the
appropriate layer a path component buffer was also freed in the wrong
place. John Dyson put these buffers in zones so the free routine
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port BSD VFS Rewrite
} I don't see how the namei recursion method prevents catching // as a
} namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't inherit the fact that you
Don Lewis wrote:
On Aug 16, 9:18pm, Terry Lambert wrote:
} Subject: Re: BSD XFS Port BSD VFS Rewrite
} I don't see how the namei recursion method prevents catching // as a
} namespace escape.
}
}
} //apple-resource-fork/intermediate_dir/some_other_dir/file_with_fork
}
} You can't
On Sat, Aug 14, 1999 at 12:23:00PM -0400, Brian F. Feldman wrote:
On Sat, 14 Aug 1999, James Howard wrote:
I heard somewhere that Linux was released under a slightly modified GPL to
permit the inclusion of BSD code. I assumed they did this to steal the IP
stack.
Most likely.
Nope.
On Fri, 13 Aug 1999, Terry Lambert wrote:
Has anyone mentioned to them that they will be unable to incorporate
changes made to the GPL'ed version of XFS back into the IRIX version
of XFS, without IRIX becoming GPL'ed?
Given that they say they're dropping IRIX and going with Linux, I
On Mon, 16 Aug 1999, Terry Lambert wrote:
On Fri, 13 Aug 1999, Terry Lambert wrote:
Has anyone mentioned to them that they will be unable to incorporate
changes made to the GPL'ed version of XFS back into the IRIX version
of XFS, without IRIX becoming GPL'ed?
Given that they
On Fri, 13 Aug 1999, Terry Lambert wrote:
Has anyone mentioned to them that they will be unable to incorporate
changes made to the GPL'ed version of XFS back into the IRIX version
of XFS, without IRIX becoming GPL'ed?
Given that they say they're dropping IRIX and going
On Mon, 16 Aug 1999, Terry Lambert wrote:
On Fri, 13 Aug 1999, Terry Lambert wrote:
Has anyone mentioned to them that they will be unable to incorporate
changes made to the GPL'ed version of XFS back into the IRIX version
of XFS, without IRIX becoming GPL'ed?
--- Terry Lambert [EMAIL PROTECTED] wrote:
On Fri, 13 Aug 1999, Terry Lambert wrote:
Can you please site a reference for this, other than
wishful
thinking by the Linux camp?
Here's one:
http://www.zdnet.com/pcweek/stories/news/0,4153,1015908,00.html
But just about
I lost track of the quotes.
| --- With the help of Veritas Software Corp., SGI will work to add
| key features of its Irix operating system to the Linux platform.
| Currently, Irix runs on the MIPS platform. Once SGI switches
| entirely to Intel Corp.'s IA/64 platform, that will be the
I lost track of the quotes.
| --- With the help of Veritas Software Corp., SGI will work to add
| key features of its Irix operating system to the Linux platform.
| Currently, Irix runs on the MIPS platform. Once SGI switches
| entirely to Intel Corp.'s IA/64 platform, that will
These paragraphs are contradictory. It implies an end to MIPS.
Nintendo 64 uses MIPS.
It also seems a bit overzealous.
No argument here. Perhaps they're just trying to float a few trial
baloons in hopes of finding something popular/feasable.
That was my take on things, since
On Mon, 16 Aug 1999, Terry Lambert wrote:
On Fri, 13 Aug 1999, Terry Lambert wrote:
Has anyone mentioned to them that they will be unable to incorporate
changes made to the GPL'ed version of XFS back into the IRIX version
of XFS, without IRIX becoming GPL'ed?
1 - 100 of 191 matches
Mail list logo
