linux-kernel - Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea

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]

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/