Hi Lucho, Tom, ..., TOM> > and so I won't touch the arkady branch with a 3 meter long stick. L> You already wrote this, but (1) I'd prefer the "innocent presumption", to > the "guilty presumption" towards him, and (2) I think that accusing him > when he's absent to defend himself is not ethical.
In one part, Tom is right: Arkady writes patches which are much longer than needed. Reading them takes much longer than needed, too, so it is hard to find out what exactly was the bug in the unpatched version. I think Arkady should write much more verbose explanations of his patches. Maybe he speaks C more fluently than English, but I do not care for bad style as long as I understand the point. Reading 3 sentences about an uninitalized variable or anything gives most people a better motivation to apply the attached patch than reading 30 lines of a patch which 1. initializes the variable properly 2. fixes some non-optimal type namings for 3 other variables 3. adds comments 4. changes indentation 5. changes parentheses and control flow to give some compilers a clue for better optimization 6. moves variables to more narrow scope to optimize stack and register usage 7. ... 8. ... 9. ... After reading the 3 sentences I can still apply 1. and 3. to STABLE and 2. and 6. to CUTTING EDGE kernel branches, and - AFTER I found the time to CAREFULLY read the changes, to make sure that no new bugs were introduced by that and that the readability of the code has not suffered more than the extra optimizations justified - 4. / 5. / 7. / 8. / 9.: Doing so would of course be easier if the patch would be available in 3 parts. Current situation is: Arkady writes all parts in one patch, nobody has the time to read it, after a while Tom or Bart or Jeremy find the time to find the "1." in the patch and apply that to the stable kernel branch, and the rest of the patch tends to get forgotten :-(. Or Lucho just applies the whole patch but nobody finds the time to verify that it is an improvement in all 1. - 9. aspects. Peer review is important, so it should be made easy. > if you are [using] SMARTDRV, you can also distribute [MS DOS] ... Not true: SMARTDRV (and EMM386) were available for free download from MS (*intended* as updates for those who already had older versions of them: SMARTDRV/new defaults to "delayed writes disabled or at least in "write before returning to prompt" mode, EMM386/new improves compatibility), as far as I remember in quite obvious way (other updates were more hidden in mixed update downloads or even had installers which required the old version to be installed first)...). And SMARTDRV, EMM386 and HIMEM are all included with Win 3.1 / WfW 3.11, so you can say they are not only part of MS DOS but also bundled with other products - which work with other DOSes as well, although not so well with FreeDOS. > > you didn't report, if the same problem happens with LBACACHE. Lucho> Because since I found out that SmartDrive is compatible with FreeDOS, > I don't use LBACACHE anymore Then you are a good candidate to do some performance comparisons ;-). Do you use SMARTDRV for non-int13 drives? Do you use the delayed writes? > Yes, the great SoftICE! Meeep! Ad time... http://www.sudleyplace.com/ has the great and free 386SWAT, a really cool debugger. I first had to find out that I had to init my 2nd VGA to use it (because it had detected it and decided to use the 2nd screen for the debugger) but then ... Wow, what a feature-packed thing, debugging all modes (real, DPMI, Windoze-DPMI, ...) in quite user-friendly way, and that even though I only spent 1 night using it and am far from feeling at home with all possible ways to use it! > Which means that the kernel development has virtually stopped now. I do not think so. It split, and we have a problem with merging. The patches by Arkady take time to read, which Jeremy does not have. Bart has other priorities now, so he will not dig through the whole pile to find the gems in there. And Tom is very sceptical about all Arkady patches, so he will not take too much time to read them either. He writes some good patches himself, but apparently they do not get discussed on the list that much. Probably they get added to his own kernel and sent directly to Jeremy for review? I hope they get enough review before they get into the stable kernel branch. Having an additional unstable branch is actually good, but only Arkady works on one? Tom> bug fixing will probably never stop, but squeezing single byte out of > it is IMO a complete waste of time. Fixing and squeezing should be kept separate unless the squeezing is done with some really foolproof and trivial changes. Combining both aspects into common patches is a bad idea but is widespread now. Tom is right, FreeDOS already allows you to have MORE memory free than MS DOS! But that involved tricky changes - for example f_nodes got embedded in a complex "copy to near data segment and back" system which STILL is not fully stable, and which is hard to debug (when I recently suggested that the panic() display should show the call stack, the idea was rejected because the "leak" of near f_nodes will often have happened much earlier, so a stack trace would not help). Tom> I probably made Stev Gibson happy with FreeDOS (stacks=9,256), Which reminds me that our STACKS data structure seems to be one flat stack - having MS DOS 3.3 compatible "compartments" of stacks would be good, and for FreeDOS style you can probably use stacks=3,384 and save some memory... in MS DOS style, every nested IRQ allocates one or more (!) of the e.g. 9 compartments of e.g. 256 bytes each, which can overflow into each other. Tom> made FreeDOS load DD1000XX.SYS, Please check bugzilla, there seem to be some remaining problems. Tom>made freedos kernel load Intel Pro1000 > network driver, and found one reason for panic('too many fnodes in use') Thanks. I remember that the tricks were: Using the low sector buffer for something for the DD1000.. driver, making int 21.25/35 reentrant, and some "force usage count back to 0" for the near f_nodes (which would otherwise have "leaked" for critical error events, right? Another thing which we should probably have: Some disk access flag magic or "suppress critical error handling", to avoid interactive crit. error stuff for non-DOS drives and to allow MS compatible return codes for disk access and int 21.36 / 1c etc. (by the way, forced boot sector re-read does not seem to work properly, maybe a BUFFERS problem?). > Speaking about Arkady, however, there are some circumstances which can > hinder his testing. He has only a 80386 PC with a small hard disk and > Windows 3.1. And he has no Internet connection at all! Yes, an important point - he is using something like a BBS, so he has mail and can use a web to mail interface to download single web pages. Still he could use SSHDOS/SFTPDOS/SCPDOS/FTP... to upload files ;-). Who knows, maybe he can even find out why WSWAP (DOS sessions) do not work in Win3.1 /s mode in FreeDOS? > the kernel talks directly to int13 and never uses int25 internally. Not entirely true: The kernel uses a big powerful function internally which consists of "things which would be done by int 25/26/... normally", critical error handling, DMA wraparound avoidance (I wonder if there would be a performance gain by being able to disable that for harddisks), track wraparound avoidance (I hope LBA disks bypass this check), etc.! The DMA / track wrap thing is SUPPOSED to be in an handler which hooks int 13 (so that DOS programs can benefit from it even when using int 13 directly). It uses 1 low sector buffer, but I think that does not stop it from being offered to all int 13 users. The int 13 access would also be accessible / hookable through int 2f.13, as shown in FDSHIELD. If FreeDOS really never uses int 25/26/... internally, then SMARTDRV 4 would have little effect on FreeDOS!? Tom> AFAIR, he found *one* bug, that *might* have real world significance > (ret_AH), which was introduced lately by some optimizations by Bart. > I don't see any new features in keDANGEROUS either. Arkady did improve some things. He changed the menu system a lot, improved Y/N prompt handling for INSTALL, reduced environment overhead (which hopefully is as safe as he said), fixed the ret_AH bug which DID have real world significance, and fixed a few other issues, e.g. improved int 21.36 handling a bit. However, he also made things worse, e.g. you now have to press enter after typing a digit in non-fullscreen menu mode, and some patches broke things which were fixed again by later patches, so you have to be careful with them. Sure, allowing a completely empty environment is not technically a bug, but I remember the big discussion about "environment must not be empty, otherwise FreeCOM gets confused". Another broken-unbroken pair actually involved "real brokenness"... > SmartDrive 4/5 doesn't hook Int 25h as SmartDrive 3 hooks Int 13h. Here's > a detailed description of the working principles of SmartDrive 4 and 5 - > http://support.microsoft.com/?id=83325 That is a really interesting page, although I already knew SOME things about SMARTDRV from earlier reading... SMARTDrive 3.x of MS DOS 4.01 was an int 13 / CHS / track cache. I think the cache elements could not even wrap around track ends. The driver was a SYS but already contained some (probably never really used) API for extra control. Actual use was limited to buffering reads in either EMS or XMS. SMARTDrive 4.x of MS DOS 5.x/6.x/7.x and Win3.1 is an int 25/26 based cache which can work for ALL FAT drives - even non-int13 ones. Because int 25/26 are hooked, the cache can make use of internal knowledge of the filesystem structure. However, older versions do not support FAT32 disks (which do not normally use int 25/26). The cache offers an embedded (shares the same pool of XMS) CD-ROM caching module which hooks MSCDEX (I guess). By the way, I recently found out that I_CACHE, like my CDRCACHE, "hooks" CD-ROM access by "looking like a lowlevel driver for *CDEX and looking like *CDEX for the actual lowlevel driver", a nice and not intrusive method. I_CACHE also has some advanced features like delayed writes, VDS/VDMA, handling of floppy drives without change line, resizability, queueing, sorting the delayed writes into tracks ... (shareware 1994-1996 by Miles Pawski). Back to SMARTDRV. It can not only cache CD-ROM "redirector" drives but, I believe, even network redirector drives. Delayed writes are delayed until the cache is full, the delay gets longer than 5 second, a program exits (returns to the prompt), ctrl-alt-del is pressed, or the system gets idle. A whole bunch of interrupts is hooked to achieve this, the design of the LBAcache dispatcher is much simpler (but other "backstage" parts of LBAcache are quite complex!). SMARTDrive 4.x auto-shrinks / auto-re-inflates when Win init/exit broadcasts are detected, and this MS KB83325 article tells us that this is done in a more elegant and clean way compared to SMARTDrive 3.x :-). The shrinking was important in the early 1990s when people only had 2-8 MB RAM at all. SMARTDrive 4.x supports VDS, can load (part of) itself into UMB (for LBAcache, you simply use LOADHIGH to load the main part into UMB, use (better not!) LOADHIGH to load the optional separate track buffer into UMB, and use the LBAcache TUNS option to tell the cache to allocate stacks outside UMBs even when loaded high - which is needed for SCSI). SMARTDrive 4.x also contains a wrapper for "double buffering" which you have to load in a separate invocation of SMARTDRV. For FreeDOS, you would use the LOWDMA tool of UMBPCI, if anything - the FreeDOS kernel already contains checks (in the abovementioned big powerful function, which in turn is used BY int 25/26 in FreeDOS) to ensure that UMBs are not used for disk transfer buffers. When used in Win32, int 25/26 calls are redirected to a protected mode disk driver (WDCTRL/IDE/ESDI/SCSI available) for better performance. That driver also allows direct disk access to the swap file on disk and is fully reentrant, which in turn allows even DOS boxes to use virtual RAM which can be swapped out to disk. Components are: WDCTRL, BlockDev, PageFile, int13 (all 386Enh drivers, "32bit disk access" can be disabled when compatibility problems show up, the int13 and WDCTRL parts make sure that int 13 users and DOS (-> int 2f.13...) use the 32bit drivers and not the real int 13 - when 32bit disk access is enabld, of course). If you know a nice case of a non-int13 drive letter which wants to be cached, please let me know. I think I could eventually write an ugly wrapper which "posts" int 25/26 access to such drives through the int 13 interface, using a virtual int 13 drive which in turn is implemented by actually accessing int 25/26 again. That double morphing would allow LBAcache to cache such drives (geometry-free LBA access, combined with a fixed but not really used virtual CHS geometry). About the delayed writes again: DR DOS NWCACHE has selectable delay (unit: timer ticks, default: 5 seconds, ERIC RECOMMENDATION: 330 milliseconds) and selectable maximum amount of dirty cache sectors (default: all or nothing, ERIC RECOMMENDATION: 64 kilobytes). Other caches also have selectable read-ahead (LBAcache TICKLEHD: whole track for floppy, 8 sectors for harddisk. MS DOS BUFFERS: up to 8 sectors (the y of BUFFERS=x,y). Other caches: max 1 track, recommended 1/4 track for harddisks and rest-of-that track for floppy. NWCACHE also allows write merging in the current floppy track, which seems to be quite safe compared to fully delayed writes. Some caches sort the delayed writes back into tracks to allow faster writing, or even check if a write actually changes disk contents before letting it through...). As usual, I would like to know how NWCACHE /DELAY=330 /BL=4 /FLUSH=ON /W=64 performs compared to "no delayed writes / readahead at all" and "full big delay of at most the whole cache contents". SMARTDRV only allows "all or nothing" (except the flush on/off setting) and LBAcache current version does not support delay at all yet but i am PLANNING a delay which would use the default settings 330/on/64 which I suggest to be tested with NWCACHE... Looks like I got a bit distracted by the cache topic, I hope you still found my comments on kernel development interesting / useful ;-). Eric. ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
