Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
=Comment: #0=================================================
Emily J. Ratliff <emilyr.com> - 2008-09-16 18:20 EDT
1. Feature Overview:
Feature Id: [201598]
a. Name of Feature: FCP - HBA API followup for upstream
b. Feature Description
This item comprises a rework of the existing HBA API library and kernel functions such that:
a) The new library fits into the common libHBAAPI approach as a vendor specific library
b) The kernel functions are reworked to allow easier integration into upstream kernels.
2. Feature Details:
Sponsor: zSeries
Architectures:
s390x
Arch Specificity: Both
Affects Kernel Modules: Yes
Delivery Mechanism: Direct from community
Category: Kernel
Request Type: Kernel - Enhancement from Upstream
d. Upstream Acceptance: Accepted
Sponsor Priority 1
f. Severity: High
IBM Confidential: no
Code Contribution: IBM code
g. Component Version Target: lib-zfcp-hbaapi-2.0
3. Business Case
Enablement of system management applications to use zFCP infrastructure. The result is improved
usability of the zFCP infrastructure.
4. Primary contact at Red Hat:
John Jarvis
jjarvis
5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf.com, Boeblingen 49-7031-16-3978
Technical contact(s):
Gonzalo Muelas Serrano, gmuelas.com
IBM Manager:
Thomas Schwarz, t.schwarz.com
------- Comment From sven.schuetz.com 2009-03-19 04:31 EDT-------
Hi,
to your questions. HBA API consists of two parts:
1.The "wrapper" or "common" library. That is the one from
http://sourceforge.net/projects/hbaapi which is requested in the first bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=489929
2. The so called vendor library, which is the actual implementation.
That's the one the open-fc guys requested in the second bugzilla.
https://bugzilla.redhat.com/show_bug.cgi?id=489962
Our library is a vendor library just like in 2.
http://www.ibm.com/developerworks/linux/linux390/zfcp-hbaapi-2.0.html
It just contains a version of hbaapi.h in case the wrapper/common library is not present. During the configure stage you can chose if the wrapper is present (hbaapi.h from our package is not needed) or if the wrapper is not present (hbaapi.h from our package will be needed).
For your question if the open-fc approach will work for us:
In theory or in the future, yes. Today, no. If everything would be perfect, we could use one approach where we have one library which uses standard interfaces. Today, both the open-fc and our approach are to a little extend platform specific. They use some PCI libraries to get certain information which are not available on System z. We use some system z specifics which are not present on other platforms.
The functionality both libraries offer is the roughly the same.
My suggestion would be:
As the wrapper library is designed to have multiple vendor libraries living together on one system, let's include both - the wrapper library and both of the vendor libraries - theirs and ours. They can coexist nicely. For future releases we should try to merge our approaches so that we only have one vendor library left (that would mean to eliminate platform specifics in the current approaches). I will get in contact with the open-fc guys to bring that forward.
------- Comment From mgrf.com 2010-06-17 16:50 EDT-------
This feature is verified on R6 snapshots
Set feature to "verified" Thx
Comment 11releng-rhel@redhat.com
2010-11-10 20:12:56 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.