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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 19 Feb 2013 15:32:44 +0200
From:	Tomas Winkler <tomas.winkler@...el.com>
To:	Samuel Ortiz <sameo@...ux.intel.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg KH <gregkh@...uxfoundation.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host

On Wed, Feb 13, 2013 at 11:39 AM, Samuel Ortiz <sameo@...ux.intel.com> wrote:
>
> On Tue, Feb 12, 2013 at 11:09:00PM +0000, Arnd Bergmann wrote:
> > On Tuesday 12 February 2013, gregkh@...uxfoundation.org wrote:
> > > >
> > > > > Please let's find something that makes both hw and Linux happy
> > > > I still believe it makes sense to use mei_device for what we add to the MEI
> > > > bus. I'd be fine with mei_bus_device as well, but that would somehow look
> > > > a bit awkward. Greg, Arnd, any preference ?
> > >
> > > "mei_device" works the best for me.  Tomas, what you think of as a "MEI
> > > Device" really is a "MEI Controller", it bridges the difference between
> > > the PCI bus and your new MEI bus, so you will need to start thinking of
> > > these things a bit differently now that you have created your own little
> > > virtual bus.
> >
> > Yes, I agree. mei_bus_device would also work as the name for the controller,
> > but not for the devices attached to it IMO.
> Tomas, I propose to switch to mei_controller instead of mei_host and keep the
> mei_device name for the devices we attach to the MEI bus.
> Does that work for you ?
>

The issue is that when we added our virtual bus we haven't gave up on
/dev/mei backed by mei_device
This is the interface, defined in linux/mei.h  which user space
applications use to connect to ME Clients within ME device.
Any ME client can be connected through this interface and we have few
legacy applications running for few years that use this interface so
we are not going to break them.

What we've done now is we added a virtual bus so also in-kernel
applications/subsystems can more naturally connect to the ME Clients,
this connection is client specific.  So the device that connect to the
bus is not an mei device but mei client device hence the name I've
proposed mei_cl_device.

Does it make sense?


Thanks
>
> Cheers,
> Samuel.
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
> --
> 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/
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ