Corey Minyard wrote (in 3 messages): > I forgot to mention that the v37 code does actually make sense. > Everything Matt has worked on has gone to the mainstream kernel, so all > Matt's changes should be there, either already in v37, or in future > patches to the main kernel.
The ones I spot-checked for were not in v37, and I could not use the future/main kernel stuff since I'm working in a fairly backwater 2.4-based environment. My attempts to sanely bring up Matt's patches, plus some HP patches I was trying to integrate, on the v37 base, were not at all successful. So I greatly appreciate your work here... > I've spent some time today working on this. My strategy is to go from > the v37 driver (which is both in the 2.6 kernel and 2.4 kernel) and go > forward from there from lkml patches that are appropriate. I have a > base set of patches that compile and work. > > Do we need emulator capability? How about smb? We are not building any of the emulation or SMBus modules; can't speak for anyone else though. The SMBus module implies the existence of hardware that can only be accessed that way. We only need this stuff to work on big "server" class machines. Am I right in guessing that IPMI-over-SMBus is going to be found only in small embedded devices? > I have a set of patches that should bring forward the 2.4 driver to the > same level of features as the 2.6 driver (as close as you can get, I > think). I have three sets of quilt patches at: > > http://openipmi.sourceforge.net/patches-2.4.20.tar.gz > http://openipmi.sourceforge.net/patches-2.4.21.tar.gz > http://openipmi.sourceforge.net/patches-2.4.32.tar.gz > > These all contain the same basic things: > > * a "patches" directory with all the patches and a series file > * The NMI patch > * The v37 base patch (exactly from the sourceforge download) > * A set of patches to add all the necessary features > * Patches for 2.4.20 and 2.4.21 to bring them to exactly the same > level as 2.4.32. There are some minor necessary differences with > ACPI (ACPI is not fully cooked in 2.4.21), but that is all. > * The SMBus patch (untested) > > I have only done basic testing on the interface (basic messaging, no > watchdog, power control, etc.) on the 2.4.32 and 2.4.20 kernels (there's > no basic difference here between 2.4.20 and 2.4.21, and I ran out of > time to test 2.4.21 except for compiling). > > My theory is to bring each kernel up to as close textually as possible > with individual patches. From this point onward, we can issue one patch > and it will apply to all 2.4 kernel versions. This should reduce the > maintenance burden; hopefully there won't be that many patches. That sounds like a good approach. The whitespace changes are sort of painful (makes this look like more change than it is), but they are worth it to set a level baseline. > It > would be nicer to use the 2.6 kernel as a base version, but there are > just too many differences. That's what I ran into when I briefly flirted with trying to use 2.6 ongoing versions. They don't even want to think about being compiled in a 2.4 environment... > So when we release this set of patches, I'll roll each up into a v37-v39 > patch for the respective kernel, and that will go onto sourceforge. > > If you have never used quilt before, you don't have to get it and learn > it. The tarball contains a set of patches and a file named "series". > The series file contains the list of patches in the order they should be > applied. So you can write a simple script (cat patches/series | while > read i; do patch <patches/$i; done) to apply the patches. > > If you are interested in this, can you make sure this has all the > features and updates you need? I've preserved the original git headers > in the patches that came from 2.6 so you can review them. For me, it will probably take about 2-3 months to really be able to answer this. I'm about to be out of the office for ~2 months (new baby) plus it will take a lot of complicated QA cycles, testing with management agents from all of our OEM partners and on various hardware. I will look into how much QA gear I can engage before I drop out of sight. I'm also going to ask my contact at HP to engage with this, make sure their changes get pulled in during this current active cycle. Thanks, >Bela< ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer
