Noriyuki Soda <soda@sra.co.jp> writes:
> UCHIYAMA Yasushi, MAEKAWA Masahide and Atsushi FURUTA are working
> on this issue. (including dynamic device driver loading and dynamic
> meta information -- files file -- treatment)

so, one interesting question is how you do this for all possible types
of data without ridiculously polluting the 'files' files.

for instance, right now, there's a special file-system keyword.  it's
used for two purposes that i'm aware of: root FS checking, and
creating the fs list.  i see the latter as, basically, cruft in
'config'.

yes, you can generate driver information via config.  but then, at
what cost to the configuration language and internals of config?

I don't see you proposing a similar solution for malloc types, or, for
instance, line disciplines or other place where it would also be
appropriate, though esp. w.r.t. the former it _is_ an issue, and a
solution which doesn't solve the problem isn't an adequate solution.


> They are planning different approach about this.
> Rather than describing cdev/bdev <-> device name mapping in C source,
> They are going to describe this in "files.*" (and dynamic loading
> "files.*" information)

I've not really looked at their implementation, so cannot criticise it.


> In this way, 
> - we don't have to make a hack which depends on GNU toolchian.

(1) like it or not, the GNU toolchain is much more portable and widely
    used a 'host tool' than our config is.

(2) it's pretty much a prerequisite for using our sources now,
    anyway.  you could probably get around it, but you'd suffer for
    doing so, and you'd have to port it eventually anyway.

(3) in fact, for modern object file formats, e.g. ELF, it just
    exploits features of the format, not as much features of the
    tools.  any tools for those formats which are sane will provide
    (perhaps syntactically different, but provide nonetheless) access
    to those features.
    
(4) there are workarounds even if none of the above can work for a
    specific case.


> - we don't have to describe same information in 3 places
>   (conf.c, MAKEDEV, "files.*" file for devices which may become root device).
>   cdevsw/bdevsw will be created by configuration framework
>   automatically (even if dynamic loading case) via the "files.*"
>   file iformation.
>   MAKEDEV also can be created from the "files.*" file and MAKEDEV
>   templates.

(1) we already should be specifying in files what can become root by
    using the 'disk' and perhaps 'ifnet' class.  need for major is
    bogus, though, and shouldn't be in the config files (and that can
    probably be eliminated either way).  In other words,

(2) MAKEDEV information could be created from the MD header, and
    templates.


OK, so, even assuming that the way i suggested isn't the right way to
do devsw replacement -- and i'm not convinced of that -- how do you
plan to solve, at the very minimum, the M_* malloc type issue?

as i've pointed out before, the best evidence that i can think of is
the fact that M_AFS is in our list of malloc types.  (The need to hack
malloc.h is one of the issues that's actually been presented to me as
a problem by people who i've asked.)


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.