Date: Wed, 12 May 1999 15:09:05 -0700 From: Mike Smith <mike@smith.net.au> To: Noriyuki Soda <soda@sra.co.jp> Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <199905122209.PAA01534@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 12 May 1999 18:01:35 %2B0900." <199905120901.SAA04493@srapc288.sra.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
> NOTE: Please Cc: soda@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. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905122209.PAA01534>