I don't see where we need multitasking for NAS use. A program could be
made to both handle incoming requests while serving data and doing other
tasks, eliminating the need for a proper multitasking kernel. Even if
that was the case, the bloat of the Linux kernel would make it
prohibitive in certain applications. Sure, you could compile your own
slimmed version specific for the task, but DOS' lightweight requirements
and comparatively speediness make it the clear out-of-the-box winner.
An improved FAT was something I planned for eventual use with the 32-bit
kernel we're creating. Perhaps it's best to keep it that way since
regular DOS (as Eric points out) is not that well suited for the job
being sans-multitasking as it is.
I will draw up a spec as I said when I get the time. After that,
implementation is up to the rest of the community. We could just as
easily go with FAT+ or not advance the filesystem at all.
On 9/24/2015 9:21 PM, JAYDEN CHARBONNEAU wrote:
First thing I noticed (This may be just me.),is that we need more
memory for the OS environment.Normally,when I boot FreeDOS on ANY
computer (Be it modern or old),the memory is always 601 MB free.More
memory would be needed for a bigger file system and multi-tasking.
On Thu, Sep 24, 2015 at 5:54 PM, Eric Auer <e.a...@jpberlin.de
<mailto:e.a...@jpberlin.de>> wrote:
Hi Mercury,
so you want to run a NAS or home automation on DOS?
For NAS, you need a multitasking OS, not DOS. For
home automation, which limitation of FAT would be
a problem? Same for other light embedded devices.
Flash does not give good performance for FAT, but
embedded devices would have been free to use one
of many available Linux filesystems. But did not.
Of course the question can be extended: What if an
existing nicer-than-FAT filesystem is used more in
DOS? Have a look at what already EXISTS for Linux,
then have a look at the source code to check which
filesystems are 1. simple enough to make a "light"
DOS driver possible (some might even be so simple
that booting DOS from them is feasible, but only a
really popular filesystem may get kernel drivers),
2. better than FAT in some way (e.g. more speed on
flash storage, better space allocation or LFN in a
less insane way than VFAT) but 3. not putting lots
of code into features which mean nothing for DOS,
such as ACL based file permissions or extreme file
or disk size support beyond existing FAT32 API or
"network redirector" API expressible number range.
Looking forward to your review of existing FS-es!
Of course with an outlook towards which properties
a not-yet-existing FS could have to be even nicer
for use within a DOS based storage "ecosystem".
Cheers, Eric
PS: By "light", I mean a driver which is not 100s
of kilobytes in size and which can be fast with a
bit of DOS RAM and XMS instead of needing 500 MB
of DPMI RAM and protected mode implementation :-)
> NAS devices, home automation computers and other similar devices are
> becoming increasingly common, and offering a filesystem finally
capable
> of handling the sizes of modern hard drives could be a welcome
> improvement for them, and just may help get FreeDOS used in a
wider market.
>
> How do we know this isn't a chicken-and-egg problem? Maybe all the
> devices only use the proprietary exFAT because there was no open
> alternative. Maybe, had there been one available, we would all...
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
<mailto:Freedos-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freedos-devel
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
------------------------------------------------------------------------------
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
