On Thu, 15 Jul 1999, Jamie Lokier wrote:
> > [CRLF conversion] My vote is to kill that feature in 2.3 and retroactively
> > add a warning to 2.2.11.
>
> FWIW my vote is to kill CRLF conversion too.
Sound reasonable.
OK, folks. Methink I see how to do it. It has the benefit of keeping dmsdos
alive, BTW.
a) CVF interface becomes splitted into several independent parts.
BTW, some of the functions simply go away.
b) Normal path in fat_bread(), etc. is taken out into separate
functions. Which form the *default* cvf_format. fat_bread() et. al. become
the plain calls of MSDOS_SB(sb)->cvf_format->cvf_bread, etc. Inlined ones.
It will actually speed the things up compared to the current variant
(well, 2.2 one ;-)
c) Moreover, normal and bigblock versions should be separated.
Ditto for FAT-12 vs. FAT-16 vs. FAT-32 in case of fat_access(), etc.
That's why I think that splitting the interface is a good idea - there are
several independent sets of methods.
d) ->smap() probably should go away. Talk about the cruft... Guys,
->smap() appeared in the main kernel in 1.1.35 since the block size on FAT
was hardwired to 1k back then. In 1.1.60 it was changed to 512. No bloody
need to use ->smap() on normal devices. And devices with bigger sectors
seem to be b0rken anyway - I suspect that attempt to use swapfile on
UMSDOS fs sitting on ZIP drive will give a major screwup.
e) order of fixing: first of all, non-compressed FAT on devices
with 512-byte sectors, then bigblock stuff, then dmsdos.
WARNING: if somebody works on CVF modules (aside of dmsdos,
that is) - please, let me know. Interface changes are going to happen.
Cheers,
Al
-
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/