Date: Fri, 28 Dec 2007 18:03:00 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: marcelm@juniper.net Cc: embedded@freebsd.org Subject: Re: ocpbus(4) Message-ID: <20071228.180300.-432832706.imp@bsdimp.com> In-Reply-To: <20071228.163257.756911359.imp@bsdimp.com> References: <20071228.150443.-924279995.imp@bsdimp.com> <4FA37AAF-8113-44DE-8FF9-5BB203188912@juniper.net> <20071228.163257.756911359.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20071228.163257.756911359.imp@bsdimp.com>
"M. Warner Losh" <imp@bsdimp.com> writes:
: No, this is more or less the gist of it. The type and id
: can be chosen in any way we like, including using the type
: as the id.
I just went out to shovel the drive way (a hazard of living in
Colorado) and the above stuck in my head. One could also make the
type/id a string and then the probe routines become something like:
static int
at91_ssc_probe(device_t dev)
{
if (strcmpy(device_get_name(dev), ocpbus_get_devname(dev)) != 0)
return (ENXIO);
device_set_descr(dev, "SSC");
return (0); /* or some other negative value */
}
without the need to have the actual enumeration... This would be more
complicated than setting the name when the child was added, but it
would have the advantage of being overrideable if necessary.
I'm just worried that the file defining an enum would soon become a
big source of integration failures when code designed for these
devices is integrated back into the tree. Maintaining big lists in
the tree is something that newbus was designed to avoid. The
artificial IDs seem to be reintroducing that, which is why I've had
the negative reaction that I've had to it.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071228.180300.-432832706.imp>