On Sun, Sep 23, 2007 at 04:51:15PM -0400, Hector Martin wrote:
quoted text
> I see several options for implementing this:
> - Add support to the standard FAT driver. This should probably be made a
> configurable suboption.
> - Add support that piggybacks onto the standard FAT driver, but
> otherwise doesn't touch it. I don't know how feasible this is.
> - Modify the FAT driver to allow the basic changes needed to support
> FATX, then piggyback it for the actual implementation. See above.
> - Fork the FAT driver and make it into a FATX driver.
> - Start from scratch.
> 
> I'm unsure about what the best option would be. Obviously changes to FAT
> should be made with care, as we don't want to cause a regression.
> However, much of the code (allocation strategies, FAT handling, etc)
> should be the same or very similar, so it seems stupid to start from
> scratch.

I'd start with modifying the existing FAT driver.  Once you have working
code you can look at the amount of changes and decided if you want to
add support to the existing driver or fork it.  If you think you can't
just judge it by yourself send your prototype to lkml or -fsdevel for
an rfc so we can look over it and guide you a little on how to do it.
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/