[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FS types
fnaumann@mail.CS.Uni-Magdeburg.De%INTERNET wrote:
> > 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.
>
> Ok, defined Dcntl's are:
>
> > Filesystem installation (MiNT)
> >
> > 0xf0 1 FS_INSTALL mint/file.h
> > 0xf0 2 FS_MOUNT mint/file.h
> > 0xf0 3 FS_UNMOUNT mint/file.h
> > 0xf0 4 FS_UNINSTALL mint/file.h
>
> So I mean it's logical to use:
>
> Filesystem information (MiNT/MagiC)
>
> 0xf1 1 FS_NAME (write the name of the xfs)
> 0xf1 2 FS_VERSION (write major/minor version)
> 0xf1 3 FS_TYPE (write major/minor type of fs on drv)
> 0xf1 4 FS_TYPE_ASC (write a human readable version of FS_TYPE)
FS_NAME should and could be kept identical to the call that exists
already
in MagiC.
The other three opcodes could be combined in one call filling a
struct. The lenght of the string returned by FS_TYPE_ASC needs to
be restricted to some sane value (24)?
>
> and, for discussion:
>
> FS_EJECT/FS_STOP/FS_LOCK (mapped to XHDI _for example_ (if available))
> (-> kernel can look devices with opened files)
Thid would duplicate the same fscntl codes for CDROMs. I think
we should reuse them. MagiCMac does this for floppies, for example.
Regards, jr
- References:
- Re: FS types
- From: Frank Naumann <fnaumann@prinz-atm.cs.Uni-Magdeburg.DE>