Date: Fri, 15 Sep 2006 16:47:20 -0400 From: John Baldwin <jhb@freebsd.org> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 106148 for review Message-ID: <200609151647.20432.jhb@freebsd.org> In-Reply-To: <200609152039.28868.hselasky@c2i.net> References: <200609151417.k8FEHSFx098273@repoman.freebsd.org> <200609151243.50388.jhb@freebsd.org> <200609152039.28868.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 15 September 2006 14:39, Hans Petter Selasky wrote:
> Maybe a missing "if (*dmd->dmd_devclass == NULL)" here. It is not a big
> problem. All the USB probe / attach code is currently executed under Giant,
> so there should not be any race condition. "devclass_find_internal()"
> allocates memory with M_NOWAIT, and will not sleep and cause problems.
Well, as long as new-bus eventually has locking to handle concurrent driver
adds (probably just a big sx lock around the whole thing) it will be fine.
> > typedef struct devclass *devclass_t;
> >
> > Basically, passing a devclass_t into DRIVER_MODULE() just gives you a
> > pre-intialized pointer to your devclass. The devclass's aren't bound to
> > that devclass_t though, they are bound to the name. Thus if you have:
> >
> > static devclass_t foo_class, bar_class;
> >
> > static driver_t foo_driver {
> > "foo", ...
> > };
> >
> > static driver_t bar_driver {
> > "foo", ...
> > };
> >
> > DRIVER_MODULE(..., foo_driver, foo_devclass, ...);
> > DRIVER_MODULE(..., bar_driver, bar_devclass, ...);
> >
>
> Yes, but I cannot set the "devclass" to "NULL" ? That will panic according
to
> the "driver_module_handler()" function ??
Yes. I actually want to just remove it altogether because for almost all
drivers it's worthless and just wastes space (granted, all of 1 pointer in
the data seg of each driver).
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609151647.20432.jhb>