Date: Wed, 12 May 1999 16:47:32 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Noriyuki Soda <soda@sra.co.jp> Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <Pine.BSF.3.95.990512162505.22596G-100000@current1.whistle.com> In-Reply-To: <199905122317.IAA00977@srapc342.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
ok, here is a reason for all this... It has benn a common thought among the FreeBSD people I have spoken too (and that's nearly all of the main developers, INCLUDING bill Jolitz) that with cheaper RAM and better organosed busses teh way to go is towards removing all static devoce information from the kernel, so that new device drivers are loaded completely dynamically. We are living in a world where NT is the competition. You do not recompile NT to add a device. Nor should you have to recompile FreeBSD to add a device. We want the distributed FreeBSD binary kernel skelaton to work with a driver that was written fro hardware that was built after the skelaton was compiled. This requires that the kernle have NO (NONE, ZIP, NADA, 0) information about the driver compiled into it. This is true as well for BUS types. If someone writes a VMEbus module it should be loadable to the kernel with no recompile, and after that all VME bus devices for which tere is a driver should be usabel once their drivers are loaded. The config.new(8) was evaluated a long time ago and rejected. Not because it was worse than config (.old) but because it was NOT SUFFICIENTLY BETTER. If we did the work to convert to config.new then that would be wasted effort, because we would then have to discard config.new and all it's changes when we got to the next step. It was decided (not officially, but effectively enough) that it would be just as easy to go directly to where we want to get from old config as from new config, so that itermediate step of config.new is wasted effort. We are planning on dicarding (mostly) config(.old) as well, but at least we have not needed to do a lot ofo work on it. NetBSD people have not the same stated aim of completely eliminating config, so for them it made more sense to migrate to config.new. From The FreeBSD perspective config.any is an evolutionalry dead end. It should only be used for 5% of all systems, where people are experimenting with features. The aim is to have the skelaton for a particular release be completely suitable for nearly all users, and have it taylored for particular systems by the linking in of dynamic .ko files as needed. THe diference between out definition of 'dynamic' an dyour definition of 'dynamic' is that in our definition the driver may not yet have been imagined at compile time for the kernel. I the newconfig(TM) world you need to know about the device, even if you don't have the driver present. We consider this a vital feature. Any system that does not support this will NOT be considered for FreeBSD. I have watched this discussion for a while and it seens that this concept has somehow not been understood by the newconfig people. I believe it is because we have not specified enough what our defintion of 'dynamic' is. It must also apply to new BUS type modules as well. The present new-bus code still has some prior knowledge for some devices and bus types. These are to be eliminated as we progress, so you should not think of these when you try understand new-bus. julian On Thu, 13 May 1999, Noriyuki Soda wrote: > >>>>> On Wed, 12 May 1999 14:53:31 -0700, > "Jordan K. Hubbard" <jkh@zippy.cdrom.com> said: > > >> I agree that this is better way to solve the conflicts between new-bus > >> and newconfig. Although I wondered why FreeBSD's core decide to choose > >> new-bus before Usenix. > > > We didn't choose it "before USENIX" as if it were somehow part of the > > objective to get this feature in before a public event, it simply came > > up that Peter had the time to actually integrate new-bus from the > > Alpha platform to the x86 > > This doesn't answer my wondering. The core members can safely postpone > the decision after Usenix, because all of core members must know that > both new-bus people and newconfig people will come to Freenix track. > Who is the chair of Freeunix track ? :-) > > > Whether new-bus or newconfig is "better" was really, honestly not > > the issue so much as were the following two bullet points: > > Quite interesting. This means that FreeBSD doesn't choose technology > by it's design, but by which spokes loudly. I definitely say that this > is worst way to design software. > > > 1. Does this bring the alpha and x86 architecture ports into better > > alignment so that any future permutations can be more easily > > brought across and/or simply shared between the two platforms? > > BSD/OS, NetBSD and OpenBSD are all based on newconfig on various > architectures. FreeBSD/alpha is directly derived from NetBSD/alpha and > NetBSD/alpha is based on newconfig. > And at the time when the decision is made, FreeBSD/i386 and > FreeBSD/pc98 are already converted to newconfig. > > So this is definitely is not the reason. > > > 2. Have we had a good history of communications between the people > > doing new-bus vs our history of communication with the newconfig > > people? > > Have you ever asked to newconfig people? > No, no one of core members who takes charge of kernel part contacted > to newconfig people, ever. > Only one communication is held between one of core members who is > actually new-bus one, and newconfig people. And this is requested by > newconfig people, not by one of core members. > > Note that there are core members who supports new-bus, everytime this > issue is raised between core, new-bus people can reply about this, > newconfig people never have that chance. > > If you'll make offical decision, always you can call both people, and > can hear both opinion. But this is never done. > > > The latter point is actually *really important* since we've already > > learned that having totally separate groups who talk to us maybe once > > a month (if even that often) is just not a workable strategy for the > > long term and often causes more confusion for our users than it > > actually helps the project. > > > We talk to Doug Rabson on a practically daily basis on a wide > > variety of issues whereas the only real communication I've seen from > > you has been during this conflict. > > And did you call one of the newconfig people? No. > The contact address of newconfig people is already publically > announced, but no one of core who takes charge of kernel part > contacted to the address. > > We contacted to the one of core who takes charge of kernel part, and > talked all problem about new-bus, before the decision is made. > > So, which does effort of communication ? > > > Before that, I had no idea that a Noriyuki Soda even existed. :-) > > Actually I am not a FreeBSD person, but one of observers of newconfig > project. Some of you does know that my name is listed in NetBSD > contributer's list. Although I send-pr'ed to FreeBSD sometimes. > This is the reason I never posted to this mailing list. > > The reason I posted now is I am disgusted in FUD about technical > points of newconfig. (I don't really care non technical points.) > All of core should know about the benefit of the newconfig, because we > already talked about it to one of the core when the decision is made. > > The reason why real newconfig people doesn't appears here is > that there is language barrier. > How did you think about Nakagawa-san's English? > Do you know the pain about writing English when he knows his > English is actually quite broken? > (Yes, my English is broken, too. But probably I am a person who don't > know what is disgrace. This is rare character and not thought good in > Japan.) > > Can you write Japanese ? > If no, why do you blame the one who cannot write English. > Actually they will write English, if one of the core asked it. But no > one of core request it, ever. > > So why no one never stops the FUD like the later postings ? > > > To try and put it another way, I've seen a lot of arguing about the > > technical merits of the two systems but very little arguing about how > > to solve the HUMAN FACTORS aspect of this situation which are really > > and truly what led up to the core team's decision. I've also called > > for greater communication between the two groups and so far all I've > > seen is a lot of arguing and expressions of general annoyance from > > Japan - that is NOT communication! > > Please point out the "general annoyance from Japan". > If you read it carefully, you can find the technical point is correct. > The problem of representation is caused by language barrier, not by > the annoyance. > > > Proper communication involves regular discussion about incremental > > improvements to the code base and how best to carry them out, biting > > off problems in small chunks and dealing with each completely before > > moving on to the next. Simply wandering off with the entire problem > > for 6 months and working on it in isolation DOES NOT WORK and we've > > proven this again and again. It only leads precisely to the situation > > we have here now with newconfig and also PAO. > > Then you don't know about language barrier. > Please learn Japanese, and write/speak Japanese, then you can find why > the voice from Japan is not enough. > > Actually Japan is the country where FreeBSD most succeeded. > There are over 50 books in Japan which includes "FreeBSD" in it's title. > This is not joke. > > And this is the result of Hosokawa-san, Nakagawa-san, Kato-san and > many other Japanese people's effort. > > > To put the problem in a larger context, people often ask me what all > > the FreeBSD people in Japan are working on and it's a point of eternal > > embarassment to me that I usually have to say "I honestly have no > > idea." > > Why don't ask Japanese people, then? > Why don't you going to learn Japanese? > > We all Japanese tries to learn English, though there is big barrier > between English language and Japanese language. > > > We really really really need to fix this if we're to avoid > > further repetitions of this kind of thing and that's why I'm flying to > > Tokyo at the end of this month to talk with you guys - we're clearly > > not communicating adequately and I'm willing to do what I can, > > including physically relocating myself on a periodic basis, to fix it > > from this side. > > This is wellcome, of course. > > > What are you doing to fix it on yours? :-) > > We've done our best, why don't you know our effort ? > -- > soda@sra.co.jp Software Research Associates, Inc., Japan > (Noriyuki Soda) Advanced Technology Group. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990512162505.22596G-100000>