Re: [MiNT] FreeMiNT & MiNTlib patchset - add new support

[Alan Hourihane <alanh@fairlite.co.uk>]

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.