[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
UniFS
Here's a weird idea. How about combining ramfs with Unifs? That way the
Unified file system could store files like a real filesystem?
Or perhaps add a command to MiNT.CNF that would allow writes to U: to be
redirected to some other path? So that it would show up in U:\ but get stored
elsewhere?
If the DIRSEP #define is changed to an OR conditional, like :
#define DIRSEP(p) (((p) == '\\') || ((p) == '/'))
then, what else would be required to use a Unix path separator in system
calls?
Would cach'ing fs->lookup provide much of a speed advantage? Some people
were talking about putting a "cookie cache" into MiNT and it wouldn't be
very hard (assuming that you don't have to release a cookie back to the
filesystem immediately, and you can let the cache keep it for awhile without
hurting something) then it should be pretty straightforward. Say, an array
of 32 cookies to cache? I've already worked out a way to do it and I'll
hack it in this weekend and see if it makes much of a difference, but I
don't think there will be much improvement.
Oh .. I think TOSWIN has a really BAD memory leak. For some reason, when I
do a PS or a TOP, MiNT increasing has more and more memory, until it gets
over 2 MB and I have to reboot. I first thought it was tfork, but I used
that directly from a shell quite a bit and there was no problem, but under
TOSWIN memory use skyrockets! It seems to be a combination of tfork and
toswin though as tfork'd processes grow huge when running and only the original
memory is free'd and returned to the system, the rest is "owned" by pid 00.
Anyone working on unblocking Pfork() or Pvfork() ??
- Follow-Ups:
- Re: UniFS
- From: Chris Herborth <herborth@53iss6.waterloo.ncr.com>