[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C69653E.6050808@vlnb.net>
Date: Mon, 16 Aug 2010 20:20:14 +0400
From: Vladislav Bolkhovitin <vst@...b.net>
To: James Bottomley <James.Bottomley@...e.de>
CC: scst-devel <scst-devel@...ts.sourceforge.net>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Fwd: Re: [Scst-devel] linuxcon 2010...
Hello James,
Could you comment rumors that decision about future Linux SCSI target
subsystem is done as well as other related rumors:
1. What don't you like in the transition path for users from STGT to
SCST, which I proposed:
- The only people which would be affected by replacing of STGT by SCST
would be users of ibmvstgt. Other STGT users would not notice it at all.
Thus, we should update ibmvstgt for SCST. If ibmvstgt updated for SCST,
the update for its users would be just writing of a simple scstadmin's
config file.
- STGT doesn't have backend drivers, which SCST doesn't have, so
there's nothing to worry here. At max, AIO support should be added to
fileio_tgt.
- STGT user space targets can use SCST backend via scst_local module.
Scst_local module is ready and work very well.
The result would be very clear without any obsolete mess.
2. Don't you like something in the sysfs interface SCST has?
3. I have heard you said "Vlad wasn't comfortable in handing up the
control to the maintainers ... (this is how kernel.org works)." I have
no idea what you meant. I have never been asked about anything like
that, so I couldn't say anyhow that I'm not comfortable with anything.
Could you clarify that?
4. Have you changed your opinion that a driver level multipath is
forbidden in Linux and now you think that an iSCSI target with MC/S
support is acceptable?
Thanks,
Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists