Re: 1.15 kernel ;-)

[Konrad Kokoszkiewicz <draco@mi.com.pl>]

> wouldn't it make sense to put the new TOSFS stuff into an (separately
> loaded) XFS module? Thar way, we could separate MiNT kernel and FS
> changes.

Well, the newfatfs is supposed to replace the old TOS FS completely, so it
will need to be integrated anyways...

> Related to that: we recently found that the kernel still uses the BIOS
> function Mediach() in filesys.c. This is a Very Bad Thing, as a file
> system
> might not have any BIOS support at all. The kernel itself should only
> use
> the functions exported by the filesystem drivers, and tosfs.c (and
> similar
> file systems) should *then* call Mediach() where appropriate.
> 
> I'm not sure whether the current disk change call in the filesystem
> already
> supports this semantics, but we sure need something like this. I would
> be
> willing to work on this -- however I currently have no working gcc setup
> here
> (due to lack of time).

Any fixes are welcome and I am glad you want to fix the Mediach() usage.
Well, as for the time... it is no hurry, we'll work on the new kernel yet
some time.

BTW. I always had troubles understanding why there are so many problems
with floppy disk change (or media change in general, but it beats me
considering floppies) on ST/TT/Falcons. Is there any reason for not using
the most simple solution, as re-reading the bootblock and updating the
internal filesystem data strucres accordingly (like clearing FAT or inode
caches for example), if the bootblock differs from what was read before?

Actually, any disk operation, like opening a file for read/write/update or
reading directories could cause bootblock to be re-read by the system. 
Then we have the serial number there, the volume name and the number of
free clusters to check if the diskette is still the same. Perhaps it will
slow the file opening down a bit, but at least would solve the floppy
change problem and would prevent the user/operator from bitching while
Minix filesystem doesn't want to read new directory from a changed floppy
disk.

As for possible slow down, I don't think it would be detrimental. Just:

a) floppies aren't the main storage media anymore (harddisks are)
b) this perfectly works for SpartaDOS on 8-bit Atari, though XL serial
   drives are 10 times slower than our floppy drives. I have no reason
   to not using a working solution from 8-bit computers, if such a
   solution works.

--
Konrad M.Kokoszkiewicz
|mail: draco@mi.com.pl                  | Atari Falcon030/TT030/65XE |
|http://www.orient.uw.edu.pl/~conradus/ |  *** FreeMiNT 1.14.8. ***  |

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** U pospolstwa normalne jest, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.