Re: cvs commit: src/sys/pci pcisupport.c
#I'm busy recently, and shocked by suddenly new-bus merge #happening (I think, its process is not fair). I was lost my head. #Also, one of stress cause is language barrier. English is hard #for me. It is my weak point. Not a problem; most of us do not speak Japanese. :-) I am looking forward to hearing about newconfig from you folk at USENIX! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Tomoaki NISHIYAMA wrote: From: NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp y-nakaga You bought a computer with the super-ultra-new Microsoft (tm) y-nakaga Microsoft Bus (tm), for which you bought the latest and greatest y-nakaga device X. y-nakaga y-nakaga It is extremely vulgar joke. I doubt your character. No, I don't think this is a joke, but a serious situation. We should stick on technical problem if we continue to discuss. I replied to this in private, but, for the record, it was not a joke. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Sat, 15 May 1999, Daniel C. Sobral wrote: Tomoaki NISHIYAMA wrote: From: NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp y-nakaga You bought a computer with the super-ultra-new Microsoft (tm) y-nakaga Microsoft Bus (tm), for which you bought the latest and greatest y-nakaga device X. y-nakaga y-nakaga It is extremely vulgar joke. I doubt your character. No, I don't think this is a joke, but a serious situation. We should stick on technical problem if we continue to discuss. I replied to this in private, but, for the record, it was not a joke. I understand it wasn't a joke, but it *was* funny, and he wasn't abusing things. I don't think it's too fair to jump on him over it (you didn't, Daniel). A little humor is allowed, as long as things are kept in proportion, right? Enough. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999 10:41:23 +0100 (BST), Doug Rabson d...@nlsystems.com said: As I suspected, a massive flamewar has happened while I've been away. I don't think I have anything to add to what has been said (and I certainly don't want to continue a flamewar). Can people please just drop the subject until after Usenix. This kind of flamewar is too upsetting (to me anyway) and just makes it harder to have a useful face-to-face discussion. As I said earlier, I agree with you. About human factor, I think face to face communication is best way to solve problem. But about technical issues, I'd like to reply in public place, because both the message from Julian (*1) and the message from Daniel (*2) showed typical misunderstanding about newconfig. The goal they showed is also the goal of the dynamic configuration of newconfig from the beggining. I'd like to show how it will be achieved by newconifg. Could you permit me to answer technical issues in -hackers as Daniel adviced ? Or, -current is better about the questions which is posted to -current ? Other possibility is newconfig mailig list (anyone can subscribe it and it's archive can be accessed from WWW), or postponement until after Usenix. How do you think? (*1) Date: Wed, 12 May 1999 17:08:10 -0700 (PDT) From: Julian Elischer jul...@whistle.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: pine.bsf.3.95.990512165327.22596i-100...@current1.whistle.com (*2) From: Daniel C. Sobral d...@newsguy.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Fri, 14 May 1999 20:46:05 +0900 Message-ID: 373c0cfd.7d9d3...@newsguy.com -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Sat, 15 May 1999, Noriyuki Soda wrote: On Thu, 13 May 1999 10:41:23 +0100 (BST), Doug Rabson d...@nlsystems.com said: As I suspected, a massive flamewar has happened while I've been away. I don't think I have anything to add to what has been said (and I certainly don't want to continue a flamewar). Can people please just drop the subject until after Usenix. This kind of flamewar is too upsetting (to me anyway) and just makes it harder to have a useful face-to-face discussion. As I said earlier, I agree with you. About human factor, I think face to face communication is best way to solve problem. But about technical issues, I'd like to reply in public place, because both the message from Julian (*1) and the message from Daniel (*2) showed typical misunderstanding about newconfig. The goal they showed is also the goal of the dynamic configuration of newconfig from the beggining. I'd like to show how it will be achieved by newconifg. Could you permit me to answer technical issues in -hackers as Daniel adviced ? Or, -current is better about the questions which is posted to -current ? Other possibility is newconfig mailig list (anyone can subscribe it and it's archive can be accessed from WWW), or postponement until after Usenix. I would like to postpone until after Usenix. I'm sure that we will be able to sort out any technical misunderstandings there which will make it possible to have a reasonable public discussion. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Sat, 15 May 1999 15:58:01 +0100 (BST), Doug Rabson d...@nlsystems.com said: I would like to postpone until after Usenix. I'm sure that we will be able to sort out any technical misunderstandings there which will make it possible to have a reasonable public discussion. OK, I'll postpone, then. Julian, Daniel, and other folks, is this OK for you? If you'd like to hear the answer now, please request us that we should reply to your question. We'll reply to you in newconfig mailing list (i.e. To: you, Cc: newconfig) to avoid useless flame war. Note that the newconfig mailing list is truly open, anyone who is interested in newconfig approach can access the answer. The address of mailing list: newcon...@jp.freebsd.org The official WWW page: http://www.jp.freebsd.org/newconfig/ The way to subscribe (majordomo): http://www.jp.freebsd.org/newconfig/ml.html The mail archive of newconfig: http://home.jp.freebsd.org/mail-list/newconfig/ The mail archive of newconfig-jp (written in Japanese): http://home.jp.freebsd.org/mail-list/newconfig-jp/index.html.ja.jis (The traffic of newconfig mailing list is not much, because main discussion is currently done in newconfig-jp.) And, Dainel, I'm very sorry that one of us called your serious question joke. I know your question is serious, because what you said is also the goal for me from the beginning of dynamic configuration of newconfig. Perhaps we should answer to you in newconfig mailing list (To: you, cc: newconfig). Is this OK for you? We have answer which satisfy your requirement. -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
I replied to this in private, but, for the record, it was not a joke. Ok, I see your say. I feel inadequate metaphor and provocation form, so that message seemed vulgar joke. New-bus's goal is meaningful, but not only that one. Also newconfig is same. Difference between these is realization way. But I don't reply that message, I must become to cool. Probably other member of newconfig will reply. I keep quiet in a while. #I'm busy recently, and shocked by suddenly new-bus merge #happening (I think, its process is not fair). I was lost my head. #Also, one of stress cause is language barrier. English is hard #for me. It is my weak point. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp writes: Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. Because, you are misunderstanding 4.4BSD scheme (and newconfig). This is pointless. All you're doing is pointing your finger and screaming It's not right! It's not fair! without saying anything of actual value. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
This is pointless. All you're doing is pointing your finger and screaming It's not right! It's not fair! without saying anything of actual value. OK OK, you are right. I have language barrier, so I can't explain well. I talk other newconfig member, one of member, Furuta-san will go to Usenix and presentation of newconfig paper. After Usenix, still misunderstanding is exist, argument again. I will become to explain if needed. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp writes: OK OK, you are right. I have language barrier, so I can't explain well. I talk other newconfig member, one of member, Furuta-san will go to Usenix and presentation of newconfig paper. Any chance of getting a preview of that paper? Is it, or will it be, available on the Web? DES (who won't make it to Usenix this year...) -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Any chance of getting a preview of that paper? Is it, or will it be, available on the Web? I don't know, probably the paper not yet available on Web. Please ask to Furuta-san. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikhail Teterin wrote: Mike Smith once wrote: For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. What about kldload /modules/up/whatever.ko and kldload /modules/smp/whatever.ko and even kldload /debug-modules/up/whatever.ko [...] Horrible kludges. Things should just work. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In article xzphfpg3tmo@localhost.ping.uio.no, Dag-Erling Smorgrav d...@flood.ping.uio.no writes: Any chance of getting a preview of that paper? Is it, or will it be, available on the Web? Nakagawa-san slightly misunderstands. I have no time to write full paper, so I have already submitted presentation slide. Instead of it, I will also write speech draft of the presentation, and will place anywhere before the talk. Please wait. -- fur...@sra.co.jp (Atsushi Furuta) Advanced Technology Group. Software Research Associates, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa wrote: Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. Because, you are misunderstanding 4.4BSD scheme (and newconfig). The *GOAL* here is the following: You bought a computer with the super-ultra-new Microsoft (tm) Microsoft Bus (tm), for which you bought the latest and greatest device X. Now, you want device X to work. Your FreeBSD 4.5 doesn't know about Microsoft Bus, much less about device X. As it happens, this Microsoft Bus is actually mounted through USB, which happens to be available through an CardBus device, which is actually mounted on a PCI card providing the bus. What you *must* achieve is the following: cd /modules fetch http://www.microsoft.com/FreeBSD/drivers/yeah.sure./msbus.ko fetch http://www.company.x.com/drivers/deviceX/x.ko kldload x results in the msbus being loaded on demand, located and mounted across the assorted bridges, and device X driver then getting loaded, having it's resources automatically set up, and becoming available for use. No kernel recompiling of file editing can be added to above sequence, and other files should be kept to the minimum possible (strictly -- if it can be done with less, it should be done with less). The newconfig opponents fear that one must edit some file to add the information that x must be mounted over msbus, or even worse (such as kernel recompiling). If you can show that the four lines above would suffice in newconfig, you got a winner. Feel free to change the kldload x to dconfig x if you like, but 'dconfig x at msbus' will not be well received. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
David Schwartz wrote: Believe it or not, good ideas can even come from people who can't code at all, and the ideas are just as good. Slapping these people down just ensures they don't contribute in the future. Now if their ideas genuinely are bad, you are more than welcome to slap them down as much as you wish. If that means they don't contribute more bad ideas in the future, so much the better. Heck, it even may save you the idea of having to explain why the bad idea is, in fact, bad. But if it's such a good idea, why don't you code it? doesn't fall into any of these categories. It's one of those that's what you think type arguments that serves as an excuse to ignore the merits of the other side's case. Well, it would help if the people who can't code wouldn't so often make bad suggestions and then keep trying someone else to implement them even when the people who *can* code tells them it's a bad idea, and they just won't take that for an answer. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Proof of Trotsky's farsightedness is that _none_ of his predictions have come true yet. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
You bought a computer with the super-ultra-new Microsoft (tm) Microsoft Bus (tm), for which you bought the latest and greatest device X. It is extremely vulgar joke. I doubt your character. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp y-nakaga You bought a computer with the super-ultra-new Microsoft (tm) y-nakaga Microsoft Bus (tm), for which you bought the latest and greatest y-nakaga device X. y-nakaga y-nakaga It is extremely vulgar joke. I doubt your character. No, I don't think this is a joke, but a serious situation. We should stick on technical problem if we continue to discuss. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Peter Wemm pe...@netplex.com.au Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Thu, 13 May 1999 06:24:12 +0800 Message-ID: 1999051414.e2dda1...@spinner.netplex.com.au peter What on earth is the locator stuff for? Why can't you use plain text? peter How does 'iobase 0x280' become '640,0,0,0,9,-1,-1,0,1,0'?? This should be changed in the future. I would say for this point Yes, there are weaknesses still, but that is because it isn't quite finished and is evolving still. I don't think it impossible to make it work dconfig load ne4 at isa0 iobase 0x280 irq 9 dconfig unload ne4 We have just made it work, before making it look cool. peter I prefer just: peter device pcic0 at isa? port 0x3e0 peter device pcic1 at isa? port 0x3e2 peter in a static kernel config file, or: peter pcic0 port 0x3e0 peter pcic1 port 0x3e2 peter in /boot/isa.conf. Or: peter # sethint pcic0 at isa port 0x3e0 peter # sethint pcic1 at isa port 0x3e2 peter # kldload pcic.ko peter .. to load pcic to look at isapnp, pci and those two isa ports. or: peter # kldload pcic.ko peter .. to load pcic and look at pci and isapnp if present. peter peter If the driver writer decides there is a significant amount of code in peter bus dependent modules that it is worth splitting pcic.ko itno pcic_isa.ko, peter pcic_pci.ko, pcic_pnp.ko and pcic_common.ko, then this works best: peter # kldload pcic_pci.ko peter .. to load the pci and common parts, and cause a reprobe. Yes, it does seem cool. But don't you think it even better to simply tell the system that I want pcic on pci not knowing the filename (whether it was split into three files, or just one file)? # dconfig load pcic? at pci? Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Jordan K. Hubbard j...@zippy.cdrom.com Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:12:05 -0700 Message-ID: 67065.926554...@zippy.cdrom.com jkh I have seen a lot of arguing about technical merits and decisions made jkh by the core team, but I have yet to see any constructive comments jkh about fixing the communication problems which led to this decision. I think the best way to fix the communication problem is to discuss on the technical merits, to understand what you think and to make you understand what we think. If the explanation of the code is too short ask questions what is not understood. jkh Evaluating technology is a jkh question of deciding which code is both superior AND has the best jkh longevity, longevity being a more difficult equation which combines jkh the history of the developers involved and how effective your jkh communications with them are. In this case, I don't believe jkh communications are effective and that kills newconfig just as jkh thoroughly as having the code be a total mess; I think I've pointed jkh this out several times now. Yes, longevity is an important thing. But it is not only the matter of communication, but it depends on the fundamental design, and on what principle the code is written. Once you understand the fundamental design and the principle it is based on, you will be able to develop them further. Thus we want you understand the design and principle of newconfig, through the code and discussion. You can decide to merge them after understanding the principle. It's not a good idea to reject something without understanding, as to merge something without understanding. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Noriyuki Soda wrote: BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: I'm not going to reply to these points as I suspect it will lead to a pointless flame thread. I would prefer to discuss these issues in person at Usenix. 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. As I suspected, a massive flamewar has happened while I've been away. I don't think I have anything to add to what has been said (and I certainly don't want to continue a flamewar). Can people please just drop the subject until after Usenix. This kind of flamewar is too upsetting (to me anyway) and just makes it harder to have a useful face-to-face discussion. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as best match, but first match. :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in files file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. - new-bus cannot support on-demand device driver loading, dynamic configuration for newconfig can do it, though. This is because new-bus doesn't have the way to represent meta information like a mapping from device name to driver filename. If new-bus have this, there is no need to specifiy kldload if_fxp, but just say I need fxp0, then configuration framework can automatically load fxp driver, if it is not loaded yet. This is how configuration works in both newconfig and even oldconfig (look at static kernel configuration file for oldconfig, there is the line device fxp0 which demands fxp driver to be loaded). The way to specify a driver to be linked on new-bus is retrogression to the age before 4.0BSD (4.0BSD introduced oldconfig and it was released on 1980 :-)). Why does a user have to specify file name instead of device name? Mmmm, perhaps do new-bus people believe MS-DOSism or Linuxism? :-) The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. - new-bus heavily depends on oldconfig which is known to be obsolete and machine dependent (look at usr.sbin/config/config.y, there are many definitions which depends on ISA bus, e.g. PORT, IOMEM, IOSIZE, ... newconfig can defines such attributes dynamically on demand.), and lacks many features which newconfig already has. e.g. - configruration hint which can be accessed from static configuration - bus/device hierarchy information which can be accessed from static configuration - inter module dependency information based on module attributes. new-bus completely lacks this feature, and depends on oldconfig about this. - mapping information from device name to object file name. new-bus completely lacks this feature, and depends on old config about this. Therefore, FreeBSD eventually will have to choose one of the following candidates: [a] gives up static configuration. But this doesn't solve the following problems: - at least console driver should be linked statically, unless you statically link this, you cannot get the error about dynamic loading critical drivers. :-) - in some applications, static configuration is good enough and dynamic configuration is merely overkill. FreeBSD will not cope with these applications better. Furthermore, this doesn't solves the problems about inter module dependency and mapping information from device name to object filename. [b] uses ugly kluge like hardcoding to solve the problems which already solved by the newconfig cleanly. [c] reinvents features which already implemented on the newconfig. This is exactly NIH problem, and means FreeBSD loses compatibility with *BSDs (FreeBSD becomes non-BSD). Note that newconfig is genuine feature of 4.4BSD, and 4.4BSD red daemon books already said that after the system is completely booted, 4.4BSD (i.e. newconfig) cannot load device drivers These
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Noriyuki Soda wrote: NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as best match, but first match. :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? Yes. BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: I'm not going to reply to these points as I suspect it will lead to a pointless flame thread. I would prefer to discuss these issues in person at Usenix. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: I'm not going to reply to these points as I suspect it will lead to a pointless flame thread. I would prefer to discuss these issues in person at Usenix. 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. -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 09:35:36 -0400, Rick Whitesel rwhite...@nbase-xyplex.com said: In general I believe that dynamic configuration of the system is extremely useful to both the development community and the user community. The development community has a much easier time if they can load / unload drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Hi: While I confess to not having the whole picture here, I do, of course, have an opinion. In general I believe that dynamic configuration of the system is extremely useful to both the development community and the user community. The development community has a much easier time if they can load / unload drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Rick Whitesel Scientist NBase-Xyplex Eml: rwhite...@nbase-xyplex.com They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 - Original Message - From: Noriyuki Soda s...@sra.co.jp To: curr...@freebsd.org Cc: s...@sra.co.jp Sent: Wednesday, May 12, 1999 5:01 AM Subject: Re: cvs commit: src/sys/pci pcisupport.c NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as best match, but first match. :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in files file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. - new-bus cannot support on-demand device driver loading, dynamic configuration for newconfig can do it, though. This is because new-bus doesn't have the way to represent meta information like a mapping from device name to driver filename. If new-bus have this, there is no need to specifiy kldload if_fxp, but just say I need fxp0, then configuration framework can automatically load fxp driver, if it is not loaded yet. This is how configuration works in both newconfig and even oldconfig (look at static kernel configuration file for oldconfig, there is the line device fxp0 which demands fxp driver to be loaded). The way to specify a driver to be linked on new-bus is retrogression to the age before 4.0BSD (4.0BSD introduced oldconfig and it was released on 1980 :-)). Why does a user have to specify file name instead of device name? Mmmm, perhaps do new-bus people believe MS-DOSism or Linuxism? :-) The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. - new-bus heavily depends on oldconfig which is known to be obsolete and machine dependent (look at usr.sbin/config/config.y, there are many definitions which depends on ISA bus, e.g. PORT, IOMEM, IOSIZE, ... newconfig can defines such attributes dynamically on demand.), and lacks many features which newconfig already has. e.g. - configruration hint which can be accessed from static configuration - bus/device hierarchy information which can be accessed from static configuration - inter module dependency information based on module attributes. new-bus completely lacks this feature, and depends on oldconfig about this. - mapping information from device name to object file name. new-bus completely lacks this feature, and depends on old config about this. Therefore, FreeBSD eventually will have to choose one of the following candidates: [a] gives up static configuration. But this doesn't solve the following problems: - at least console driver should be linked statically, unless you statically link this, you cannot get the error about dynamic loading critical drivers. :-) - in some applications, static configuration is good enough and dynamic configuration is merely overkill. FreeBSD will not cope with these applications better. Furthermore, this doesn't
Re: cvs commit: src/sys/pci pcisupport.c
Hi: Since newconfig appears technically superior, what are the issues that are hindering its acceptance? Rick Whitesel - Original Message - From: Noriyuki Soda s...@sra.co.jp To: Rick Whitesel rwhite...@nbase-xyplex.com Cc: Noriyuki Soda s...@sra.co.jp; curr...@freebsd.org Sent: Wednesday, May 12, 1999 9:41 AM Subject: Re: cvs commit: src/sys/pci pcisupport.c On Wed, 12 May 1999 09:35:36 -0400, Rick Whitesel rwhite...@nbase-xyplex.com said: In general I believe that dynamic configuration of the system is extremely useful to both the development community and the user community. The development community has a much easier time if they can load / unload drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message 003001be9c88$2669b620$d3e4b...@xyplex.com, Rick Whitesel writes : Hi: Since newconfig appears technically superior, what are the issues that are hindering its acceptance? That we want to have no config at all. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Poul-Henning Kamp p...@critter.freebsd.dk Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:17:49 +0200 Message-ID: 5598.926522...@critter.freebsd.dk phk In message 003001be9c88$2669b620$d3e4b...@xyplex.com, Rick Whitesel writes phk : phk Hi: phk Since newconfig appears technically superior, what are the issues that phk are hindering its acceptance? phk phk That we want to have no config at all. That is too short an answer. What is the definition of config? Why do you want to remove it? Newconfig people is in agreement that old config should be removed. But newconfig is a different thing. Newconfig should be satisfactory for the purpose you remove the old config. Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
phk Since newconfig appears technically superior, what are the issues that phk are hindering its acceptance? phk phk That we want to have no config at all. That is too short an answer. No, it is complete and to the point. What is the definition of config? config(8) Why do you want to remove it? Why should we, as a 3rd millenium OS need a static config tool ? Tell me which future technology we will need to handle which will require static config ? We are working on FreeBSD as a OS for the future, not for the past. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
From: Poul-Henning Kamp p...@critter.freebsd.dk Subject: Re: cvs commit: src/sys/pci pcisupport.c Date: Wed, 12 May 1999 17:45:45 +0200 Message-ID: 5756.926523...@critter.freebsd.dk phk phk phk Since newconfig appears technically superior, what are the issues that phk phk are hindering its acceptance? phk phk phk phk That we want to have no config at all. phk phk That is too short an answer. phk phk No, it is complete and to the point. phk phk What is the definition of config? phk phkconfig(8) phk phk Why do you want to remove it? phk phk Why should we, as a 3rd millenium OS need a static config tool ? Newconfig is a *dynamic* configuration tool. Replacing the old config with newconfig is sufficient for your reason to remove config. Why do you refuse newconfig if it is a better framework for dynamic configuration? Tomoaki Nishiyama e-mail:tomo...@biol.s.u-tokyo.ac.jp Department of Biological Sciences, Graduate School of Science, The University of Tokyo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 17:45:45 +0200, Poul-Henning Kamp p...@critter.freebsd.dk said: What is the definition of config? config(8) Why do you want to remove it? Why should we, as a 3rd millenium OS need a static config tool ? For example, - To specify the drivers which is linked statically to kernel. As I said earlier, you cannot link console driver dynamically, If you do this, you cannot get error message when dynamic linking of the console driver failed. - There should be a way to inform kernel about inter module dependency dynamically. config(8) converts this information to a file which is kernel readable format. - There should be a way to inform kernel about mapping from device name to driver filename dynamically. config(8) converts this information to a file which is kernel readable format. - To achieve better performance in both UP and SMP cases. Proper SMP implementation requires fine grained locking, though this increases performance penalty in UP case. (e.g. Solaris shows this problem.) Thus, the way to specify options SMP is needed to use (static) source level and compiler level optimization. This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. The new-bus doesn't have these features. We are working on FreeBSD as a OS for the future, not for the past. Of course! We never should go back to the age of 1979 (i.e. before 4.0BSD). -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NAKAGAWA Yoshihisa y-nak...@nwsl.mesh.ad.jp writes: mechanism was unacceptable -- else we would have used it years ago. It is not formal core decision. On whose authority do you say that? Garrett is a core team member. Our policy in all areas has been that we'd rather do the Right Thing than follow the crowd. new-bus is wrong way. You are misunderstanding 4.4BSD mechanism. Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
My personal opinion is that static configuration is a subset of dynamic configuration. The eventual aim is to have a kernel which is a very sparse skelaton, with very few services and drivers loaded (in fact possibly none). At boot time, the needed drivers and services are loaded and configured (by the loader possibly). A driver that is already linked in is treated exactly as if it had been loaded, except that the loading is not required.. In this view, a statically linked in module is really just a 'pre-loaded' module. it still needs to be initialised. In this view, config(8) is reduced to being used to specify the preloaded modules (though that may be done after compilation by an external linker/loader) and to specify debugging options. A utility could exist that takes a skelaton kernel, and a specified list of kld modules and creates a composite loadable kernel, in which some modules are already present. I will admit that I have only looked a small amount at the new config that NetBSD uses, but it seemed to me that it produced far too much static information. This infrastucture would be duplicated by a dynamic loading framework. why have two such frameworks? If newconfig has removed all static device framework from the kernel then it is going the way I envision things moving. If it still does what the NetBSD one did when I looked at it, and produces a statically compiled framework of child devices and parent nodes, then that is one of the things we are trying to get away from. julian On Wed, 12 May 1999, Noriyuki Soda wrote: On Wed, 12 May 1999 09:35:36 -0400, Rick Whitesel rwhite...@nbase-xyplex.com said: In general I believe that dynamic configuration of the system is extremely useful to both the development community and the user community. The development community has a much easier time if they can load / unload drivers. As for the users, my rule of thumb is that a computer should never ask a human the answer to a question that it can find out for itself. I think this is especially true for configuration information. In addition, the need for dynamic system (re)configuration will only increase as features like PCI hot swap become the standard. Of course, I completely agree with you. The reason I prefer newconfig is it actually can support dynamic configuration better than the new-bus. All features which new-bus has can be implemented on newconfig, too. And, more. (See the description about on-demand dynamic loading in my previous post.) Furthremore, newconfig does static configuration better than the new-bus, and newconfig has a option which removes dynamic configuration entirely from kernel. New-bus apparently doesn't have this option. So, which is flexible ? :-) -- s...@sra.co.jpSoftware Research Associates, Inc., Japan (Noriyuki Soda) Advanced Technology Group. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Dag-Erling Smorgrav once wrote: As an outside observer, who does not understand most (all?) of the differences involved, I must say, this will have to be an unfairly uphill explanation. Because, using the style exemplified by PHK today, the newconfig people could say something like: Then explain to us why newbus is wrong * newbus is too far in the future and too dynamic (as opposed to PHK's statement, the (new)config is too old and too static -- no details) and why the 4.4BSD scheme is right. * newconfig(8) (as opposed to PHK's ``config(8)'') We want the FreeBSD to keep the stability and ... it has today. I'm not arguing with PHK here (nor anyone else), I'm just saying the brevity is not always a virtue... And for me, who reads -current mostly to keep the grip on the FreeBSD's directions and currents (hey!), this brief responses are NOT informative at all. Should they be? I'm not sure, but usually people taking a stand try to make themselves clear to all/most of the audience... Another mailing came through today was a lot more informative, though... Perhaps, the newbus vs. newconfig discussion can be summarized to both sides' satisfaction offline and then presented to the rest of the world? Or, the core team may just say: Because we said so (which I think was already done once) and stop discussing this... Respectfully, -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 12:12:54 -0700 (PDT), Julian Elischer jul...@whistle.com said: The eventual aim is to have a kernel which is a very sparse skelaton, with very few services and drivers loaded (in fact possibly none). This is also aim of newconfig, although console driver should be linked statically at least. Also, newconfig is aiming to provide freedom to choose whether a driver is linked dynamically or statically. At boot time, the needed drivers and services are loaded and configured (by the loader possibly). A driver that is already linked in is treated exactly as if it had been loaded, except that the loading is not required.. In this view, a statically linked in module is really just a 'pre-loaded' module. it still needs to be initialised. Yes. This is what newconfig on dynamic configuration does. But SYSINIT() of drivers is NOP in newconfig. Configuration framework does know all necessary operation to do, thus, there is nothing to do in SYSINIT(). Note that this is one of the key points to achieve best match policy for driver selection. In this view, config(8) is reduced to being used to specify the preloaded modules (though that may be done after compilation by an external linker/loader) and to specify debugging options. A utility could exist that takes a skelaton kernel, and a specified list of kld modules and creates a composite loadable kernel, in which some modules are already present. These modules should be specified by device name, or by feature name (i.e. attributes), oldconfig and newconfig use this model. But new-bus doesn't. It doesn't use device name and doesn't have the feature like the attributes of old/newconfig. It merely uses modules' filenames to specify modules which should be linked. This is one of the points what I think the new-bus is wrong. All configuration information should be specified by specification (device names and attribute names), not implementation (module filename). This is critical point to achieve on-demand dynamic loading and better compatibility. I will admit that I have only looked a small amount at the new config that NetBSD uses, but it seemed to me that it produced far too much static information. IMHO, that's wrong. What newconfig produces is only what really needed. If you think there is unnecessary information, probably it means that you don't really understand the usage of the information, yet. This infrastucture would be duplicated by a dynamic loading framework. This is wrong. The newconfig uses same information and same framework on both static and dynamic configuration. There is no duplication. why have two such frameworks? No. The newconfig is unified framework for both static and dynamic configuration. If a driver is static configurated, it's struct cfdata is generated by config(8), and it will be parsed by configuration framework (kern/subr_autconf.c). If a driver is dynamically configured, then kernel generated struct cfdata is used instead. Thus, there is no duplicated information between static and dynamic configuration in newconfig. Both configurations use same struct cfdata. The only difference is whether the generator of struct cfdata is config(8) or kernel. Do you call this duplication? Then you might not really understand what the configuration is, yet. Only config(8) reads files file (i.e. meta information) and it converts the information to binary format for kernel. So, there is no duplication about meta information parser. Yes, there is duplication about parser of configuration hint. But if you imagined that there is no need to implement the parser of configuration hint on userland. Then that's completely wrong. If config(8) doesn't have the parser of configuration hint, then you cannot determine which modules should be linked statically. The reason why new-bus doesn't have this duplication is new-bus doesn't have static configuration ability and it depends on oldconfig about static configuration. Actually, the one which has two framework is not newconfig, but new-bus. New-bus have it's own configuration framework for dynamic configuration and depends on oldconfig framework for static configuration. These frameworks are completely different, and as soon as you'd like to remove oldconfig, real problem of new-bus appears. As I said earlier, eventually new-bus will have to choose one of the following ways: [a] gives up static configuration. [b] uses ugly kluge (e.g. oldconfig remains forever). [c] reinvents features which already implemented on the newconfig. I'm not sure which is the way of the new-bus, in this point, though. If newconfig has removed all static device framework from the kernel then it is going the way I envision things moving. If it still does what the NetBSD one did when I looked at it, and produces a statically compiled framework of child devices and parent nodes, then that is one of the things we are trying to get away from. This is completely
Re: cvs commit: src/sys/pci pcisupport.c
Mikhail Teterin m...@aldan.algebra.com says: : : Perhaps, the newbus vs. newconfig discussion can be summarized to both : sides' satisfaction offline and then presented to the rest of the world? But didn't this already happen. I seem to recall a round of discussions that went on a week before the new-bus switch. The entire discussion ran around in circles with both sides discussing the technical merits of their implementation and both sides pointing out the problems in the other's implementation. Check the archives for the all the messages. My personal opinion? Well, I've been looking at the newconfig stuff and I think that they weakened their cause by not following -current. I've been trying the stuff out since they announced. But it does me no good to try and use it if it's out of sync with userland. Hey, I don't feel like looking at proc size mismatch messages. 8) I think the real shame is that both sides have good ideas and a lot of the newconfig stuff could work with newbus. However, instead of pooling our resources we've divided them and drawn a line in the sand. And I can't say that I personally feel that all of the questioning e-mails that have been going around the past day make me any more sympathetic to the newconfig cause. Core made a decision. Let's follow it. And before anyone throws any of that it's not traditional stuff out, please remember that no other BSD is using a boot loader like ours, NetBSD dropped Mach-VM for UVM, etc, etc, etc... My real fear is that this causes a rift which will lead to a split like the Net/OpenBSD one. At that point, both sides lose. --Jerry name: Jerry Alexandratos || Open-Source software isn't a phone: 302.521.1018 || matter of life or death... email: jalex...@perspectives.net || ...It's much more important || than that! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message 199905122048.qaa72...@misha.cisco.com, Mikhail Teterin writes: Or, the core team may just say: Because we said so (which I think was already done once) and stop discussing this... We did I think. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
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 and it was deemed desirable to have the SAME bus configuration code for both architectures. I don't see how any engineer in his right mind could argue that it made sense to have two, active and shipping ports to different architectures, each with its own bus code. Whether new-bus or newconfig is better was really, honestly not the issue so much as were the following two bullet points: 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? 2. Have we had a good history of communications between the people doing new-bus vs our history of communication with the newconfig people? 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. Before that, I had no idea that a Noriyuki Soda even existed. :-) This project essentially lives and dies by the strength of its ties to various developers. Given the fact that one body of code came from someone whom I *knew* we could work with, given a long history of working with them, and the other body of code came from someone who really only became known to myself and the rest of core when we saw your paper submission for USENIX (which I'm looking forward to attending, as I'm sure are many others in this discussion), well, it really wasn't a hard decision to make at all. Given the same set of factors, we'd make the very same decision today. 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! 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. 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. Many of the various developers in Japan really don't go much out of their way to let me or core in general know what's going on (though there are some notable exceptions) and it's like working in a company where a major part of it is entirely off-site and never calls you on the phone; anyone who's actually worked in such an environment knows exactly what I'm talking about and can appreciate the frustration of not knowing what a good chunk of your organization is up to. 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. What are you doing to fix it on yours? :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as best match, but first match. :-) Of course, dynamic configuration of newconfig solves this problem. It would appear that you don't understand the problem, as no configuration technique can telepathically determine in advance which new drivers you are going to load. BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in files file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. This is actually a major defect in the newconfig design; if the kernel doesn't already know about a device when it is built, it can never support it. The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. This is a transient implementation issue, the obsolecesnce of which is already manifest in the plans that have been laid for a device identifier to module to file lookup with the translation data _outside_ the kernel. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Noriyuki Soda wrote: NOTE: Please Cc: s...@sra.co.jp, I am not subscribing this mailing list, because I am a NetBSD user. :-) Aha! Now a few things are starting to make sense... It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. Hmm, I thought this cannot be done correctly on new-bus, because the new-bus kicks match/attach routine from SYSINIT(). It is apparent This has *never* been the case. All that the SYSINIT() system is used for is *registering* the drivers with the configuration engine. The actual configuration happens much later, in the i386 case the initial configuration is run from root_bus_configure() in i386/autoconf.c. that this fails in dynamic configuration case, because a potencial candidate of drivers which is dynamically loaded first always matches. This behaviour can not be called as best match, but first match. :-) Of course, dynamic configuration of newconfig solves this problem. Was this behaviour of the new-bus changed in -current ? Yes. Originally, the new-bus routines, apon finding a device, would offer it to the child drivers one at a time, and the first one that succeeded it's probe would then have it allocated to it. Now it uses a priority mechanism and the best-match driver wins. BTW, there are many fundamental design flaws in new-bus, so I don't think new-bus is comparable with newconfig, yet, even if priority probe is implemented. For example: - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is because critical information for configuration is represented in C source internally. e.g. The bus/device hierarchy information is embedded in DRIVER_MODULE() on new-bus. On newconfig, such information is represented externally in files file. Thus the information can be used in both static and dynamic configuration case. As a result, newconfig can support same configuration syntax in both static and dynamic configuration, the new-bus never can do it. Obviously there is some confusion over terminology or some misunderstanding somewhere, because we have been through this what seems like at least half a dozen times in private mail, and got nowhere at all. It seems to me that the basic difference is: We do not *want* static hardcoded configuration to be compiled into the kernel if at all possible. That requires kernel recompiles to simply change things like a port number for a ne2000 clone card. At the moment, our interim code means that things like 'ed0 goes at port 0x300, irq 11' etc is compiled in via the hints table, but we want that moved out into /boot/isa.conf or something like that ASAP and have loader(8) preload it for the kernel. That means that changing the configuration of a statically compiled kernel does not require a recompile or reconfigure. Most (but not all) of the mechanisms are in place to have this done totally dynamically from loader. For example, if you put this in your kernel config file: device ed0 in -current, you can then add this to /boot/userconfig_script: port ed0 0x300 irq ed0 11 iomem ed0 0xd .. and when the kernel boots, it will probe for ed0 on the isa bus, as well as attach to pci devices. (I have not actually tried this, I do not expect problems though). Abusing userconfig for this is a bit horrible though and is limited in it's capabilities. Everything else is in 4.0-current dynamic. Yes, there are weaknesses still, but that is because it isn't quite finished and is evolving still. As an example, it is not possible to hardwire (for example) de4 on some particular pci slot. This is an implementation problem, not a design problem. isa uses the mechanism already, and pci could too if anybody wanted it enough to write a handful of lines of code. - new-bus cannot support on-demand device driver loading, dynamic configuration for newconfig can do it, though. This is because new-bus doesn't have the way to represent meta information like a mapping from device name to driver filename. If new-bus have this, there is no need to specifiy kldload if_fxp, but just say I need fxp0, then configuration framework can automatically load fxp driver, if it is not loaded yet. This is how configuration works in both newconfig and even oldconfig (look at static kernel configuration file for oldconfig, there is the line device fxp0 which demands fxp driver to be loaded). File names shouldn't be in the kernel. You should not have to precompile a kernel to know that 'if_fxp' is loadable for some pci device id.. how can you do this with a 3rd party binary driver? For what it's worth, I *hate* the newconfig
Re: cvs commit: src/sys/pci pcisupport.c
Why should we, as a 3rd millenium OS need a static config tool ? For example, - To specify the drivers which is linked statically to kernel. As I said earlier, you cannot link console driver dynamically, If you do this, you cannot get error message when dynamic linking of the console driver failed. This presumes you don't have a fallback console driver. If you look at the current console driver architecture, you'll see that it's not too difficult to do this, nor would it be too difficult to componentise the various console driver components and simply link-time aggregate them. - There should be a way to inform kernel about inter module dependency dynamically. config(8) converts this information to a file which is kernel readable format. This is _the_ fundamental defect (as opposed to merely shortcoming) with newconfig. If I want to use a vendor-supplied driver module, I must first generate a kernel that knows about it. This is not dynamic by any definition of the word. KLD should (but does not, yet) obtain this information from the module as it is loaded. This is not a flaw in the KLD design, only its implementation. - There should be a way to inform kernel about mapping from device name to driver filename dynamically. config(8) converts this information to a file which is kernel readable format. This is a task for a PnP ID:module mapping database. See eg. sys/boot/common/pnpdata. It should most definitely _not_ be inside the kernel. - To achieve better performance in both UP and SMP cases. Proper SMP implementation requires fine grained locking, though this increases performance penalty in UP case. (e.g. Solaris shows this problem.) Thus, the way to specify options SMP is needed to use (static) source level and compiler level optimization. This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. This is, again, defective reasoning. For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
According to Mike Smith: This is actually a major defect in the newconfig design; if the kernel doesn't already know about a device when it is built, it can never support it. That would be so lovely, with a DEVFS too: Plug your Cool card into your pcmcia slot, and get the message on the sytem console that an unknown pcmcia card called Cool, made by CoolMakers, Inc. Damn... not even a generic driver wanted this card. Pull the card out and go for the web: # ftp ftp.a.cool.thing.com ftp get cool.tgz -- Downloading file. ftp quit -- Good bye. # install_driver cool.tgz -- Adding driver to driver database, and installing /modules/cool.ko! And at this point the kernel has not loaded the driver, but just been told there's a new driver around and for what cards and vendors it works, etc. This is done by a library call, or something, which does adds the driver to the database, and a syscall to update the kernel's already loaded database, or to get it to reload the database. Plug the card in again, and the kernel loads in cool.ko and probes the card, and created a /dev/cool, and everything works just fine. No reboot, no recompile, nada. *purr* /Mikael To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mike Smith once wrote: For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. What about kldload /modules/up/whatever.ko and kldload /modules/smp/whatever.ko and even kldload /debug-modules/up/whatever.ko [...] -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mikael Karpberg wrote: According to Mike Smith: This is actually a major defect in the newconfig design; if the kernel doesn't already know about a device when it is built, it can never support it. That would be so lovely, with a DEVFS too: Plug your Cool card into your pcmcia slot, and get the message on the sytem console that an unknown pcmcia card called Cool, made by CoolMakers, Inc. Damn... not even a generic driver wanted this card. Pull the card out and go for the web: # ftp ftp.a.cool.thing.com ftp get cool.tgz -- Downloading file. ftp quit -- Good bye. # install_driver cool.tgz -- Adding driver to driver database, and installing /modules/cool.ko! And at this point the kernel has not loaded the driver, but just been told there's a new driver around and for what cards and vendors it works, etc. This is done by a library call, or something, which does adds the driver to the database, and a syscall to update the kernel's already loaded database, or to get it to reload the database. Plug the card in again, and the kernel loads in cool.ko and probes the card, and created a /dev/cool, and everything works just fine. No reboot, no recompile, nada. *purr* This is exactly the way new-bus works. You merely load the driver, and the configuration engine reruns the probe for unclaimed devices on smart busses automatically. Of course, kicking off a generic driver when a more specific driver is loaded is a different problem... I have not looked to see if this is supported. It should not be a significant problem if it is not yet implemented. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Mike Smith once wrote: For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. What about kldload /modules/up/whatever.ko and kldload /modules/smp/whatever.ko and even kldload /debug-modules/up/whatever.ko [...] This is just too painful for words. If people _really_ want to do this, you'd put all of the drivers into one .ko file and only partially link it (ie. just link the one module). But I do not think we want this at all; the obvious selectors so far are: - UP vs. SMP - BPF - Invariants That's eight versions of eg. a network driver already. I cut off BPF as an issue a little while back by putting stubs for the BPF routines into the kernel when BPF isn't actually built; we want to do the same things for the other functionality types. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 14:53:31 -0700, Jordan K. Hubbard j...@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
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 15:09:05 -0700, Mike Smith m...@smith.net.au said: It would appear that you don't understand the problem, as no configuration technique can telepathically determine in advance which new drivers you are going to load. Apparently you misunderstand newconfig. :-) There is compiled format of files file which path is known by kernel. - newconfig can cope with both static configuration and dynamic configuration. new-bus can handle dynamic configuration only. This is actually a major defect in the newconfig design; if the kernel doesn't already know about a device when it is built, it can never support it. Apparently you misunderstand newconfig, too. :-) See above. The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. This is a transient implementation issue, the obsolecesnce of which is already manifest in the plans that have been laid for a device identifier to module to file lookup with the translation data _outside_ the kernel. In other words, that is not compatible with the BSD way where FreeBSD and BSDI and NetBSD and OpenBSD already probed. It is actually true that FreeBSD becomes Linux. -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999 15:09:05 -0700, Mike Smith m...@smith.net.au said: It would appear that you don't understand the problem, as no configuration technique can telepathically determine in advance which new drivers you are going to load. Apparently you misunderstand newconfig. :-) There is compiled format of files file which path is known by kernel. Aha. And the kernel has to read this file? How does it read it if it's loading eg. the disk driver that it will be using to read the disk? Why does the information have to be in this file? Why not put it in the drivers themselves? The way on new-bus will cause compatibility problem when OS is upgraded, because the implementation (filename) may be changed between versions and versions. This is a transient implementation issue, the obsolecesnce of which is already manifest in the plans that have been laid for a device identifier to module to file lookup with the translation data _outside_ the kernel. In other words, that is not compatible with the BSD way where FreeBSD and BSDI and NetBSD and OpenBSD already probed. There is no BSD way anymore. The BSD way was developed to support Unibus on the early Vax systems. It's not clear to you that newbus does draw on ideas from newconfig. But newbus is a lot more than _just_ a new set of names for the probe/ configuration functions; it's a complete driver interface architecture. Newconfig is a good semi-static semi-dynamic configuration framework, but that's all it is. It is actually true that FreeBSD becomes Linux. This is a childish troll, especially coming from you. If for no other reason, this is an excellent reason _not_ to be working with your team. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
It is actually true that FreeBSD becomes Linux. Comments like this will only ensure that you wind up in kill files, mine included. They add nothing to the discussion. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
It seems Mike Smith wrote: It is actually true that FreeBSD becomes Linux. This is a childish troll, especially coming from you. If for no other reason, this is an excellent reason _not_ to be working with your team. Oh boy... Could we end this now please ?? We've made our decision, and thats it, period, end of story. -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
It is actually true that FreeBSD becomes Linux. Comments like this will only ensure that you wind up in kill files, mine included. They add nothing to the discussion. I see, sorry. -- soda To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
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.
Re: cvs commit: src/sys/pci pcisupport.c
NetBSD people have not the same stated aim of completely eliminating config, so for them it made more sense to migrate to config.new. I think it's also safe to say that because of NetBSD's interest in supporting 'older' hardware, it would be suicide to use a truly dynamic scheme since much of the old hardware doesn't have the necessary capabilities to do dynamic configuration. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
NetBSD people have not the same stated aim of completely eliminating config, so for them it made more sense to migrate to config.new. I think it's also safe to say that because of NetBSD's interest in supporting 'older' hardware, it would be suicide to use a truly dynamic scheme since much of the old hardware doesn't have the necessary capabilities to do dynamic configuration. Yeah, like a sparcstation-1. It really can't do dynamic reconfiguration at all. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999 08:17:52 +0900 (JST), Noriyuki Soda s...@sra.co.jp said: Have you ever asked to newconfig people? No, no one of core members who takes charge of kernel part contacted to newconfig people, ever. It's your responsibility to communicate with us, not the other way around. The only way for your views to be even considered is for you to make them known BEFORE the die is cast. I can't speak for any of the other developers, but I personally get 200-400 messages a day, and unless you speak up and -- most importantly -- inform everyone REGULARLY of the progess you make, your views will not be considered. 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. The issue hasn't been raised in -core. Doug built the system, and refined it in FreeBSD/alpha with encouragement from many of us. Last November, I set up a public mailing-list, announced it to the world several times, and used it to coordinate the further development. Peter and I developed the i386 part of the mechanism long after the Alpha side was well-entrenched. Peter and Doug continue to enhance it. The only discussion -core ever had on the topic was ``ok, when should we bring this into current?''. Once those milestones were met -- about four days, as I recall -- we threw the switch. By that time, a de facto decision had long since been made, since it's a well-known principle of volunteer projects that the people who do the work (like Doug with the Alpha port) are the ones who really make the decisions, by choosing which projects to spend their time on. 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. There is no such person as ``the one of core who takes charge of kernel part''. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999, Noriyuki Soda wrote: It is actually true that FreeBSD becomes Linux. It is truely unfortunate that it comes to this.. however it has always been to me a source of great frustration to me that Linus was able to implement a driver framework that allows a very dynamic loading of modules and drivers. FreeBSD is designing the next logical step beyond this. Config.new is a stepping stone in an evolution. In our case we have pretty much all decided that the 'goal' for this next phase of evolution is the complete dynamic configuration of the kernel. The old BSD way was simply a step in the evolutionary chain. There is nothing inherrently 'right' about it. It reflects the limitations of the technology at that time. config.new did not change the level of the technology, but rather, re-arrange it a bit. The newconfig crew have made improvements to config.new to better support dynamic loading, but after a lot of discussions (face to face in many cases) the statements have been agreed by nearly all the FreeBSD people involved. 1/ a module that is pre-loaded should be treated the same as one that is 'post' loaded as much as possble. 2/ A module should not rely on any prior knowledge of it's existance to function correctly. 3/ A module should be able to supply it's own default configuration information, and also be able to access additional information that may be availabel at load time. 4/ The loadable module may implement an entirely new class of modules (e.g. a new bus type) of which there was no previous knowledge. 5/(not agreed by all) In a perfect world, /dev/ entries would reflect reality, and the sysctl name space would also do so. 6/ all the usual desirable aspects of loadable modules (e.g. unloadability) apply. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
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. I'm not sure this was adequate reason to postpone the decision either, and like I said, Peter had the time to do it and it wasn't clear when he was next going to have the time again. In a volunteer project, you have to sometimes move when people are ready to move or you'll miss your window of opportunity. 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. No, it doesn't mean that, it means that assessing technology isn't JUST a question of looking at code since code, by its very nature, changes rapidly - if you cannot see that then this conversation is likely to be just about as productive as arguing with a first-year high school student on the subject. Evaluating technology is a question of deciding which code is both superior AND has the best longevity, longevity being a more difficult equation which combines the history of the developers involved and how effective your communications with them are. In this case, I don't believe communications are effective and that kills newconfig just as thoroughly as having the code be a total mess; I think I've pointed this out several times now. Have you ever asked to newconfig people? No, no one of core members who takes charge of kernel part contacted to newconfig people, ever. As I told you before, I didn't even know you *existed* until I saw your paper. How am I supposed to contact you guys if I don't even know you're alive? There are presently over 5 billion people on the planet and I can't call each and every one of them regularly to find out whether or not they're working on FreeBSD. :) The time for you guys to have contacted core (or, even better, -hackers) to let us know of your existence was back when you started your project, not at the point where you were so far along that papers were being published. Don't expect people to contact YOU since, as I've said, people generally don't even know you exist until you tell them. 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. You don't get chances in this business, you MAKE chances. :) Can you write Japanese ? If no, why do you blame the one who cannot write English. I'm very fortunate to have had my mother tongue chosen as the defacto international language of computer science and don't think I don't realize my degree of good fortune. Had Japanese or French been chosen instead, you may rest assured that I'd have put the time necessary into learning those languages as well. I'm certainly capable of learning a foreign language when and if it's necessary, don't think I'm an english bigot here or anything (sprechen Sie Deutsch? :), but I'm also a realist and if the prevailing language of communication is language X then I expect everyone concerned to just learn language X and I don't particularly care how difficult it is, Just Do It and don't whine about it is my motto. To be more specific, I expect you and anyone else in Japan who wishes to communicate with an international audience to learn english and, should I ever live in Japan and need to speak frequently with Japanese speakers, you may rest assured that I'll learn Japanese, however hard that process might be. We're supposed to be intelligent people here and if we can't learn to speak others languages if and as necessary then maybe we're not as intelligent as we think. :-) Please point out the general annoyance from Japan. I have seen a lot of arguing about technical merits and decisions made by the core team, but I have yet to see any constructive comments about fixing the communication problems which led to this decision. Focusing on the negative and not the positive counts for general annoyance in my book since people generally don't do that unless they're annoyed. I'm sure your command of english is not so deficient that you're unable to make positive suggestions - I thought Japanese people had more cultural difficulty in saying no than in saying yes :-) 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. See above. 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. I know, I've been to Akihabara and I've even taken pictures of the books in question (http://www.freebsd.org/~jkh/japan/report/dayfive-books.jpg). Don't think that I underestimate the importance of the Japanese market - if I did, do you think I'd be taking time out *right before USENIX* to fly over
Re: cvs commit: src/sys/pci pcisupport.c
Mikael Karpberg wrote: That would be so lovely, with a DEVFS too: Plug your Cool card into your pcmcia slot, and get the message on the sytem console that an unknown pcmcia card called Cool, made by CoolMakers, Inc. Damn... not even a generic driver wanted this card. Pull the card out and go for the web: # ftp ftp.a.cool.thing.com ftp get cool.tgz -- Downloading file. Pah. kldload http://www.cool.com/drivers/freebsd/cool.ko Perhaps kld modules should have some kind of signature verification to support such a thing. That'd be so great. The FreeBSD installation floppy could delay most device probes until after you've set up networking (so you'd need some network drivers on the floppy) then grab all the latest versions of the other drivers it wants to complete the install from www.freebsd.org... - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, Mike Smith wrote: This option should automatically select the appropriate sources which is compiled into kernel, according to the source is needed only in UP case, or only in SMP case, or both. This is what oldconfig and newconfig does. This is, again, defective reasoning. For a usable dynamic architecture, loadable modules need to be compiled to support both UP and SMP architectures simultaneously. Thus the locking primitives need to be conditionalised at _runtime_. Or, alternately, at load time by choosing the appropriate subsystem to match the hardware. It is clearly possible to arrange that lowest-common-denominator code is initially loaded and then replaced with a configuration optimized version. The configuration at compile time is in the Makefile to cause, when appropriate, the various versions to be compiled from common code. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Thu, 13 May 1999, Noriyuki Soda wrote: 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. I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general agreement beforehand about it. This has always had one response. No. We don't give apriori blank check agreement to stuff like that, because we don't know which way it's going to go, and if the final product isn't going where the developers (which means generally core, but not completely) then it's gong to be rejected. This has caused bad feelings sometimes, but it's stopped some folks from trying to hi-jack FreeBSD, and force it to go where one person wants it to go; it forces FreeBSD to be a group decision. So, how do big projects get done, then? The first point being brought up is true, no one wants to invest hugely in a project, just to see the work rejected. The way we get around that is by communicating, regularly and thoroughly, about the design and implementation of the project. Good communications means that we don't get into fights, and FreeBSD goes where the group wants it to go, not where some small set of interests want to hi-jack it. I am NOT saying that you or your group want to hijack anything, but the process DOES stop folks from doing that, and it's in fact already stopped that from happening more than once in my memory. Communications is a good thing, not something to be embarrassed about. Describing communications as by which spokes loudly is missing the point. Loudness hasn't the least to do with it. Regularity and clarity, getting the message across, is what's important. That is where your group has misunderstood the process. By going off on your own, and doing all that coding without any input, you established a reputation for not being willing to work together. Someone with a proven track record of communicating regularly was chosen. Not from a technical standpoint, but from a managerial standpoint, why does this surprise you? Don't offer technical arguments, this is not a technical issue. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general agreement beforehand about it. There is a big difference between a general agreement that some feature or other is a good thing and a blank check of approval for code changes. These seem to get confused all the time. One example of this problem, in the opposite direction of the one you mentioned, is the old, If you think that's such a good idea, why don't you code it and submit it? This is equally unhelpful. If it's a bad idea, why should anyone code it? If it's a code idea, why does it matter who codes it, as long as it's coded well? DS To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
On Wed, 12 May 1999, David Schwartz wrote: I have to comment on this, it's too outrageous. Several times in the past, folks have written in and asked, if they wrote some particular piece of software, would it get committed. They said that it was a large undertaking, and that they wouldn't undertake it, unless there was general agreement beforehand about it. There is a big difference between a general agreement that some feature or other is a good thing and a blank check of approval for code changes. These seem to get confused all the time. One example of this problem, in the opposite direction of the one you mentioned, is the old, If you think that's such a good idea, why don't you code it and submit it? This is equally unhelpful. If it's a bad idea, why should anyone code it? If it's a code idea, why does it matter who codes it, as long as it's coded well? Because if it's a day of coding, you should just do it. If it's a 3 month project, you don't waste such time, and you should communicate it. The time factor is judged by folks who code for a living, and maybe it's a little high, but not too bad. I haven't seen this rule misapplied, but it's possible some may think so; they are most likely mis-estimating the scope of the work involved. I have a 3 day project in mind; I'm just going to code it (once I get finished with classes in 2 weeks); if it gets turned down, I'm a big boy, I'll get over it. If it was longer, I would bore you all with it. It's not, and I won't. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: cvs commit: src/sys/pci pcisupport.c
Because if it's a day of coding, you should just do it. If it's a 3 month project, you don't waste such time, and you should communicate it. The time factor is judged by folks who code for a living, and maybe it's a little high, but not too bad. I haven't seen this rule misapplied, but it's possible some may think so; they are most likely mis-estimating the scope of the work involved. Believe it or not, good ideas can even come from people who can't code at all, and the ideas are just as good. Slapping these people down just ensures they don't contribute in the future. Now if their ideas genuinely are bad, you are more than welcome to slap them down as much as you wish. If that means they don't contribute more bad ideas in the future, so much the better. Heck, it even may save you the idea of having to explain why the bad idea is, in fact, bad. But if it's such a good idea, why don't you code it? doesn't fall into any of these categories. It's one of those that's what you think type arguments that serves as an excuse to ignore the merits of the other side's case. DS To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On whose authority do you say that? Garrett is a core team member. I heard from Asami-san, Any voting not yet for new-bus. After that, new-bus patch merge is decided. new-bus merge is core decision, but drop static configration, ... these are not yet voted. Then explain to us why newbus is wrong and why the 4.4BSD scheme is right. Because, you are misunderstanding 4.4BSD scheme (and newconfig). -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message 199905120901.saa04...@srapc288.sra.co.jp Noriyuki Soda writes: : This reminds me another ugly kluge in sys/pccard/i82365.h: : #define PCIC_INDEX_00x3E0 : #define PCIC_INDEX_1(PCIC_INDEX_0 + 2) : This is the way what some clever FreeBSD people saids right to : Nakagawa-san, though Nakagawa-san never agreed that it is right, and : rather likes the newconfig way like below: : pcic0 at isa? port 0x3e0 : pcic1 at isa? port 0x3e2 : pcic* at pci? : pcic* at isapnp? : It is apparent which is better and cleaner for me. But perhaps you do : not agree with me. :-) This is a horrible kludge (eg what is in FreeBSD right now is bogus and truely evil). I like the way that newconfig attaches things, which is why I'm currently reworking the pccard code. Actually, I'd rather junk most/all of the code that is there now. The code was good for the time, but now it has been overtaken by events. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
In message 199905122048.qaa72...@misha.cisco.com Mikhail Teterin writes: : Perhaps, the newbus vs. newconfig discussion can be summarized to both : sides' satisfaction offline and then presented to the rest of the world? It is my impression that the language barrier has made this discussion harder to follow. In all the discussions I've seen, both here and elsewhere, it seems like the two sides are talking past one another. That's one reason I really like Doug's idea for a meeting at Usenix (sadly, I'm unable to attend). This isn't a simple issue, and there are many subtle advantages and disadvantages to both systems which are hard to convey in email... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
On Tue, 11 May 1999, NAKAGAWA Yoshihisa wrote: I was thinking of doing this, the same as alpm and intpm: case 0xdevid: #if NUHCI 0 return NULL; #else return VIA blah USB controller; #endif It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Doug Rabson wrote: On Tue, 11 May 1999, NAKAGAWA Yoshihisa wrote: I was thinking of doing this, the same as alpm and intpm: case 0xdevid: #if NUHCI 0 return NULL; #else return VIA blah USB controller; #endif It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. And a very useful mechanism it is. Which is why I implemented priority ordered probes in -current. For the sake of the thread, this got committed a day or two ago, and these hacks have been replaced with a low priority match. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
For the sake of the thread, this got committed a day or two ago, and these hacks have been replaced with a low priority match. Why do you use another mechanism of 4.4BSD ? Don't loss time and loss inter-operability between other BSDs. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
Because 4.4BSD got it wrong. It has always been the belief of the FreeBSD Project's management that 4.4's totally-static configuration No! 4.4BSD mechanism is good. Newconfig already support dynamic configuration and *good* module support (not yet merge newconfig CVS). mechanism was unacceptable -- else we would have used it years ago. It is not formal core decision. Our policy in all areas has been that we'd rather do the Right Thing than follow the crowd. new-bus is wrong way. You are misunderstanding 4.4BSD mechanism. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
I was thinking of doing this, the same as alpm and intpm: case 0xdevid: #if NUHCI 0 return NULL; #else return VIA blah USB controller; #endif It depends on old-config, so poor mechanism. newconfig already implimented best match probe/attach. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
