tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Attaching to an attribute



On Fri, Dec 08, 2017 at 09:56:10 +0800, Paul Goyette wrote:

> On Fri, 8 Dec 2017, Valery Ushakov wrote:
> 
> > This, however, still highlights a problem.  How can a module device
> > driver attach wsmouse as a child regardless of how the kernel is
> > configured.
> 
> The device driver module does all appropriate initialization, which includes
> config_init_component().  That ends up calling parent "bus" drivers (or
> other attachment attributes drivers) to "rescan", which causes the parents
> to attach any potential new child.
> 
> So, if the configuration has "wsmouse* at wsmousedev?" all drivers offering
> the wsmousedev attribute are told to rescan...  If the configuration has
> specific parents (ie, not attributes), then each of those parents get the
> rescan command.
> 
> Note that config(1) doesn't handle
> 
> 	pseudoroot <attribute>
> 
> You need to list each possible parent, even if the attachemt is via an
> attribute:
> 
> 	pseudoroot ums?
> 	pseudoroot xxxms?
> 
> 	wsmouse* at wsmousedev?

This is not what I'm trying to do.

I have a module (vboxguest) that provides a device driver and that
driver wants to attach wsmouse as its child.  As far as I can tell, in
the tree the uatp(4) module is doing exactly that.

When the module driver calls config_found_ia(self, "wsmousedev", ...);
autoconf will look for all drivers that can attach at "wsmousedev" and
will next try to match the pspec's parent driver with this driver.

In x86 configs all wsmouse attachments are to specific drivers, not to
the wildcard attribute.  So config_search_loc() calls cfparent_match()
with vboxguest as parent and pspecs like:

  { "wsmouse", "spic", DVUNIT_ANY }
  { "wsmouse", "pms", DVUNIT_ANY }
  { "wsmouse", "ums", DVUNIT_ANY }
  ... etc

all these pspecs has parent driver specified and so none of them will
match vboxguest, and so wsmouse fails to attach.

The only way I could make it attach is by manually sneaking in an
extra attachment entry in module's cfdata.

  static int wsmousedev_loc[] = { 0 };
  static const struct cfparent wsmousedev_pspec = {
      "wsmousedev", NULL, 0
  };

  // and then in cfdata
  { "wsmouse", "wsmouse", 0, STAR, wsmousedev_loc, 0, &wsmousedev_pspec },

Note that if i mention wsmouse* in the module ioconf file, config(1)
will arrange for wsmouse driver to be registered too, which fails with
EEXIST and so does module initialization.

-uwe


Home | Main Index | Thread Index | Old Index