From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tommy McCabe Subject: Re: Future of ELKS Date: Thu, 20 May 2004 13:18:39 -0700 (PDT) Sender: linux-8086-owner@vger.kernel.org Message-ID: <20040520201839.77135.qmail@web51309.mail.yahoo.com> Mime-Version: 1.0 Return-path: List-Id: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-8086@vger.kernel.org Tommy McCabe wrote: --- Miguel Bolanos wrote: > Good day to all, >=20 > The project seems to be finally awaking from a very > long period of > inactivity, this can be reflected not only by the > traffic on the mailing > list, but on the amount of people hanging around at > the irc channel and > the quality of the discussions over there. >=20 > Based on this facts, I believe that it is important > that all the people > involved and interested in ELKS, provide their own > opinions on what the > future of ELKS should be... I know of many wanting > to have specific > features that are not currently in the kernel.. and > others that as well > have interesting ideas for code reduction and > improvements. So if you > are one them, please feel free yourself, as all this > feedback is > important for us upgrade the TODO and roadmap of the > project. >=20 > The current things that are been done are: >=20 > - Creation of an additional kernel that will use > linux 2.6 coding style, > this is been done because we are looking forward to > enable the > possibility of including support for 8086 and > similar on the official > linux kernel as an option... of course this is will > take a long time, > and doesn't mean that work on the current > "production kernel" will be > depricated or anything like that, we which to > encorage you to keep > contributing on the "production" kernel.. and the > "new" kernel project > will be a work in parallel that at some point will > have all this > improvements on the production kernel merged. >=20 > - A possibility of using gcc to create 8086 binaries > might be a > possibility with a patch created by our irc friend > boto. If the tests of > this are successful we will enable elkscmd to let > the users decide if > they which to use gcc-8086 or our current bcc :) >=20 > Anyways thats all for now. Hope to hear back from > all. > best wishes >=20 > Mike >=20 > - > To unsubscribe from this list: send the line > "unsubscribe linux-8086" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at=20 http://vger.kernel.org/majordomo-info.html A list of things: 1. Debug ELKS. 2. Replace the various vi flavors with e3, which has already been ported, is easier to use, and is smaller. 3. Make sure the code is efficient as possible- 640KB isn't a lot of room, and I would like a minimal system to run in 256KB. 4. Get rid of the BIOS drivers and replace them with ELKS drivers. 5. Get full 286 protected mode and extended memory support. 6. Get all the drivers in current use out of "alpha test". 7. Implement modules. 8. Implement PLIP. 9. Use all the space on the 1.44MB disks, and differentiate between full3 and full5. 10. Make the devices in the image files depend on kernel config options. 11. Make ELKS installable to a hard drive. 12. Use a more modern version of the Minix FS, or even ext2. 13. A general code cleanup. Make ELKS POSIX-compatible, for example, open(), read(), write(), close(), fork(), and execve(), instead of their ELKS counterparts. Get rid of the things such as "the function to define a function" and hard-to-understand things such as x->y->z, which takes a paragraph to describe, let alone explain. Get rid of the complex tangle of system calls to do things such as use files. 14. Update the docs. 15. Get an ELKS GUI. Nothing fancy, with modes such as 320x200 to be compatible with CGA, but something like the DOS GUIs of old (NOT Windows). 16. Make use of the PS/2, VGA, and FPU drivers in the kernel. 17. Have a full choice between no FPU support, hardware FPU support, or FPU emulation. 18. Get a different compiler, preferably one that is ANSI-compatible, and use the whatever-it-is that allows 1MB code segments. 19. Make the compilation as hassle-free as possible. I have a bad hack of ELKS, which does compile, available at 24.194.1.64. It is a standard HTTP server with about 40KB/s of bandwidth, so don't hammer it. Three big bugs: 1. I can't fit everything on the root disk, 2. Ash should be on the comb disk, 3. sys_execve and sys_open reutrn the 2 and 8 errors on bootup. Another bug, I don't know if it has been solved since 0.10, is that you can't login with ash as the default shell. And oppose bloat at all costs! I don't want ELKS to bear the fate of MINIX, a half-maintained OS half-incompatible with everything which half-works on an 8086 and fully gobbles memory. __________________________________ Do you Yahoo!? Yahoo! Domains =96 Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer=20 =09 =09 __________________________________ Do you Yahoo!? Yahoo! Domains =96 Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer=20