From owner-freebsd-mobile Tue Mar 9 2:16: 6 1999 Delivered-To: freebsd-mobile@freebsd.org Received: from netrinsics.com (unknown [210.74.174.111]) by hub.freebsd.org (Postfix) with ESMTP id D210614BEF for ; Tue, 9 Mar 1999 02:16:00 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: (from robinson@localhost) by netrinsics.com (8.9.2/8.8.7) id SAA19722; Tue, 9 Mar 1999 18:10:49 +0800 (CST) (envelope-from robinson) Date: Tue, 9 Mar 1999 18:10:49 +0800 (CST) From: Michael Robinson Message-Id: <199903091010.SAA19722@netrinsics.com> To: jkh@zippy.cdrom.com, robinson@netrinsics.com Subject: Re: compatibility list Cc: dkulp@neomorphic.com, freebsd-mobile@FreeBSD.ORG In-Reply-To: <62457.920965462@zippy.cdrom.com> Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jordan K. Hubbard" writes: >I think this somewhat oversimplifies the matter and if we could >actually examine some of the bits of code you saw "rejected" at this >point, we'd quickly see that they destabilized or even flat-out broke >other aspects of our desktop/server support. First let me state *EMPHATICALLY* that I am against breaking anything for anybody. I was a VAX system adminstrator at Berkeley back in the 4.2 days, and I, too, find it offensive that some crufty laptop modem code could ruin the BSD legacy of stability and reliability. But, on the other hand, an attitude of "shoot first and ask questions later" is incompatible with attracting people to the project. >The same goes double for some of the scarier patches >to wd.c and the network drivers. > >That's all the "architectural purity" I see being called for here, >that and some attempt to avoid a profusion of #ifdefs within the code >that make it unreadable to anyone else. I ported wd.c from PAO to 3.0. I understand exactly what you are talking about, both in terms of scariness and incomprehensible #ifdefs. If I were running, e.g., Yahoo, I wouldn't want that code near my servers either. But I'm not running Yahoo, I'm running a laptop that happens to be my primary development system. When I went looking for some guidance on how to make my backup drive work, I found in the mailing list archives generally unproductive discussions between a group of people that was concerned about being able to use the hardware they actually have, and a group that was concerned that FreeBSD ought to have an elegant solution to the general problem of removable devices. It was strongly suggested that the former group was wasting their time (actually, I think the quote was, "you're wasting your time"). So, it appeared to me that I had the choice of a) waiting for the elegant solution to spontaneously evolve, b) becoming an expert in kernel architecture and devote all my time (for at least the better part of a year) to designing and implementing an elegant solution, or c) writing a quick hack that met my immediate requirements, without any delusions that it would ever be officially blessed for use by others. "C" was the no-brainer pick. In the process, I discovered a profusion of trivial little signs of profound neglect (e.g., the documented syntax in pccardd.conf.sample directly contradicted the code in pccardd/file.c). It was obvious that the "elegant solution" crowd was not attracting to its cause anyone who had any improvements to offer short of redesigning the entire FreeBSD device-driver architecture. As one of those non-attractees, here are my suggestions for how to improve the situation: 1. Establish an absolute, unconditional moritorium on any flames, insults or other denigration of any contribution to PC-CARD support, no matter how crufty or ill-conceived. 2. Put any functional crufty bits in the tree, somewhere, anywhere. Something like sys/i386/unsupported. It doesn't have to be part of the default installation (in fact, shouldn't be), but it should be somewhere where it is easy for people working on it to keep in sync with the rest of the tree, and with each other, and where it is available to people who do need to use it. Patches against this code should be subject to a level of scrutiny appropriate for something that is unsupported, but important to a significant user base. 3. Write documentation explaining in adequate detail why each of the crufty bits is unsupported, what has to happen before it will be supported, and some general guidelines on how to get from point A to point B. 4. Refer enquiries on freebsd-mobile to #2 and #3 above, rather than pointing vaguely to archived unresolved flamewars. If these four points are deemed unduly burdensome by the core team, then perhaps its not worth waiting the six months to shoot the PC-CARD support. Personally, though, I don't like a lot of the recklessness of the PAO team, either, and I'd hate to see PC-CARD support placed entirely in their hands. (Of course, I'd *really* hate to have to migrate to Linux, but hopefully it won't get to that point.) -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message