linux-kernel - Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to mod

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110825023832.GA6131@kroah.com>
Date:	Wed, 24 Aug 2011 19:38:32 -0700
From:	Greg KH <greg@...ah.com>
To:	KY Srinivasan <kys@...rosoft.com>
Cc:	"gregkh@...e.de" <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"virtualization@...ts.osdl.org" <virtualization@...ts.osdl.org>,
	Haiyang Zhang <haiyangz@...rosoft.com>
Subject: Re: [PATCH 003/117] Staging: hv: Add struct hv_vmbus_device_id to
 mod_devicetable.h

On Wed, Aug 24, 2011 at 09:51:00PM +0000, KY Srinivasan wrote:
> > It would allow you, in your probe function, to do something different
> > depending on the guid that the probe function was matching on.  So you
> > would not have to check the guid again to do that, just use the data
> > pointed in that void pointer and away you go.
> > 
> > As an example, look at drivers/usb/class/cdc-acm.c, the acm_ids[]
> > variable which uses the driver_info field to contain a quirk for the
> > device.
> 
> Ok; this makes sense. But I currently don't have any quirks to support!

That was just an example.

> The util driver is not even a driver in the true sense. I made it a driver and
> added the probe function just to support auto-loading with the vmbus ID space
> that I am trying to implement here - the probe function does nothing.

As you can tell, I'm trying to say that is wrong :)

the hv_util.c driver should have a pointer in each of the driver_info
that describes what it is, and then in the probe function, you use that
to hook up the correct things needed.

None of this hard-coded mess like you currently have.

Trust me, you want that pointer, put it in, and if you never use it,
I'll buy you a beer.  But if I send you a patch using it, well...

> > > I looked at the usage of this in PCI and it appears to be for supporting
> > > dynamic  IDs for existing drivers.
> > 
> > No, that's exactly wrong.  dynamic ids play havoc with this pointer,
> > making some drivers not be able to handle dynamic ids because they rely
> > on it for some driver-specific information to be passed in it, which
> > dynamic ids can not handle.
> > 
> > Oh, have you remembered to turn off dynamic ids for these devices?  Or
> > do you support them properly?
> 
> I don't support dynamic IDs. What would I need to do to turn it off.

Ah, nevermind, that is something that busses add in their core if they
want it.  I added it for PCI and USB, maybe I should move that to the
driver core so that others can get it automatically one of these days...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/