Am I understanding correctly that you could not define a new single address, build the dasd there, set it off, detach it and attach another new device at the same address, and then set the address back on?
This would seem to be a good way to handle moving several volumes through a virtual machine, if it'd work... ---- Robert P. Nix internet: [EMAIL PROTECTED] Mayo Clinic phone: 507-284-0844 200 1st St. SW page: 507-255-3450 Rochester, MN 55905 ---- "In theory, theory and practice are the same, but in practice, theory and practice are different." > -----Original Message----- > From: Rob van der Heij [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, September 25, 2002 1:31 PM > To: [EMAIL PROTECTED] > Subject: Re: /proc/dasd/devices > > 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
