Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset

[Charles Manning]

Chrisoph

On Wednesday 16 February 2011 21:04:20 Christoph Hellwig wrote:
> On Thu, Feb 10, 2011 at 07:22:47AM +1300, Charles Manning wrote:
> > Can you be a bit more specific?
>
> Just compare the mes in yaffs_linux.c with a normal linux filesystem.
> All that gross magic nfsd detection in readdir could have been removed
> long ago.  ->readlink should not be implemented by a normal filesystem
> but use generic_readlink,

Fair comment. I'm sure there are better ways to handle that.

> the fs-specific inode should embedd the vfs 
> inode instead of requiring two allocations,

The approach used here significantly reduces memory footprint. 
The yaffs inodes (== yaffs objects) live all the time while the vfs inodes 
come and go. It is far better to just link these together when in use.

> tons of useless function 
> pointer indirections like sb_dirty_fn and the put_super_fn really must
> go away.  

Ok.

> The procfs interfaces should be replaced by something saner, 
> the insane amount of ad-hoc tracing crap should be replaced by much
> less strategically placed trace events, and all those stupid compile
> time options have absolutely no business at all beeing there for a
> filesystem - 

Why not?

> remember you can get media from all over the place. 

No you can't. This is a flash file system for soldered down flash. I think 
that is a fundamental place where your understanding of what yaffs is falls 
down.

> If you can't encode these difference in your on-disk format it has
> absolutely no business going into mainline with this format.

Yaffs does not really have an on-disk format like most other fs do.

> And last but not least there's no way we'll merge a filesystem with a
> global mutex and all kinds of hacky release and reaquire semantics
> these days. 

I could change the locking but that would require considerable work.

> I really think you need to get back to the drawing board. 

I'm starting to think that the distance from where yaffs is now to what people 
will accept into the kernel tree might be quite large.

I might just be easier to walk away from the mainlining effort. Yaffs is a 
highly successful and useful fs and very easy to patch in to a kernel. People 
could continue to use it that way as they have for the last 9 ears or so.

-- Charles



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/