[Pkg-pciutils-discuss] Re: [PATCH] Restore lspci -m formatting on machines with domains

[Martin Mares]

Hello!

> Some users are unhappy about the format of lspci -m changing with
> multiple domains.  This patch (which should apply on top of the patch
> you sent on March 13th) lets us choose how to display domains when in
> machine readable mode.  If the user specifies -D and -m, we display
> in the domain:bus:slot.fn style.  If -D isn't specified, but domains
> are detected, we add either Domain: <number> for verbose or -D<number>
> by default to the end of the information about the device.  Any script
> reading the output of lspci -m should cope with additional fields being
> added, but I can't blame them for not anticipating domain numbers being
> added on the start.

Sorry, but NACK. You are again changing the -m format in a way which is
incompatible with the previous stable releases.

If some script parses lspci -m output and it doesn't support domains,
it will surely break on machines with domains. With your change, it will
break silently and just produce bogus output, while with current stable
pciutils, it will at least scream loudly.

I agree that the last patch we've made also breaks compability in
a subtle way -- it sometimes prepends "0000:" even for entries which
don't need it.

So I think the right solution is to partially revert to the previous
behavior and always omit the "0000:" in -m mode (unless forced by -D).

> You can see more discussion of the lspci -m issue at:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=251828

Unfortunately, the argument here:

| It would be nice if lspci provided an option, says -X, to output ids in 
| XFree86 format:
| 
| 1) That would make easier to write XFree86Config
| 2) That would avoid dexconf breaking each time lspci -n format
| change, like recently, when it got prepended the domain.

is utterly wrong:

(a) parsing -n output (or anything which is not -m) is unreliable
    and I promise I will change the format in the future :)

(b) if PCI domains exist in the real world and dexconf
    doesn't know how to cope with them, it's a bug in dexconf regardless
    what the format used by lspci is. I've tried to make as few hassless
    as possible by defaulting to the domain-less format where applicable,
    so that dexconf has really stopped working only on machines with
    domains, where it was bound to fail anyway.

(c) when -X was added, dexconf just changed to failing silently on such
    machines. This makes no sense.

> http://lists.alioth.debian.org/pipermail/pkg-pciutils-discuss/2006-March/000005.html
> http://lists.debian.org/debian-x/2004/05/msg00910.html

| The issues lspci -X was attempting to solve was that 'lspci -n' format
| has changed in the past, breaking the xserver-xfree86.config script,

A clear bug in the script, -n was never guaranteed to be stable.
(I've just added an explicit warning to the lspci man page.)

| and that 'lspci -n' is hard for humans to convert to -X format.

I don't believe it's hard for people who are able to write the
XF86Config themselves (if it is, then maybe add a note to the XF86Config
man page which describes how to do that).

As for people using the automated scripts for generating XF86Config,
they shouldn't care about lspci anyway.

So I still don't see any reason for adding the -X switch -- it just
solves a single corner case and more so, it solves it incorrectly.

				Have a nice fortnight
-- 
Martin `MJ' Mares   <mj at ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Weather forecast for tonight: dark.