-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jun,Friday 13 2008, at 6:51 PM, Mikulas Patocka wrote:
Hi
If you are rewriting it --- have you somehow thought about avoiding
suspend?
device suspend/resume are unsupported for now. I was not sure what
these commands should really do.
Because GPL/BSD licensing issues I haven't look at linux code.
A big source of problems in Linux is, that when you suspend a
device, you can do only a limited set of calls --- basically, you
must avoid anything that could possibly wait for I/O or allocate
memory --- or you might end up waiting for the suspended device and
deadlock. And I know still about 3 places in kernel that have this
error possibility.
ok but why I should want to do something like suspending of device ?
to avoid IO operations when I'm changing
device table or what problem are device suspend/resume want to solve.
If this is problem I can use one mutex
shared between dm_dev_suspend/resume_ioctl call and dmstrategy(this
routine does IO) so I can avoid IO's when
device is suspended.
A Linux LVM does something like: suspend old table, write to disk
with direct i/o, resume new table. I'd suggest that you invent some
method how to batch these operations into single syscall --- or you
run into a several years of deadlock problems on NetBSD ---
basically, on Linux, we have to preallocate a stack and heap (so
that running LVM process won't cause a page fault --- the question
--- how to do it portably on all NetBSD architectures?), mlock the
process, make sure that we don't open files or write anything to
terminal while suspended, make sure that the ioctl syscall doesn't
allocate anything (currently false, it won't deadlock but it could
randomly fail), make sure that O_DIRECT write syscall doesn't
allocate anything or wait for other I/O (currently it false, there
is a deadlock possibility) ... etc.
--- if you port lvm2 as it is, you'll have to audit (and maybe
rewrite) many parts of NetBSD kernel for not waiting for I/O. If you
do it badly, you'll get deadlocks.
I want definitely avoid such massive changes to our kernel.
This suspend thing was a big misdesign and if you are writing it
from scratch, try to avoid it.
Regards
Adam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFIVuNElIxPgX3Go0MRAvoaAJ9TC+dcYmp9S7yv/0un4YcMUE+AwwCeP1G0
C5o2j8D/+heQATR8eewYd34=
=dmZO
-----END PGP SIGNATURE-----
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel