Date: Thu, 13 May 1999 06:24:12 +0800 From: Peter Wemm <peter@netplex.com.au> To: Noriyuki Soda <soda@sra.co.jp> Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pci pcisupport.c Message-ID: <19990512222414.E2DDA1F58@spinner.netplex.com.au> 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
Noriyuki Soda wrote:
> NOTE: Please Cc: soda@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 0xd0000
.. 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 way:
====
2) To load/unload drivers, in /dev directory, do
mknod config c 80 0
For example, to load `ne3 at pci0 dev ? func ?', do,
dconfig --load --driver=ne --unit=3 --bus=pci --busunit=0 \
--locator=-1,-1 --flags=0
To unload,
dconfig --unload --driver=ne --unit=3 --bus=pci --busunit=0 \
--locator=-1,-1 --flags=0
To load/unload `ne4 at isa0 iobase 0x280 irq 9' do,
dconfig --load --driver=ne --unit=4 --bus=isa --busunit=0 \
--locator=640,0,0,0,9,-1,-1,0,1,0 --flags=0
dconfig --unload --driver=ne --unit=4 --bus=isa --busunit=0
--locator=640,0,0,0,9,-1,-1,0,1,0 --flags=0
====
What on earth is the locator stuff for? Why can't you use plain text?
How does 'iobase 0x280' become '640,0,0,0,9,-1,-1,0,1,0'??
> - new-bus heavily depends on oldconfig which is known to be obsolete
> and machine dependent (look at usr.sbin/config/config.y, there are
Machine dependent? The only thing machine dependent about config(8)
is that for the "alpha" machine, it uses files.alpha, while for "i386",
it uses "files.i386". There is *NOTHING LEFT* that is machine dependent.
> 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
We already do this, from the ioconf.c on a recent build:
struct config_resource fdc0_resources[] = {
{ "at", RES_STRING, { (long)"isa" }},
{ "port", RES_INT, { IO_FD1 }},
{ "drq", RES_INT, { 2 }},
{ "irq", RES_INT, { 6 }},
};
#define fdc0_count 4
This is a bit of a hack at the moment and is just used to initialize
the runtime resource database where the hints are kept.
> - bus/device hierarchy information which can be accessed
> from static configuration
This is not required to be in a config program, the drivers know it.
> All of above facts are already told to one of the FreeBSD core
> members, just before core members officialy decided to choose new-bus.
> I do not know why core members decide new-bus, though.
config.new was rejected years ago. The 4.4BSD config.new was static,
device/bus/etc relationships were compiled into the kernel statically
and not extendable. I realize you are busy rewriting config.new into
newconfig and dconfig, but those are *not* 4.4BSD any more.
> It seems FreeBSD already start to choose [b]. Please look at changes
> in revision 1.67 of sys/i386/isa/npx.c. It hardcodes magic number 13,
> instead of the value gotton from configuration framework. It is
> interesting that even this doesn't use #define NPXIRQ 13. :-)
Since it seems to bother you so much, I will add the four missing lines of
code should somebody wish to break PC compatability.
> This reminds me another ugly kluge in sys/pccard/i82365.h:
> #define PCIC_INDEX_0 0x3E0
> #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. :-)
I prefer just:
device pcic0 at isa? port 0x3e0
device pcic1 at isa? port 0x3e2
in a static kernel config file, or:
pcic0 port 0x3e0
pcic1 port 0x3e2
in /boot/isa.conf. Or:
# sethint pcic0 at isa port 0x3e0
# sethint pcic1 at isa port 0x3e2
# kldload pcic.ko
.. to load pcic to look at isapnp, pci and those two isa ports. or:
# kldload pcic.ko
.. to load pcic and look at pci and isapnp if present.
If the driver writer decides there is a significant amount of code in
bus dependent modules that it is worth splitting pcic.ko itno pcic_isa.ko,
pcic_pci.ko, pcic_pnp.ko and pcic_common.ko, then this works best:
# kldload pcic_pci.ko
.. to load the pci and common parts, and cause a reprobe.
Note that loader(8) looks at the bios PNP and PCI lists and will likely
use a table to preload likely drivers based on the device id's it's
found. This won't be perfect since loader(8) won't easily be able to
run the match routines from the .ko files in the pre-kernel execution
environment, but newconfig wouldn't be able to do this either since the
newconfig match routines are compiled into the drivers too.
Cheers,
-Peter
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?19990512222414.E2DDA1F58>