> Introducing a new error code that is only exposed to a constrained set > of consumers may work, but I think introducing a new error code for > open(2)/spec_open() of an ioretired device would be a bad idea.
Why? Nothing could've been inferring anything special about ENXIO since it's returned in may cases beyond I/O retire. BTW, it wouldn't just be for open() -- many other system calls can lead to S_ISFENCED() checks. > Also, it sounded to me like the bug leading to the style-2 > inconsistency is that ioretire may have missed checking retired state > in the spec_associate_vp_with_devi() code path associated with DL_ATTACH. > If that is the case, we should file a CR for that. Seems plausible. -- meem _______________________________________________ fm-discuss mailing list fm-discuss@opensolaris.org
