On Tuesday, 12/11/2001 at 03:11 EST, Nick Gimbrone <[EMAIL PROTECTED]> wrote: > > It would have been better if the TCP/IP CTC protocol included an exchange > > of buffer sizes using a pre-defined small I/O buffer. But it didn't and > > that's the way the ball bounces. (The restriction being that the MTU would > > be forced to be less than the I/O buffer size.) > Exactly. But when a mistake is made, then you need to look for a way to correct > it rather than fielding these config problems time & again. It seems like this > is a common config issue... and thus it is time for the device driver to fix > it... it is just a matter of programming and careful transition to the new > driver(s). (E.g. add them as new alternate drivers rather than replacing the old > ones, etc.)
Nah. Instead of VCTC, use z/VM 4.2 and guest LANs with virtual HiperSockets. WDNYADD. (We don't need yet another device driver). > And while I'm on the subject... why is it that the IBM proprietary device > drivers need to be versioned to the kernel (creating all sorts of havic for > those who what to upgrade before IBM is ready or even do their own kernel > hacking). There is no reason (other than perhaps some legal bean counter's) to > not split that driver code into a sourced layer which implements a private api > for the oco portion that contains all the secrets. The api would need (for > instance) to present a kernel data structure abstraction which that oco portion > could view as fixed... and the sourced piece need hold nothing proprietary... > again, simple straight forward programming.... "its time..." [Disclaimer: I am not the owner of the Linux for zSeries or S/390 OCO device drivers and I don't pretend to speak for the owner.] This is the same design point that Alan Cox described a while back. As simple as it sounds, changing the driver design would require that someone stop working on what they are designing/developing now and redesign and recode the drivers. The means someone else must stop testing what they are testing now and test the redesigned driver. I don't mean to say that the driver's design won't change (I don't know), but keep in mind that such a change isn't free, and that changing it is a business decision, not a technical one. But we do listen and we do learn. If we make the same mistake again with some other driver, feel free to kick us in the teeth (or wherever...). Regards, Alan Senior Software Engineer z/VM Development, Endicott, NY Phone 607.752.6027 fax 607.752.1497 t/l 852
