On Tue, Sep 24, 2002 at 06:22:50PM -0400, Post, Mark K wrote: > That's kind of hard to answer. As I mentioned in my original note, I don't > have a really good feel for how likely the lack of this is to cause a > problem, just a vague feeling that this isn't quite right.
For the people running on bare metal, I'd say it's fairly important. It's a pretty significant data integrity exposure if you can scramble a volume without warning, and there are enough people who seem to be making a case that Linux on bare metal is a good idea for some specific apps that the ability to fully tolerate dynamic config is probably a major step to making those apps practical (SAP in 64-bit mode comes to mind immediately). On the other hand, I'd rather see the effort put into certifying SAP with Linux on VM and letting VM handle the whole problem than worrying about bare metal anyway, so Your Milage May Vary. 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. > So doesn't the question become whether the requirement is important > enough to warrant a redesign? How important is this requirement, Mark? > Romney > > > >The designer of the code feels that this would disturb the mapping of > >virtual address to minor number and make it unpredictable. I would > >immediately agree that it could have been designed differently, but > >it was not.
