[MiNT] unifs and related changes?

[Standa Opichal <opichals@seznam.cz>]

Hi kernel hackers!

I've been hacking the unifs recently. I would like to propose some changes 
to the 1.16 line regarding this and its GEMDOS integration.
As it is now there are several default mountpoints made by the fatfs, 
minix or ext2 drivers in the U: root directory (and several others like 
e.g. pipe, kern etc.).

Basically I would like to change the way the e.g. G:\ maps to the U:\g 
(/g/). I would like to have it a bit more flexible.

For example:

Suppose the fatfs, ext2 and minix would mount to the new u:\gemdos 
filesystem which would be the one serving the GEMDOS compatible drive 
device numbers (0-31). This would look like:

U:\gemdos\a (FAT)          (devno e.g. starting from 64)
U:\gemdos\c (FAT)          (dtto 66)
U:\gemdos\d (e.g. ext2)    (dtto 67)
U:\gemdos\e (e.g. minix... or whatever...)

Than there would be the symlinks (or some other kind of link) like:

U:\a -> gemdos\a
U:\c -> gemdos\c
U:\d -> gemdos\d
U:\e -> gemdos\e

And the meaning of GEMDOS C:\ would behave just like the U:\c. In this 
case it would be mapped to the HDD fatfs, minixfs, ext2fs mount point.
For this the unifs would handle the devno 0-31 and map them to the correct 
mountpoint device numbers (like 66 in this case for the gemdos\c).

With this scheme it would be possible to change (by a simple /here a 
bit special ... but not visible for the user/ symlink change) the mapping 
of the logical GEMDOS drives to appropriate physical driver. Also the A: 
-> U:\gemdos\c might be a cool thing for tests.. ;)

The other thing I have in mind that I would like to have the possibility 
to wrap the driver for a specific GEMDOS drive with some other filesystem 
driver that would redirect the actual access where it thinks it is 
appropriate.

The best thing on this all is that I'm ready to do all the necessary 
changes withing the CVS. I just want to know if there are some problems 
that I'm not aware yet that would make the whole effort useless.
The next good thing is that I think it might help the unifs code be 
polished and the responsibilities might be more separate there.

Any objections or better ideas?

best regards

STan