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 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 problems are all well understood and
EASY TO FIX.
in page 502.
As this shows, it is apparent that newconfig can cope with
dynamic configuration, why do new-bus people thought that
newconfig cannot deal with dynamic configuration, and
reinvent configuration framework?
It is obvious that they do not know about newconfig enough,
(their terminology like "ivar" shows this fact).
[d] shifts the all the problems to users
(e.g. see compatibility problem mentioned above)
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.
P.S.
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. :-)
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. :-)
--
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
