> That's really the wrong way to look at it. Just look at the headers from > the mail: they clearly show that the mail was sent to you by the mailing > list software. It was delivered to you because *you* subscribed to the > list, not because *I* sent it to you. > Other mail clients (such as my own kmail) by default automatically reply to > the mailing list only. Your client probably has a "reply-to-list" option.
The e-mail client I normally use is the the browser-based basic webmail client of my ISP, which happens to be WOW! It is a cable TV company which also offers high speed internet connectivity via a cable modem. They give free e-mail accounts to their cable-modem customers. And they have a basic and an advanced browser-based webmail client. I don't use the e-mail client installed on my workstation. I prefer web-based e-mail for a number of reasons, but I won't go into it here because it's off-topic. The point is that, as seen by my e-mail client, the incoming e-mail says To: [email protected] From: (poster's e-mail address) When I click on "reply", the "To" field is pre-filled-in with the poster's e-mail address. I have to remember to do a "copy", while still on the page for the incoming e-mail, of the "To" field; then after clicking on "reply" I have to remember to do a "paste" on top of the "To" field to put the list address there. I'm not sure why it works that way, but it does. Anyway, the point is that I know how to work around it; I just have to remember to do it. > And in fact, the patch that's now included upstream > is rather different from your patch. Yes, they took a different approach than I did. My patch applies to the mdsk_init_io internal function. It sets the return code to zero inside the function; so that the caller never sees a return code of 4. The official patch took a different approach. They changed the logic in the two places in the code where the return code is checked; so that it correctly handles a return code of 4. Both approaches work. The official patch is better, in my opinion, because it automatically sets the read-only option on when it detects the return code of 4 and also adds some diagnostic and informational messages. The down side to the official patch is that it does not backport as easily to old releases due to changes in the way that kernel messages are issued between 2.6.26 and 2.6.33. But both patches solve the problem. > More confusion. The reason that still points to the Lenny version is that > there has not yet been a release (upload) of D-I for Squeeze [1]. The > images linked there are completely unusable to build CD images for Squeeze > (and even unusable to install Squeeze). > > The only images relevant for Squeeze ATM are the "daily built" images > available from [2], and they use the 2.6.30 kernel udebs from unstable. That's good info. Thank you. I was just about to try an install of Squeeze for s390. You just saved yourself a bug report. > No, they accepted it as a *bug*. They did not accept your *patch*. Oh, now I get it. > Sure. But OTOH it adds support for a class of devices that is currently > effectively not supported. So even though the from a technical PoV it is a > bug, from a functional PoV it can be seen as an enhancement. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. It might also help you if you have a vested interest in driving I/O through CP diagnose codes for some reason. (i.e. local modifications to DIAG 250 support in z/VM for accounting, security, auditing, or whatever.) The DIAG driver, with or without the patch, does not add support for devices that otherwise are not supported by Linux. And the patch does not add support for new devices. What the patch gives you is safety. Without the patch, the only way to share minidisks between multiple servers, and still use the DIAG driver, is to LINK the minidisks with access mode MW. And that gives multiple servers potential read/write access to the minidisk, which can (and almost certainly will) corrupt the minidisk if two servers mount the file system read/write at the same time. If the minidisks are LINKed with access mode R, that can't happen. CP prevents you from accidentally shooting yourself in the foot. But if you LINK the minidisk with access mode R, and you use the DIAG driver, you can't get the device online unless one of the two DIAG patches is on. Without the patch, you must either LINK the minidisk with access mode MW or else stay with access mode R but switch to the ECKD or FBA driver, depending on device type. If you use access mode MW, you increase the risk of corruption. If you switch to the ECKD or FBA driver, you lose the performance boost of the DIAG driver. > I think it *is* worth the effort to try to get the fix in 2.6.32, but > probably not in Lenny. OK, I'll try. But in exchange, I'll ask that you attempt to persuade the kernel team to hold off on freezing Squeeze until a kernel with this patch on it is adopted by Squeeze. There isn't much point in going through the effort to get the patch into 2.6.32 if Squeeze is going to be frozen at 2.6.30 or 2.6.31. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
