At 03:22 25-09-02, David Boyes wrote: >I haven't looked at the code yet, but unless it has to force a reevaluation >of the special device mapping nodes when a entry is removed, it seems >like inserting a non-DASD placeholder entry in the device table in a >"not-available" state in place of the previous DASD entry would be >safe enough to avoid oops'es (assuming that everything umounted >cleanly, etc). The next "add" operation could replace that no-op in >preference to a new entry, which would keep the device structure from >expanding w/o limits.
I believe the culprit is that the added device goes in the next free minor nunmber. An easy way to make the process deterministic could be to specify both parameters when adding a device (like we add CP-own volumes) and complain when the entry is not free. And while we're at it, it would be helpful to have a userspace program to do it and return a completion code (and maybe even do the CP LINK as well). For those who run in LPAR and believe in the dasd= as protection, they run with an exposure when they return a volume this way. Rob
