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]
Message-ID: <20130211134612.GO20996@sortiz-mobl>
Date:	Mon, 11 Feb 2013 14:46:12 +0100
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Tomas Winkler <tomas.winkler@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [char-misc-next 01/11 V2] mei: bus: Initial MEI bus type
 implementation

Hi Arnd,

On Mon, Feb 11, 2013 at 11:50:26AM +0000, Arnd Bergmann wrote:
> On Sunday 10 February 2013, Samuel Ortiz wrote:
> > > >  
> > > >  /**
> > > > + * mei_bus_client
> > > 
> > > I don't really understand this structure, please explain it better.
> > This is a structure that links the MEI bus client pointer passed to the driver
> > with the actual ME client. It also allows the ME driver to implement
> > technology specific ME protocol through the send/recv hooks.
> 
> I think part of the confusion is that this is what in other subsystems
> is called a device, not a client. I believe I'm still confused in the
> same way that Greg is.
Ok, I understand where the confusion comes from now. Yes, for most of the
other subsystems, this is a device. Initially I tried to keep the MEI bus code
as little intrusive as possible and I didn't want to rename mei_device to
something else.

 
> You already have a 'struct mei_device', which refers to the PCI device
> that owns the bus, and has clients attached to it. While it may be
> a little confusing to people that already worked with the current
> mei code, I think it would help to rename the existing 'mei_device'
> to 'mei_host' or something else that feels appropriate, and introduce
> the new structure as 'mei_device' derived from 'struct device', again
> matching what most other subsystems do.
I understand, and I agree it would make sense. As we're aiming at having this
patchset merged during the next merge window, would it be ok to have this
renaming phase as a follow up patch ?

> Similarly, you can then rename 'mei_bus_driver' to 'mei_driver' to fit
> that logic, since I would consider a 'bus_driver' to be something
> that is responsible for the entire bus, not just for one device.
That would make sense as well, and I can have this done through patchset v4.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ