From owner-freebsd-mobile Sat Mar 27 20:30:38 1999 Delivered-To: freebsd-mobile@freebsd.org Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (Postfix) with ESMTP id 0360B153C9; Sat, 27 Mar 1999 20:30:34 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA14904; Sat, 27 Mar 1999 21:30:09 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA06189; Sat, 27 Mar 1999 21:30:09 -0700 Date: Sat, 27 Mar 1999 21:30:09 -0700 Message-Id: <199903280430.VAA06189@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Motoyuki Konno Cc: Nate Williams , NAKAGAWA Yoshihisa , Philippe CASIDY , freebsd-mobile@FreeBSD.ORG Subject: Re: Which LAN PCCARD for FreeBSD (no PAO!) In-Reply-To: <199903280328.MAA01166@rei.snipe.rim.or.jp> References: <199903251636.RAA04214@greatoak.home> <199903270255.CAA28337@chandra.eatell.msr.prug.or.jp> <199903272106.OAA05479@mt.sri.com> <199903280328.MAA01166@rei.snipe.rim.or.jp> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > I would like to know which card works under FreeBSD 3.1R and FreeBSD > > > > 2.2.8R WITHOUT PAO! > > > > > > Why? "plain FreeBSD"'s APM and PC-Card support is limitted and > > > buggy. You should be use PAO. > > > > No no no. You got it all wrong. PAO support is buggy, FreeBSD APM is > > good, and PCCARD support is limited. :) :) :) > > Why do you think "PAO support is buggy"? Do you read the recent > PAO patch? If you found bugs in PAO, please list up them. > > I can not understand why you dislike PAO so much. Because the number of options/changes that it makes to the stock FreeBSD has often times in the past been wrong. I can say that because many times in the past I found the real bugs in the FreeBSD code and fixed them, while PAO provides one, two, or three different 'workarounds' for the problem rather than trying to find the problem. Next, many of the patches affect too many different parts of the system, and are overkill for 'functionality', yet the PAO folks (after repeated attempts to work with them from me) refused to review and cleanup the patches to their 'necessary to fix the bug' state. It also 'fixes' many of the problems in the wrong way which makes extending the system that much more difficult, so that you end up with a code mess everytime new functionality is required. (Case in point, the PCI support in PAO was a mess last time I looked at it.) Finally, even after I made things very eary for them to merge their work with the baseline FreeBSD code (I spent about 80 hours on just the userland pccardc/pccardd merging) those changes were rejected, along with all of the other FreeBSD changes that were made by other committers. (I could list about 6-7 different 'bugs' that were fixed by me or others that were 'backed out' in PAO and replaced with incorrect workarounds. I don't know if these are still in place, but they were as of about 12 months ago.) Working together to solve a problem means 'working together', and I have seen no attempts at any of the PAO folks (except for kuriyama) who have any desire to work 'with' the FreeBSD people to solve the problem. Even when problems were pointed out in detail, there was no response (or change made to the code) or worse yet the response was something to the effect of 'PAO development is meant to be for laptops only'. (Case in point the APM code in PAO did not follow the APM specification, yet even when I changed the FreeBSD to follow the spec. and pointed the problem out to Tatsumi-san, my email was ignored and PAO *continued* to provide buggy APM support.) This happend over a 9 month period of time almost 2 years ago, yet the code-base still hasn't removed much of the 'useless' code that clutters up the tree. Yes, there are *very* good features in PAO, but wading through the useless changes and getting to the good stuff is hard work. Work that I'm unwilling to do because of the effort required. However, just because I'm unwilling to do the work doesn't mean I'm willing to sacrifice the maintainability and stability of FreeBSD by integrating the PAO patches whole. Heck, I could name off the things I'd like to have that are in PAO. 1) Device support that doesn't exist in FreeBSD. 2) Better pccardd 'configuration' management. 3) The ability to 'kill -HUP' pccardd and have it re-read the device table. 4) Support for additional PCCARD/CardBus controllers. 5) Installation boot floppy support. I could also name things that are/were completely wrong and/or should be redone. 1) Most of the ATA support 2) Most/all of the serial patches 3) The way that ethernet addresses are found/probed, which affects almost all of the additional network drivers that are in PAO, including the Wavelan stuff. I haven't looked in awhile, but potential wrong things 1) pcic is now an ISA device, even though it should not be. 2) PCI/CardBus support is a real mess. 3) 'Everything is a config file "option" configuration' 4) Wavelan support in pccardd. > o PC-card support of "plain FreeBSD" is limitted. PCCARD support in FreeBSD is actually pretty good. However, CardBus support is pretty limited, which means that most newer laptops are not supported. > o There are many notebooks which cannot work with "plain" FreeBSD, > but works fine with PAO. Most of this is configuration. > o There ALREADY exists PAO. There already exists Win95 as well, so should we all start using it? > So, I think "integrate PAO into FreeBSD -> fix PAO bugs if exist" > is EASIER AND FASTER than "ignore PAO and develop FreeBSD." Integrating PAO into FreeBSD is not an option if 'integrating PAO' means applying all of the PAO patches to FreeBSD, regardless of how it negatively affects desktop systems and future work for supporting hardware. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message