Ignatios Souvatzis wrote:

> using the normal device open / close paths has the advantage that the
> change of the "in use" database is always in sync with the actual use,
> and can't be accidentally (programming error/omission) be forgotten, and
> without additional locking issues create - or am I wrong? 

you are correct - it does make it easier, given the current state of the
code. however:

> We'd have to add sysdisk_open()/_close() to all normal open/close calls
> in appropriate places, and use some locking to make sure that the open
> state and the "don't let anybody else open it" state don't get out of
> sync?

if we add a parameter to VOP_OPEN (which, I think, does not scale) then
there's going to be a massive amount of changes and code to adapt. if we
make the 'mode' bits take an additional flag, it'd be a hack (does
something like 'FREAD|FWRITE|FSYSTEM' make sense?) and won't scale --
and the number of changes would be the same as if we'd just use
sysdisk(9).

another problem we did not yet address -- could very well be a non-issue
but we don't know yet -- is how the VOP_OPEN scheme would integrate with
subsystems that simply don't VOP_OPEN.

a large part of that problem can be easily solved with the addition of
something like the fileop scope. since that would already hook in all
of those places, the changes will be minimal.

either way: I'm not yet convinced the VOP_OPEN way is possible, and is
elegant enough. I guess we'll have to wait for move people to voice
in... :)

-e.