> > It would be nice though if you could follow the usual phase-out
> > procedure: flag it as obsolete and printk a warning, then remove it
> > and printk an explanation, and finally remove the explanation.
>
> It's a bit late for that - we could do it in 2.1 easily, but now... FAT is
> already broken ;-/
Kill it for 2.3 and have people cast around to see if they have anything that
depended on it. I can't imagine there is anything, but if it turns out it's
a problem we can stick it back for 2.4.
> * support for FAT on normal devices (with 512-byte sectors) can
> be restored fast. Devices with the large sectors (e.g. ZIP drives) are
> trickier, but doable. Support for dmsdos... Hell knows. *Probably* it can
> be done, but it will be tricky. OTOH dmsdos will need rewrite anyway.
Did you give any thought to my NTFS problem (did I even tell you about it)?
The problem is the FILE records can span multiple blocks and I want to avoid
the kmalloc, memcpy stuff that the driver currently does. The buffer cache
doesn't (AFAICS) cope with reading chunks that are multiples of the block
size ATM, 'cos it ain't needed for normal filesystems.
-- No good deed goes unpunished.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/