Hello from the Eighth Doctor
Has anyone decided to accept the challenge of maintaining umsdos for the 2.6.x
series? The last I had heard was that it was not going to be maintained. And that it
was, ah, "broken!".
------
Gregg drwho8 atsign att dot net
"This signature is wandering in the Tatooine desert wastelands, and is loving it."

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Eighth Doctor wrote:
> Hello from the Eighth Doctor
> Has anyone decided to accept the challenge of maintaining umsdos for the 2.6.x
> series? The last I had heard was that it was not going to be maintained. And that it
> was, ah, "broken!".

I haven't heard of anyone taking up that challange.

IMHO,umsdos is no longer a necessary filesystem because of vfat, loop
filesystem, and initrd pivot support.

The umsdos fs was originally developed to provide a filesystem that
would provide for unixish long filenames and permissionbits on top of
the MSDOS filesystem. This permitted a Linux system to boot and run from
a completely MSDOS filesystem, and to save files to that filesystem.
Well, this can now be accomplished through the use of a loop filesystem
(say, and ext2 filesystem stored as file on an MSDOS filesystem). With
intrd and pivot support, this loop filesystem can even be inhereted as
the 'root' filesystem of a booted Linux OS.

The other use for umsdos was to provide for unixish (long) filenames on
the 8.3 MSDOS filesystem. This functionality was supplanted by the vfat
support of the extended MSDOS filesystem that Windows uses, which also
provides for unixish (long) filenames.

So, given that the two primary uses of umsdos are also handled by other
MSDOS-compatable filesystems, and that the MSDOS filesystem itself is
slowly going away (being replaced by NTFS and it's family), I can
understand the lack of ongoing support for the umsdos filesystem code,
and the reluctance of the kernel developers to keep it part of the
mainline kernel.


- --

Lew Pitcher, IT Consultant, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFB5SnGagVFX4UWr64RAi+EAJ4+209TiU+SWgZCwfSpen ocj2Zd3gCgp2gK
ZxgCs0McUFpftnv4Y+f1I24=
=HxG7
-----END PGP SIGNATURE-----

Lew Pitcher wrote:

>
> So, given that the two primary uses of umsdos are also handled by other
> MSDOS-compatable filesystems, and that the MSDOS filesystem itself is
> slowly going away (being replaced by NTFS and it's family), I can
> understand the lack of ongoing support for the umsdos filesystem code,
> and the reluctance of the kernel developers to keep it part of the
> mainline kernel.

I think Runt and Zipslack use UMSDOS?


--
http://www.petezilla.co.uk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Chant wrote:
> Lew Pitcher wrote:
>
>
>>So, given that the two primary uses of umsdos are also handled by other
>>MSDOS-compatable filesystems, and that the MSDOS filesystem itself is
>>slowly going away (being replaced by NTFS and it's family), I can
>>understand the lack of ongoing support for the umsdos filesystem code,
>>and the reluctance of the kernel developers to keep it part of the
>>mainline kernel.
>
>
> I think Runt and Zipslack use UMSDOS?

I don't know "Runt", but IIRC Zipslack does use UMSDOS. Pat will soon have to
address how he is going to package Zipslack for the 2.6 kernel (say in Slackware
11.0 or 11.1) because of the level of UMSDOS support in the Linux 2.6 kernel.


- --
Lew Pitcher
IT Consultant, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFB9RDRagVFX4UWr64RAqn2AKCKXvIe/6hPcVu+0PMvOFBE45Xk0QCeN7fv
3M4S+iJL+JewyD+PfVA+u7Q=
=AKap
-----END PGP SIGNATURE-----