Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 254048 - Review Request: biosdevname - udev helper for naming devices per BIOS names
Summary: Review Request: biosdevname - udev helper for naming devices per BIOS names
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: FE-ExcludeArch-ppc64, F-ExcludeArch-ppc64 F-ExcludeArch-ppc
TreeView+ depends on / blocked
Reported: 2007-08-23 20:04 UTC by Matt Domsch
Modified: 2012-02-09 11:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-09-21 18:39:17 UTC
matthias: fedora-review+

Attachments (Terms of Use)
proposed patch to the specfile (deleted)
2007-08-24 06:52 UTC, Harald Hoyer
no flags Details | Diff
revised patch (deleted)
2007-08-24 06:56 UTC, Harald Hoyer
no flags Details | Diff

Description Matt Domsch 2007-08-23 20:04:07 UTC
Spec URL:
biosdevname in its simplest form takes an kernel name name as an
argument, and returns the BIOS-given name it "should" be.  This is necessary
on systems where the BIOS name for a given device (e.g. the label on
the chassis is "Gb1") doesn't map directly and obviously to the kernel
name (e.g. eth0).

Comment 1 Matt Domsch 2007-08-24 02:23:08 UTC
I'm going to ExclusiveArch %{ix86} x86_64 ia64 and put a comment in the spec.

# SMBIOS and PCI IRQ Routing Tables only exist on these arches.  It's
# also likely that other arches don't expect the PCI bus to be sorted
# breadth-first, or of so, there haven't been any comments about that
# on LKML.

Marking this as blocking ppc and ppc64 ExcludeArch trackers.

Comment 2 Harald Hoyer 2007-08-24 06:52:21 UTC
Created attachment 172394 [details]
proposed patch to the specfile

my patch to let it build and install

Comment 3 Harald Hoyer 2007-08-24 06:56:50 UTC
Created attachment 172396 [details]
revised patch

Comment 4 Matthias Saou 2007-08-24 08:53:20 UTC
I just saw the announcement on the poweredge-list. This looks neat! I'll start
the review of this package.

Comment 5 Matthias Saou 2007-08-24 09:01:08 UTC
One immediate question : The resulting binary package depends on the shared which is in /usr/lib*/ and not /lib*/ so for Harald's patch needs
further changes to get the package to be able to do anything useful before /usr
is mounted.

Comment 6 Harald Hoyer 2007-08-24 09:13:05 UTC
right... either move libsysfs or make biosdevname static...

Comment 7 Matthias Saou 2007-08-24 09:20:45 UTC
(In reply to comment #6)
> right... either move libsysfs or make biosdevname static...

Yup. Current libsysfs-devel still provides the static library, so that would be
an option, but surely moving libsysfs would be cleaner. From the spec file
comment, it seems like the static libsysfs should already have been used, but it
hasn't been. That comment kind of confuses me overall, though :

# some distros won't have a static lib version of libsysfs, which
# would be needed to generate these .so files

I guess the comment is (at least partially) wrong, since even with the static
libsysfs available, the shared one is used.

Comment 8 Kay Sievers 2007-08-24 10:02:55 UTC
Matt, please just get rid of libsysfs usage. It's an outdated, unmaintained and
useless library.

Comment 9 Matt Domsch 2007-08-24 11:45:09 UTC
OK, I'll nuke the libsysfs usage.  That comes from my use of code from the 
pcmciautils-014 package, but for what is used there, it's easy enough to 
replace with standard C lib calls.

The code can already build a static binary, called biosdevnameS.  I just 
disabled this for now, but if we really need this called before /usr is 
mounted (e.g. inside an initrd or NFS-root or something) it's easy enough to 
build again.

Comment 10 Matt Domsch 2007-08-24 18:06:54 UTC
I've applied Harald's RPM spec patch moving this into /lib* and /sbin.  I
removed the libsysfs dependency completely.  I am building, but not RPM
installing, the static copy of the app, in case we decide we need it later.

This builds and runs on Fedora 7 and OpenSUSE 10.3 beta.  rpmlint results are
empty.  The SuSE and Fedora spec files are identical now, and hopefully they can
stay that way and I can nuke one.

Version 0.2.2 is posted now to and
pushed into the git tree.

Comment 11 Matthias Saou 2007-08-27 08:45:28 UTC
Looking better. Two more questions :
- What is the point of creating a shared library which is used only by the
binary from this package? Since the .so symlink is wiped out, nothing will be
able to link against it, so not using the static version of the binary only
makes us loose the time it takes to run ldconfig, right?
- The dynamic file list confuses me. Some distros would have something else than
the .so.0 and .so.0.0.0 files without changing the spec file? (btw, the comment
regarding libsysfs above it needs updating now ;-))

Comment 12 Matt Domsch 2007-08-27 11:38:17 UTC
it's purely a "convenience" library, meaning I want to separate all the table
parsing and lookups from the "frontend" command line application and it's
parsing.  I don't at this point expect other applications to use the
"convenience" library, but at some point in the future, if I clean up the API
and there's good reason something else needs those functions, it can be done.

Comment 13 Matt Domsch 2007-08-27 12:08:08 UTC
The reason for the dynamic file list is that some versions of some distros don't
compile libpci.a with -fPIC, so it can't then be included in a shared library. 
There's autoconf code to detect this and automatically sets enable_shared=no
which results in no* being created.  (OpenSUSE and SLES are
this way right now, as were earlier versions of Fedora).  This spec builds
Fedora, RHEL, OpenSuSE, and SLES at this point, the dynamic file list being the
only magic involved (to add, or not, depending on existance of those .so.*
files, appropriately).

I'm not tied to the idea of the convenience library.  If it's really that ugly,
it can disappear too.

And yes I can fix the spec file comments.

Comment 14 Matt Domsch 2007-08-27 21:26:08 UTC
I decided to nuke the libbiosdevname.* stuff in upstream, it isn't really 
needed and only causes confusion.  Updated SRPM and spec posted.

Comment 15 Matthias Saou 2007-08-30 15:37:11 UTC
Spec and resulting package look good to go. I'll just need to runtime test the
actual binary package.

The %description could maybe be changed from :

"takes an kernel name"


"takes a device kernel name" (or "takes a kernel device name"?)

Comment 16 Matt Domsch 2007-08-30 16:05:35 UTC
Spec %description changed to say "takes a kernel device name".

Comment 17 Matthias Saou 2007-08-30 16:39:10 UTC
Okay, package approved! Seems like my workstation's BIOS doesn't override much,
though (Precision 490), but the package didn't break anything either ;-)

Comment 18 Matthias Saou 2007-09-12 11:13:07 UTC
Ping? Matt, still around? :-)
Please go ahead and request CVS branches creation, import, build, and close ;-)

Comment 19 Matt Domsch 2007-09-17 14:00:54 UTC
I haven't forgotten about this, but I've got a showstopper problem before I am 
comfortable doing a build.  I spoke with Kay about this last week, and he 
wanted an enhancement to udev-114 to let biosdevname suggest the new name 
without overriding the values in 70-persistent-net-names.  I haven't made the 
enhancement to udev yet, so that's what's blocking me on this...  Hopefully 
this week I can spend some time on it.

Comment 20 Matt Domsch 2007-09-21 16:13:25 UTC
New Package CVS Request
Package Name: biosdevname
Short Description: Udev helper for naming devices per BIOS names
Owners: mdomsch,mebrown
Branches: FC-6 F-7 EL-4 EL-5
InitialCC: harald
Cvsextras Commits: yes

Comment 21 Kevin Fenzi 2007-09-21 16:26:56 UTC
cvs done.

Comment 22 Matt Domsch 2007-09-21 18:39:17 UTC built successfully.

Note You need to log in before you can comment on or make changes to this bug.