From mint-bounce@lists.fishpool.fi Wed Aug 20 06:18:06 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> Content-Type: text/plain Date: Wed, 20 Aug 2008 11:12:48 +0100 Message-Id: <1219227168.15620.9.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:00 +0200, Frank Naumann wrote: > Hello! > > >>>> This avoid any modification on the xfs, we don't have any compatibility > >>>> problems and the directories are handled generically inside the kernel. > >>> > >>> Without adding a new flag to the XFS module to detect an older XFS, I'm > >>> not sure how adding additional checks for EISDIR into the kernel > >>> filesystem layer can help. > >> > >> If you can move the two modifications inside the xfs into the upper layer > >> you don't need to modify the xfs at all. I think that's much better. > > > > I still dont understand how you can do this. > > > > The kernel is allowing read-only directories through to the XFS. > > > > How is the filesystem layer meant to know to refuse that with an older > > XFS ?? > > You don't get my idea. If you don't modify the xfs at all there exist no > "old" or "new" xfs, they are untouched and thus no compatibility issue. > > You only need to handle these two things inside Fopen() and Fread(). O.k. Now I understand. We need to get the attributes and do the right thing. I'll fix this then. > I also thought a little bit about this. I'm sure I already mentioned this > ealier, but if you really allow and pass down FILEPTR of directories down > to the xfs all xfs dev functions need to be checked to work correctly on > such directories (e.g. xfs_lseek, xfs_ioctl, xfs_datime). > > That's another reason to don't touch the xfs at all and catch and handle > directories generically at the filesystem level (where the kernel have > control and know how to handle directories; also you only have the code > once; the code will be identically inside each xfs). > > In summary: > > dirs handled at xfs level (looks maybe simpler, but): > - you need to modify each xfs, effectivly duplicating the > code (as the directory handling is the same, there is no > filesystem specific code involved (or I overseen something)) But it's wise to catch high level troubles. > - duplicating code is a very bad idea, a source of errors > specially if you modify or change something (you need to change > in several places the same thing); following murphy you always > forget something ;-) Sure. But sometimes it's a necessity, because the XFS drivers have different semantics. > - you have a big compatibility problem; the kernel is not prepared to > check for a specific xfs version or compatibility level; the interface > is only designed to allow the xfs to check kernel features > -> you need to completely overwork the module loading strategy > (and I think we need a good reason for this, it's lot of work) Sure. I understand your point above now. > - your existing xfs modifications are not enough I think; you need > additionaly to check and/or modify the other xfs-dev functions too > - and finally you need to test all this for each xfs seperately (and again > for each modification) O.k. ignore the patches. I'll do some more work on them. Alan.