Re: Devd event from GEOM?

In message <Pine.NEB.3.96L.1050125145130.3036B-100000_at_fledge.watson.org>, Robert Watson writes:

>However, many device nodes can only be opened "exclusively", security
>event auditing will occur, or opening will have side effects.  Opening a
>device node to find out what type it is currently seems not to work very
>well and/or be undesirable.

I was mostly for the benefit of dd(1) as far as I recall.

>> Welcome to the world of dynamic hardware. 
>
>While you could imagine user space controlling the stepping of exposed
>device nodes to prevent inconsistency, it's similarly easy to imagine the
>potential feedback loops, deadlocks, etc, that would occur.  Given that we
>already mediate use of the /dev name space, I think we have to be able to
>rely on sane use of that space: if ad0 is replaced almost immediately by
>ad0, it shouldn't really matter which you get, at least in as much as that
>the consumer can figure out if it happened (should it matter, which I
>suspect in most cases it won't). 

I disagree.

If devd tells you that some FC mesh just got plugged in and you
interpret that to start a backup onto your dedicated FC drive, then
it matters a lot if it got almost instantly replaced by a USB key.

I would probably put a file with an encrypted magic marker on the
drive and refuse backup if it wasn't there.

Or something.

I think it is waaay out of what should be handled by an operating system,
we're into the territory which makes companies shell out millions for
things like Unicenter or Tivoli in the vain hope that adding more
complex software will improve the situation.

I think we should have DEVFS inject "ad0 appeared, type=DISK" to devd
and leave it at that.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.