Date:	Tue, 27 May 2014 17:35:05 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	"Winkler, Tomas" <tomas.winkler@...el.com>
Cc:	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Usyskin, Alexander" <alexander.usyskin@...el.com>
Subject: Re: [char-misc-next 3/3] mei: add WPT second mei interface

On Tue, May 27, 2014 at 11:47:44PM +0000, Winkler, Tomas wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@...uxfoundation.org]
> > Sent: Wednesday, May 28, 2014 01:07
> > To: Winkler, Tomas
> > Cc: arnd@...db.de; linux-kernel@...r.kernel.org; Usyskin, Alexander
> > Subject: Re: [char-misc-next 3/3] mei: add WPT second mei interface
> > 
> > On Tue, May 27, 2014 at 09:42:19PM +0000, Winkler, Tomas wrote:
> > > > > +/* PCH devices MEI 2 interface */
> > > > > +const struct mei_cfg mei_me_pch_2_cfg = {
> > > > > +	MEI_CFG_PCH_HFS,
> > > > > +	.mei_id = 1
> > > >
> > > > That's going to be a recipe for disaster.  Have the MEI core allocate
> > > > the id numbers as things are registered, don't have the individual
> > > > drivers create their id.
> > >
> > > I'm don't think can ensure the enumeration order.
> > 
> > You should not be relying on the order to get anything right.
> > 
> > > This is per device not per driver configuration structure.
> > > Each pci device is actually just  another head to one MEI device but heads are not
> > equal the name/id matters
> > > Yes I assume it looks odd at the first glance, anyhow we are open to any
> > reasonable suggestions
> > 
> > Just dynamically allocate the numbers like all other subsystems do?
> >
> > Then userspace can open the device nodes it cares about, it should be
> > able to somehow tell what device is what somehow, right?  If not, you
> > are doing something wrong with the interface as you can't rely on minor
> > numbers.
> > 
> 
> The only way for user space to distinguish among interfaces is the same way as driver does by looking for device id. 

What's with the lack of line-wrapping?

Anyway, why does userspace care?  If it wants to look at the device id,
then just look at the symlink to the device id of the device node.  Then
you don't care what the device node is named / numbered.

> The assignment of the device name/id is pretty much static in the HW.
> Now the same device id database from the driver has to be copied to
> the udev rules or equivalent  and kept in sync.

What?  No.  Why would you want to do that?  Why does it matter what
order these devices are connected?  Are they talked to in different
ways?  Are they different "classes" of devices?  What are they and why
aren't they just "interchangeable" as far as userspace cares?

> Most importantly all the legacy user space just opens /dev/mei  so I
> wanted to leave /dev/mei (not /dev/mei0) to be assigned always to the
> first mei head and to not break existing user space. 

That's fine, I have no objection to that.

> Can you be a bit more specific on why we cannot depend on minor
> numbers and default naming rules, what is the scenario that will
> break? 

Why is the kernel picking a name for these with a specific minor number
in it?  What makes this different from a random tty device where you
don't care what the minor number is, you just care about where is it
connected so you look at the other things "around" it (pci path, vendor
id, etc.) and create a deterministic name from with a symlink, if you
care, with udev / mdev.

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/

Powered by blists - more mailing lists