Date: Sun, 28 Mar 1999 09:42:34 -0700 From: Nate Williams <nate@mt.sri.com> To: NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp> Cc: Nate Williams <nate@mt.sri.com>, Motoyuki Konno <motoyuki@FreeBSD.ORG>, freebsd-mobile@FreeBSD.ORG Subject: Re: Which LAN PCCARD for FreeBSD (no PAO!) Message-ID: <199903281642.JAA07849@mt.sri.com> In-Reply-To: <199903281603.BAA00642@chandra.eatell.msr.prug.or.jp> References: <199903280430.VAA06189@mt.sri.com> <199903281603.BAA00642@chandra.eatell.msr.prug.or.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 > > 1. Many PAO people are Japanese, so we have language and > communication problem. I'll grant you that. However, in my experience from living in Japan and from articles I've had from many Japanese people, most Japanese technical people (engineers) have *ver* good written English skills (your English skills is much better than my Japanese skills. *grin*) However, if we grant that you can't communicate well, then how do you expect the FreeBSD developers to 'hand over' the maintenance of a large portion of FreeBSD code-base to people who are unable to communicate with most of their userbase. (I'm not saying that the the largest portion of FreeBSD's support base are American, but that English is the most common language to communicate with the userbase.) > # Nate's this mail is very long, I need long time for reading the > #mail. We are not native of English. It is hard. Japanese is very > #different to western-europe languages. You don't have to convince me of that. :) > 2. Nate, you are nagative to PAO, so we become passive for PAO > integrate. I was not always negative towards PAO, and neither was the person who was before me (PHK). But, after attempting to work with the PAO folks, it became very frustrating to see that they had no intention of working 'with' the FreeBSD folks to provide a 'joint' project. > 3. Many PAO people go to newconfig project. (me too) I know very little about newconfig, but as I understand it the FreeBSD core team is not interested in using newconfig, so any work you do using it is wasted effort. Note, I was not part of that decision (I'm no core member), but I do respect their technical ability. [ Features I liked in PAO mostly delted ] > > 3) The ability to 'kill -HUP' pccardd and have it re-read the device > > table. > > It is include some bug. (not free memory when got -HUP.) > > # I wrote that code. It is corner-cutting. :-) I didn't say I liked the implementation, but I do like the feature. (Most of the features I like need to re-vamped for FreeBSD, but in many cases *most* of the code and ideas are valid in PAO.) In this case, I've not reviewed how it's implemented, but you've convinced me that it's not done correctly. :) > > 1) Most of the ATA support > > hu-m. ATA support is temporary. Because, original wdc depend > isa_biotab_wdc[] of ioconf.c and re-write is hard. So, we will > rewrite on newconfig project. Warner Losh is already re-writing it, and I suspect (I'll let him correct me if I'm wrong) he's using the ideas and possibly some of the code from the PAO patches. > > 1) pcic is now an ISA device, even though it should not be. > > I disagree. PCIC is true ISA device. Now, CardBus controller is > used by Legacy-mode, so it should be probe as ISA device (and > additionaly PCI setup). (It likes wdc driver.) I disagree. PCIC is not an ISA device, but a completely new (and separate) device. It should be able to deal with other devices w/out knowing the details of the controller. > In the future, it is used by native CardBus mode, it should be > handle true PCI device. (It likes new ata driver.) > > And, it should be separate PCIC common core code and bus code, so > no wrong affects to native CardBus support. Agreed, but making it into an ISA device is not the right direction. > > 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. > > I think, first merge new feature, second brush up and stabilize, > it is FreeBSD-style. No, that's the Linux style. The FreeBSD style is to try and only integrate stable features that have been tested well, *then* debug them when they are found to be unstable in a larger audience. Adding in 'buggy/poorly implemented code' is never the right way to do software engineering. That is the 'Microsoft Way', and we can see what it has us. Nate 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?199903281642.JAA07849>