Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!att-out!rutgers!igor.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.os.386bsd.development Subject: success with bde's com driver Message-ID: <Mar.31.04.05.02.1993.4640@geneva.rutgers.edu> Date: 31 Mar 93 09:05:06 GMT Organization: Rutgers Univ., New Brunswick, N.J. Lines: 62 There now seem to be several different approaches to avoiding the dreaded "silo overflow" problem with SLIP. One that was described a couple of weeks ago uses a set of three patches from bde: npx-0.4, intr-0.0, and com-0.2. (Don't ask where they are. I just realized that I have lost track. They're not all on agate. But a pointer was posted a week or so ago.) This does fix the problem, and in my opinion gives the system a generally faster feel (probably somewhat faster console I/O -- not surprising given the nature of the improvements). However, as someone commented, this is not for the faint at heart. First, he has omitted the patch to one key header file (systm.h). Fortunately all that's needed there is one additional line: #include <i386/include/cpufunc.h> I suspect he has also changed the declaration of strlen, as I had to make a couple of trivial modifications to its declaration in order to get things to compile. The only other problem I had was that after the patch, the system wouldn't see my hard disk. It turns out that it just needed slightly longer timeouts in wdcommand. (My change appears in a diff that I just posted to comp.os.386bsd.questions in response to a question about mread -- the same patch lets you access DOS partitions on the disk.) Finally, I note that this patch includes some of the standard patchkit patches. Unfortunately bde didn't tell us which ones, so I had to figure it out. It appears that you do not need patches 12, 18 or 19. If you are installing most of the kernel patches from the patchkit, you *do* need 79. Unfortunately it expects 18 and 19 as prerequisites. I ended up doing 79 by hand. As I recall, a couple of other patches create conflicts that require minor fixups by hand. However I didn't have much trouble getting a working kernel with most of the 0.2.2 patches on top of bde's code. But I wouldn't recommend it unless you know something about C and patch. This kernel takes care of most of my complaints about 386BSD. The system no longer hangs when I try to copy a file. (I suspect that is patch 2.) And SLIP works quite well (though it could use a somewhat more elegant startup method -- you really want a version of slattach to sends a bootp request and setups up the IP address, default route, and host name automatically). X looks just like it does under Linux. As a postscript to the comparisons of Linux and 386BSD: It looks to me like for a lot of us there probably isn't going to be a lot of difference. However I would have a less positive impression if I wasn't a hacker -- typical users aren't going to want to go through what I did to get this kernel put together. I'd strongly suggest 1) putting one of the fixes for silo overflow (there seem to be several) into the patchkit. (I haven't looked at the others, but I like bde's approach. He's spent a lot of time on tty performance and reliability, so unless there's good reason to go with another one, I'd probably use his code.) 2) making a current patched-up kernel available as part of the patch kit. Older versions of the patch kit seem to have had kernels with them. 0.2.2 doesn't. If you're going to make new users install patches and then rebuild software, at least you're got to give them a solid kernel to run on while they're downloading things and building software. The original 0.1 kernel is nearly unusable with high-speed serial lines, and if you've got a lot of memory, it hangs a lot.