> What did seem to be missing was anything saying whether
> those device methods would be called in_interrupt() or
> whether instead they could sleep. I'd hope all of them
> would be specified to allow blocking as needed, like their
> current analogues in PCI and USB.
Look better, it was there.
> Also, there was some mention not that long ago about
> desirability of some kind of device abort() call. That
> would differ from the current remove() call because an
> abort() would pass the explicit knowledge that hardware
> was gone ... unplugged before driver shutdown, for one
> example. That could also be achieved using some kind
> of mode parameter to remove() -- perhaps three values,
> saying whether the hardware was present, removed, or
> in some indeterminate state.
I'd prefer parameter to remove...
Your hardware may die physically, and driver should try to be able to
remove() even if hardware dies.
-- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/