[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FS types



Hi Frank etc,

this is not yet a proposal, but at least a summary of what exists
and what I find is needed (or let's say would be useful).


1. MagiC

MagiC has a specific Dcntl (MGX_KER_XFSNAME, 0x6d05) which returns
an 8 character file system name. Note that this is the *name* of
the XFS, not the type. MagiC takes this information out of it's
internal XFS structure, so it's nearly invisible for the XFS.
Obviously it could be implemented differently in MiNT, like letting
the specific MiNT XFS handle this in the fscntl function. In fact,
I already do this in my current beta version of SPIN.

I must say that I like this Dcntl, because it returns something 
different from what you propose. In some cases, you really want
to know *who* is handling a filesystem, not the type of the filesystem.
That's why I would propose to support this Dcntl opcode everywhere.


2. Minix-FS

The MFS_INFO call you changed seems to be a bit Minix-FS specific.
I don't think that we should extend something that was invented
for a specific fs type and extend it to everything. Besides, this
Dcntl opcode overlaps with the old MagiC's KER_DRVSTAT, so it's
not a good idea to call it unless you are sure not to be running
under MagiC. And what we want are less special cases, not more.


3. Information I would like to see in a new Dcntl opcode

- Name of the XFS (see 1) in ASCII.

- Type of the filesystem. This should be something like a pair
  of two longs, one for the generic type, one for special information.
  Obviously, some fs types would need to be predefined.

  Some cases where I'd like to see this more structured information
  are the different flavors of FAT you already mentioned, or the
  different things one can find on a ISO9660 fs (long names,
  Rockridge extensions, Joliet extensions) etc.

- And then probably some more ASCII fields containing a printable
  string which describes the filesystem (like "ISO9660/Joliet"
  or "VFAT32"). This would be used by tools like "df".

- Maybe some version numbering.


4. Proposal

Frank should make a proposal for a new Dcntl opcode and post
it to the list. Maybe Andreas Kromke has also some ideas, he
is getting this mail as well.

Frank is the ideal candidate to work on this, because he can
change the kernel, Minix-FS and the new FATFS to support it. I surely
will support whatever we define in the end in SPIN and in ISO9660F.DOS.


5. Related

Talking about "df": it would be useful if there were a Dcntl which
allows
to get at the mount point information. As MFS mounting currently seems
to be a hack, I don't think we currently need to define something for
"all" filesystems.

Besides, I really don't understand why Minix-FS does this remapping of
the mounted device's root to the root of the device it's mounted on.
This is very confusing and maybe could be changed.



That's it, let's discuss :-)