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: <200802011537.52003.ossthema@de.ibm.com>
Date:	Fri, 1 Feb 2008 15:37:51 +0100
From:	Jan-Bernd Themann <ossthema@...ibm.com>
To:	Christoph Raisch <RAISCH@...ibm.com>
Cc:	Greg KH <greg@...ah.com>, akpm@...ux-foundation.org,
	Jan-Bernd Themann <THEMANN@...ibm.com>,
	linux-kernel@...r.kernel.org, Nathan Lynch <ntl@...ox.com>,
	ossthema@...ux.vnet.ibm.com, sam@...nborg.org,
	Sudhir Kumar <skumar@...ux.vnet.ibm.com>,
	Joachim Fenkes <FENKES@...ibm.com>
Subject: Re: [2.6.24-rc6-mm1]Build failure in drivers/net/ehea/ehea_main.c

On Tuesday 29 January 2008 15:20, Christoph Raisch wrote:

> These pci functions corresponds to a
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port0
> and
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port1
> 
> The busdriver currently does not find out, how many ports are in a
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1.
> This is up to the hardware specific driver responsible for ehea or ehca.
> Think of a PCI card where the PCI busdriver
> can not determine how many ports are implemented on the card.
> 
> How should this be mapped to /sys ?
> 
> Should we try to "flatten" the ports to something like
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1_port0
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1_port1
> ...which means physical hierarchy information would look a bit strange,
> but could be the simpler one.
> 
> The way which corresponds to the hardware would be to
> improve the kernel in such a way that hierarchical ports also wortk for
> netdev_register.
> Then we could keep this structure
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port0
> /sys/bus/ibmebus/devices/789D.001.XXXXXX-P1/port1
> 
> 
> So, which way should we try?
> 
> Gruss / Regards
> Christoph Raisch
> 
> 
> 

Hi,

so far we fould 2 options. The ibmebus manages (add / remove)
ONLY eHEA adapters (not ehea ethernet ports).
All ethernet ports have to be added / removed by the eHEA device driver when
an eHEA adapter has been added by the ibmebus as a new device.
This means the sysfs-links "driver" for our eHEA ethernet devices (ports) 
are not automatically generated.

Option 1)
- We can create then ourselves. Therefore we would 
  need two functions exported and included in the proper header file:
    - static int driver_sysfs_add(struct device *dev)
    - static void driver_sysfs_remove(struct device *dev)

Option 2)
- we just leave it out which would be inconsistent with
  other pci based ethernet adapters.

So far we prefer option 1. 
Do you see any other ways we should investigate? 

To resolve the build issue I've posted a first patch to remove the
old sysfs links. 


Regards, 
Jan-Bernd & Christoph
--
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