On Sun, May 19, 2013 at 7:06 PM, Eric Auer <e.a...@jpberlin.de> wrote:
>
> Hi Louis,
>
> sort of a long response - it seems hard to make a short point here:
>
> > FreeDOS Roadmap, as goals and stretch goals for the project. I read
> > (paraphrasing): built-in networking, built-in USB, integrated DPMI,
> 32-bit
>
> The fd32 project works or worked on the DPMI aspect. As far as I
> remember, the performance gain was minimal, but consider interest
> in terms of style to consider a protected mode kernel which has
> both DPMI and VM86 visibility. It would be a sort of DOSBOX then.
>
I would expect performance gain to be minimal. Maybe there could be
Low/HMA/UMB memory savings with a different architecture. Hard to say.
> Regarding built-in networking and USB, I am personally more for
> the existing loadable driver model. The BIOS gives you enough
> support to reach the point where you can load drivers in config
> sys. Even when booting via network (PXE) or from CD/DVD/BD, you
> can still use a MEMDISK (bootable ramdisk) to get started...
>
I lean this way too w/respect to drivers. Built-in's biggest advantage is
simplicity in user configuration. However, networking seems to be lacking
throughput speed with either mTCP or Watt32 apps. I'm not sure if it's a
packet driver, TCP/IP stack, app (doubt), or kernel (doubt) issue. My
guess is that it's a 16-bit MOV/LD* loops, the lack of zero-copy
networking, and the switch between kernel and app. I've seen some
reference to the same issue on USB drivers as well (USB 1.1 speed from USB
2.0 devices or 3.0 devices). And there seems to be 3 ways to get USB
working on DOS: USBDOS, DOSUSB, Panasonic/ASPI Method. I need to play with
those.
> On the other hand, I think it would be an interesting experiment
> to have a kernel which can load files from at least the root dir
> of ISO9660 or UDF disks and similar (ext2? ntfs?) and which can
> directly interpret GPT partition tables. The latter would have
> significant practical use. Not the former: When you boot from
> CD/DVD/BD, you do typically want a writeable ramdisk anyway, so
> you can just as well boot with the help of a MEMDISK which lets
> you load DOS CD/... drivers from there, making drivers for that
> as fixed parts of the kernel less interesting. Also, they are
> harder to update than separate drivers and you cannot easily
> skip them at boot to save DOS memory.
>
Yes! I agree! The FD Kernel needs to speak MBR, GPT, ISO9660 & UDF
(including El Torito), NTFS, Ext2/3/4 to stay relevant. Probably HFS+ as
well. Linux and/or FUSE should be helpful here.
> Good question whether you want built-in USB: I would say no, you
> already need the BIOS to help to boot from USB. After that, you
> want a modular system of USB drivers (unless the BIOS provides
> support for all relevant USB devices) to let you access disks,
> sticks, mice, keyboards and so on. Also, devices for which there
>
I'd want FD to be USB-ready (built-in or driver) for Floppy,
Zip/Jaz/SparQ/LS-120 (similar drives), HDD, CD/DVD/BD, mice,
gamepads/joysticks, keyboards.
> is no popular DOS or BIOS interface, such as network or sound,
> cannot have kernel drivers in a useful way. For networking, the
> packet driver interface is just one facet in a complex world, we
> could think about some additions to make it easier to write new
> drivers or to do common things with the network. For sound, the
> lack of popular interfaces means that you basically have to use
> protected mode to simulate a popular HARDWARE (SoundBlaster etc)
> and then let your actual driver play whatever the soundblaster
> would have played given the detected I/O with the simulation.
I think Jim Hall's suggestion of a virtualized OS is more applicable here.
Something like MOL (Mac On Linux), or QEMU User Space Emulation (ala Wine)
with device redirection to generic hardware might be best.
>
> > & 64-bit support, device driver imports, automated regression testing.
>
> Some automated or semi-automatic quality checks seem interesting.
> One could think of code style checks, audits, automated comparison
> of how well different artificial test cases or real software runs
> work with different kernel (micro-) versions in some VM etcetera.
>
Just need people to start writing tests. :D
>
> Regarding 64 bit support, there are some experiments with letting
> DPMI drivers use more than 4 GB of RAM. To make better use of it,
> you would have to define new interfaces (XMS, EMS, DPMI, VCPI...)
> and hope that DOS software would be written which uses them.
>
I've seen cwsdpmi r7 supports upto 64GB address space. Some new interfaces
might be nice to program to, but I'd advocate step one to be making use of
such extensions transparent to old programs. I'd only count on BIOS or
other specialty hardware/firmware developers to be interested in such new
interfaces.
> Just using 32- or 64-bit calculations (not RAM addresses) is another
> story: Probably the kernel can be smaller by using more 32-bit calc
> but not really faster. Using memcopy optimized for more modern CPU
> (32, 64, 128, ... bit, FPU, MMX, SSE, ...) will also not make a real
> difference, as the DOS kernel itself does not move a lot of data.
>
>
I think memcopy becomes more important the more we look to implement
advanced hardware like USB1.1/2.0/3.0, 10/100/1000 ethernet. They're all
based on memory mapped IO.
> In short, there are certainly points in which DOS can be extended,
> but I personally doubt that many or even any of them should start
> in the kernel. Separate drivers and other software fit better.
>
> Maybe we should discuss the roadmap again in the first place?
>
I'd like to see more discussion. In the mean time, I'll keep
experimenting.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
