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

Reply via email to