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

Do you mean M_* malloc type here?
I think we don't have to introduce it to "files*" files or configuration
framework. See below.

> > 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.

But our consensus is that depending GNU tools is bad thing. Isn't it? :)

> (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.

Since C99 standard defines "inline" and "long long" in it's feature,
NetBSD MI part no longer heavily depends on GNU toolchain.
Yes, NetBSD MI part may still somewhat depend on GNU toolchain,
but adding dependency on GNU toolchain is, a step backward, IMHO.

> (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.

I'd say critical kernel feature should not depend on any object
file format :)

> (4) there are workarounds even if none of the above can work for a
>     specific case.

If there are other ways to do this, why don't you use the way ALWAYS?

Why do we have to depend on GNU toolchain even if there are other ways
to implement the feature?

> > - 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,

Almost same functionality can be achieved by either "files.*" files 
or C source about device major number handling.

But there is one benefit in the way of "files.*" files.
If a user do not need dynamic configuration (e.g. embeded application,
for example), the way of "files.*" file works almost completely same
with current way of conf.c (Only difference is that conf.c is 
automatically generated.)
In other words, "files.*" has less overhead in completely static
configuration case.

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

Extracting major number from "files" files is far more easier than
extracting it from C header files.
Since configuration framework should know the major number (and bus
locater informations and other informations in "files.*" files),
describing it in "files.*" file is natural way.
Of course, major number should be able to be assigned dynamically,
but that is not hard.

> 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.)

We don't have to use the linkerset feature of GNU toolchain for this.
For example, we can simply use string address as malloc type.
	In <sys/malloc.h>:
		extern char M_FREE[];
		extern char M_MBUF[];
		extern char M_DEVBUF[];
			:
	In <kern/malloc.h>:
		char M_FREE[] = "free";
		char M_MBUF[] = "mbuf";
		char M_DEVBUF[] = "devbuf";
			:
In this way, AFS source can define M_AFS by itself like follows:
		char M_AFS[] = "afs";

Why do we have to depend on the linkerset feature of GNU toolchain,
even if there is trivial (and simple, and less overhead) way to do it?
--
soda