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: <200801181016.49128.ossthema@de.ibm.com>
Date:	Fri, 18 Jan 2008 10:16:48 +0100
From:	Jan-Bernd Themann <ossthema@...ibm.com>
To:	Greg KH <greg@...ah.com>
Cc:	Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	sam@...nborg.org, Christoph Raisch <raisch@...ibm.com>
Subject: Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c

Hi,

sorry for answering so late, I'm only tracking netdev and ppc mailing list.

On Thursday 10 January 2008 18:34, Greg KH wrote:
> > The structure device_driver(in device.h) has a member struct driver_private which
> > contains the member kobj (according to drivers/base/base.h).
> > But in device.h struct driver_private has been declared localy and 
> > neither defined nor included from base.h.
> > So my effort to use driver->driver_private->obj also does not work.
> > (I am surprised from where do you access the struct device_driver)
> 
> That is because a driver should not be accessing such a field.
> 
> And especially not in this manner, why would this driver be creating a
> symlink that has already been created by the driver core?  This whole
> thing can just be removed with no problems.  Can you try just removing
> the ehea_driver_sysfs_add and ehea_driver_sysfs_remove functions to
> verify this as I don't have the hardware present to test it out.

The eHEA driver tries to orginize its sys-entries as close as possible to
other ethernet drivers. Each eHEA NIC has multiple ports which is not that
common in PCI. This means that each port is represented by a subdirectory
which has not the "driver" sys-link, only the root directory has.
Some tools expect to have this driver link in each port directory.
That is the reason why this link is created manually.

Are there any other ways to create this link?

Regards,
Jan-Bernd Themann + Christoph Raisch
--
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