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>