Date: Tue, 9 Mar 1999 18:10:49 +0800 (CST) From: Michael Robinson <robinson@netrinsics.com> To: jkh@zippy.cdrom.com, robinson@netrinsics.com Cc: dkulp@neomorphic.com, freebsd-mobile@FreeBSD.ORG Subject: Re: compatibility list Message-ID: <199903091010.SAA19722@netrinsics.com> In-Reply-To: <62457.920965462@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" <jkh@zippy.cdrom.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903091010.SAA19722>