View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=769398
*Status : closed Priority : 1
Assigned Engineer : cattelan Submitter : mostek
Opened Date : 10/04/99 *Closed Date : 06/28/00
*Fixed By : lord *Fixed By Domain : sgi.com
*Modified Date : 06/28/00 *Modified User : lord
*Modified User Domain : sgi.com *Fix Description :
==========================
ADDITIONAL INFORMATION (CLOSE)
From: lord@xxxxxxx (BWX)
Date: Jun 28 2000 08:08:50AM
==========================
Closing PVs which were fixed in the XFS linux port a long time
ago.
Description :
linux/xfs_vnode.c is way out of date from IRIX. This might
be OK, but... xfs_vnode.c should be compared with the latest version
on IRIX and any changes needed should be stitched into the one
on Linux. On the other hand, the Linux xfs_vnode.c could be
much simpler. This task is here to study the situation and
analyze what is really needed from xfs_vnode.c
I noticed that NESTED_LOCK_VFP is defined but never
used. I am not currently implementing this as part of the lock
work. If we need a nested spinlock more work is needed
.....
==========================
ADDITIONAL INFORMATION (ADD)
From: russell cattelan <cattelan@xxxxxxxxxxx>
Date: Oct 11 1999 10:50:07AM
[pvnews version: 1.71]
==========================
--------------591C48B29E2E6F2EA4188DAE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"casey@engr" wrote:
> Submitter : mostek Status : open
> Assigned Engineer : cattelan Priority : 1
> *Modified Date : 10/11/99 *Modified User : casey
> *Modified User Domain : engr
>
> *Description :
>
> linux/xfs_vnode.c is way out of date from IRIX. This might
> be OK, but... xfs_vnode.c should be compared with the latest version
> on IRIX and any changes needed should be stitched into the one
> on Linux. On the other hand, the Linux xfs_vnode.c could be
> much simpler. This task is here to study the situation and
>
> .....
>
> ==========================
> ADDITIONAL INFORMATION (ADD)
> From: casey schaufler <casey@xxxxxxx>
> Date: Oct 11 1999 10:20:05AM
> [pvnews version: 1.71]
> ==========================
> mostek@xxxxxxx wrote:
> >
> > View Incident:
> > http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=769398
> >
> > Submitter : mostek Submitter Domain : sgi.com
> > Assigned Engineer : cattelan Assigned Domain : engr
> > Assigned Group : xfs-linux Category : software
> > Customer Reported : F Priority : 1
> > Project : xfs-linux Status : open
> > Description :
> > linux/xfs_vnode.c is way out of date from IRIX. This might
> > be OK, but... xfs_vnode.c should be compared with the latest version
> > on IRIX and any changes needed should be stitched into the one
> > on Linux. On the other hand, the Linux xfs_vnode.c could be
> > much simpler. This task is here to study the situation and
> > analyze what is really needed from xfs_vnode.c
>
> Just curious as to why the Linux xfs_vnode.c ought to be simpler
> than its Irix counterpart.
It is unclear exactly how we are or are not going to keep vnodes around.
Lunix's vnode (which called an inode) should be able to do most of the
caching and list management that the irix vnode.c stuff would do.
We need enough of vnode.c to keep the xfs code the same.
This specific area is under a lot of discussion due to AT&T licensing issues.
>
>
> --
>
> Casey Schaufler voice: (650) 933-1634
> casey@xxxxxxx fax: (650) 933-0170
--------------591C48B29E2E6F2EA4188DAE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
"casey@engr" wrote:
<blockquote TYPE=CITE> Submitter :
mostek
Status : open
<br> Assigned Engineer :
cattelan
Priority : 1
<br>*Modified Date :
10/11/99
*Modified User : casey
<br>*Modified User Domain : engr
<p>*Description :
<p>linux/xfs_vnode.c is way out of date from IRIX. This might
<br>be OK, but... xfs_vnode.c should be compared with the latest version
<br>on IRIX and any changes needed should be stitched into the one
<br>on Linux. On the other hand, the Linux xfs_vnode.c could be
<br>much simpler. This task is here to study the situation and
<p>.....
<p>==========================
<br>ADDITIONAL INFORMATION (ADD)
<br>From: casey schaufler <casey@xxxxxxx>
<br>Date: Oct 11 1999 10:20:05AM
<br>[pvnews version: 1.71]
<br>==========================
<br>mostek@xxxxxxx wrote:
<br>>
<br>> View Incident: <a
href="http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=769398";>http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=769398</a>
<br>>
<br>> Submitter :
mostek
Submitter Domain : sgi.com
<br>> Assigned Engineer :
cattelan
Assigned Domain : engr
<br>> Assigned Group :
xfs-linux
Category : software
<br>> Customer Reported :
F
Priority : 1
<br>> Project :
xfs-linux
Status : open
<br>> Description :
<br>> linux/xfs_vnode.c is way out of date from IRIX. This might
<br>> be OK, but... xfs_vnode.c should be compared with the latest version
<br>> on IRIX and any changes needed should be stitched into the one
<br>> on Linux. On the other hand, the Linux xfs_vnode.c could be
<br>> much simpler. This task is here to study the situation and
<br>> analyze what is really needed from xfs_vnode.c
<p>Just curious as to why the Linux xfs_vnode.c ought to be simpler
<br>than its Irix counterpart.</blockquote>
It is unclear exactly how we are or are not going to keep vnodes around.
<br>Lunix's vnode (which called an inode) should be able to do most of
the
<br>caching and list management that the irix vnode.c stuff would do.
<p>We need enough of vnode.c to keep the xfs code the same.
<br>This specific area is under a lot of discussion due to AT&T licensing
issues.
<blockquote TYPE=CITE>
<p>--
<p>Casey
Schaufler
voice: (650) 933-1634
<br>casey@xxxxxxx
fax: (650) 933-0170</blockquote>
</html>
--------------591C48B29E2E6F2EA4188DAE--
|