In message <Pine.GSO.4.21.0211180403440.23400-100000@steklov.math.psu.edu> you
write:
> Not really. For case in question (block devices) there is only one path
> and I'd rather keep it that way, thank you very much.
See other posting. This is a fundamental design decision, and it's
not changing. Sorry.
> Again, by the time when add_disk() got to reading partition table, device
> is _there_. That's it - we had set it up completely, it's ready for IO,
> whatever. At that point we want generic code to do some work with that
> device. And there is no magic path for that - it's normal open/read/close.
>
> There is no "live" flag - you had shown it, you'd better be ready to have
> it used. Doesn't cause any problems.
Unless the module does something else afterwards which fails and wants
to fail the init. You're saying "don't do that", which is not a good
answer 8(
You can implement a "make_module_live()" in module.h if you want
module authors to do two-stage init manually (and trust them to get it
right). Or you can run a notifier on "enlivening" a module: I'd hoped
to avoid that.
Hope that helps,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:25 EST