On Jan 17, 9:37pm, Robert Elz wrote:
}
} Date: Sun, 17 Jan 2016 14:49:23 +0100
} From: Manuel Bouyer <bou...@antioche.eu.org>
} Message-ID: <20160117134923.ga2...@asim.lip6.fr>
}
} | I mean, vnconfig -l (without other arguments) has been showing available
} | devices for a long time:
}
} Yes, I know, and agree, it has ... but that is only possible if it
} is possible to rationally enumerate the available devices. When there
} were a fixed (small) number, it made sense. That is no longer the case.
}
} Do you really want it to list 4 billion free vnds ?
Obviously not, unless somebody was silly enough to create 4
billion /dev entries, which is likely to cause other problems.
} Using what is in /dev is incorrect (always was) as /dev is just a
} convention (and particularly is not reliable when chroots are in use).
It may be "just a convention", but it is also the best
approximation.
} | this is a major behavior change, which may well break existing setups.
}
} True, but there is little alternative, unless you'd like to return to
} the pre cloning days. It can stay as it is now, listing free devices
} up to the highest used (but that really is hard to explain and makes
} little sense, and as you have observed, is not very reliable) or I guess
} we could just add a
}
} for (n = highest_found; ++n < highest_found + 4; )
} printf("vnd%d: not in use\n", n);
}
} after it finishes printing, just to list a few more free ones.
}
} | You remove existing and working functionality to fix a marginal backward
} | compatibility issue ?
}
} Not marginal at all, and backwards compat has always been one of NetBSD's
} prime objectives.
}
} | But removing this functionality is breaking
} | backward compat, in a much more important way.
}
} Actually, I doubt it. I suspect some other issue is the problem here,
} and the change to vnconfig -l is just confusing the issue.
Possibly.
} | we *are* already running an up to date vnconfig, dammit !
}
} Ah, OK, I misread your description (I thought you meant one from 7.0)
}
} | not until this problem is fixed. Breaking XEN3_DOM0 support is a real
} | problem.
}
} Agreed, we need to work out what is causing that vnconfig to fail.
}
} | Unfortunably it's transient.
}
} That does make it difficult to debug.
}
} | After a view vnconfig manipulations the
} | problem is gone for me (and vnconfig -l again show all devices,
} | used or free).
}
} All 4 billion of them?
}
} | cd_ndevs is now at 8 (checked with gdb against /dev/mem)
}
} Then at some stage you had vnd7 configured.
}
}-- End of excerpt from Robert Elz
