From mint-bounce@lists.fishpool.fi Wed Aug 20 06:47:00 2008 X-Virus-Scanned: amavisd-new at demon.co.uk Subject: Re: [MiNT] FreeMiNT & MiNTlib patchset - add new support From: Alan Hourihane To: Frank Naumann Cc: mint In-Reply-To: References: <1214745779.28954.415.camel@jetpack.demon.co.uk> <1219148919.28716.28.camel@jetpack> <1219218974.15039.2.camel@jetpack> <1219219385.15039.7.camel@jetpack> <1219222338.15039.10.camel@jetpack> <1219223882.15039.13.camel@jetpack> <1219227750.15620.13.camel@jetpack> Content-Type: text/plain Date: Wed, 20 Aug 2008 11:41:41 +0100 Message-Id: <1219228901.15620.18.camel@jetpack> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: alanh@fairlite.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Wed, 2008-08-20 at 12:39 +0200, Frank Naumann wrote: > Hello! > > > Actually, now I remembered why I didn't do it this way. > > > > We add additional xfs_getxattr() call on every read/write/lseek/etc to > > obtain the attributes to determine whether it's a directory or not, > > which I'm not sure how much slowdown that can cause for normal > > operations. > > > > By letting it hit the filesystem, that data is already known. > > That's a good point. But I think, getxattr is an optimized routine inside > the xfs anyway. > > Beside from that we can introduce a new flag to remember that the > FILEPTR is associated to a directory (f->flags). Or, if flags is not so > good, we can introduce a new struct member at the end of the FILEPTR (this > don't have side effects to the xfs). I'll do some more work around this. For the other xfs_* calls such as lseek,datime,ioctl etc, most of them are already dealt with as they check for read-only status anyway. But I'll go through the others to double check and write some test programs. Alan.