Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA1498 ; Tue, 23 Feb 93 14:44:41 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!usenet.coe.montana.edu!gemini.oscs.montana.edu!osynw From: osynw@gemini.oscs.montana.edu (Nathan Williams) Subject: Re: [386BSD] A few patchkit comments Message-ID: <1993Feb16.212839.10641@coe.montana.edu> Keywords: n Sender: usenet@coe.montana.edu (USENET News System) Organization: Montana State University References: <1993Feb16.182649.28351@zip.eecs.umich.edu> Date: Tue, 16 Feb 1993 21:28:39 GMT Lines: 94 In article <1993Feb16.182649.28351@zip.eecs.umich.edu> dmuntz@quip.eecs.umich.edu (Dan Muntz) writes: >Do patches exist which have only been distributed via the patchkit? IMHO this >is a Bad Thing. I recently switched over to pk0.2.1 (from 0.2, see below) >and noticed a few patches that I had never seen before. There are a couple patches that were posted to the 386bsd_kernel mailing list that *I don't think* were posted to the newsgroup. However, the bugs that these patches fixed were definitely worth putting in the patchkit. >Many people don't >use the patchkit or lack easy access to it (ftp) and haphazardly apply patches >as they appear in this group. I was doing this until recently, and I've >actually lost some stability in switching to the patchkit. I don't know >if a bug fixed by the patchkit exposed another bug, or if I've lost information >in the switch, but hopefully I'll find out soon by diffing my old sources >against the pk0.2.1 sources... Please do. I would think that you had applied a patch that wasn't in the patchkit. If you could find out which patch it is, I know I would like to know, since my goal for the 0.2.x patchkit was for a stable kernel, since my machine was less than stable. In my opinion, the reason for the patchkit was to set up a base of reference for other people. It is not mandatory, but it makes it easier for fols to make changes and patches based against this version, and it makes it easier for those people who are working on different parts of the system to get patches in areas that they aren't working on. > >When switching from 0.2 to 0.2.1, version 0.2 did not back out cleanly and I >had to start over from scratch. I haven't seen any other complaints about this >so perhaps it was just me. If you had installed both patch00602 and patch00603 then you probably would have problems. Otherwise, I had *hoped* that you wouldn't have to re-install if you followed the instructions in the README. Sorry about that! > >It would be nice if packages such as pcfs, julian's scsi drivers, >cgd's com.c, etc. were made part of the kit (say, patch90001,...). >Even if the latest, greatest versions were not included, it would make it >much easier for people dependent on certain packages to upgrade (thanks cgd, >for getting the 0.2.1 com.c out so quickly). The only problem with that is that the current form of the patchkit software enforces an order in the patches. Therefore, to apply Julian's patches, it would be a simple patch (there are some other issues, but if you really want to know about those, send me mail). The next driver that is added would REQUIRE that Julian's scsi patches be installed, and the next driver would require Julian's and the previous driver stuff was installed, and the next driver would require..... For example, I have no desire for the pcfs, since I don't run DOS. But, I am interested in having Julian's SCSI driver, an LPT driver (preferably one that works), and Chris's com driver. It would be nice to make a kernel with the busmouse driver in it, but I don't care one way or the other. Other people would give you completely different answers, since they are interested in completely different drivers. Pretty soon you have 12 different version of the wd driver, 2 different SCSI drivers, 5 WD ethernet controller's, etc...., and you can't remove any of them w/out removing everything that is dependant on the changes that were made to certain files after it. >I've thrown together some stuff >to automatically add pcfs (with hd patch), julian's scsi stuff (possibly old, >but stable with the 1542B), and cgd's com.c (trivial since he posted the >changes) to a pk0.2.1 kernel. If anyone would like to give it a try, drop >me a line and I'll make it available (consider it experimental until I've >heard of at least a couple others succeeding with it). Anyone know if >any of the above will be integrated into 386bsd0.2? > That's is great, and I recommend it to everyone who wants to try out all of these drivers. However, it is *difficult* to provide a patchkit in this format. Now, since certain driver's have been around long enough to prove their stability, it may be that Jordan could be convinced to consider the 'better' drivers as standard, and we could lose the old ones. In my opinion, Julian's SCSI driver's could replace the stock as driver in 386BSD without any backward loss. The driver has proven itself to be a very valid replacement to the driver, and there are less bugs and more functionality in it than with the stock driver. However, I don't make the decisions any more, so I'm just rambling... Nate -- osynw@terra.oscs.montana.edu | Still trying to find a good reason for nate@cs.montana.edu | these 'computer' things. Personally, home #: (406) 586-0579 | I don't think they'll catch on - Don H.