Bolke de Bruin wrote: >Rolf Eike Beer wrote: >>If I can still help you then depends on >>your scheduling of this job. I'll try to do some hacking at the weekends. > >Does this mean you will not have time until October 5th or just time in >the weekend until that time? For the moment my weekends are more or less "free time to hack". My thesis is some hardware design, I don't have the tools at home so there is little I can do at the weekend. This will change in september I think, then I will TeX all day ;) >>Nevertheless without access to the hardware it will be a bit difficult. >> Much more than compile-testing is not possible for me. > >Access to hardware can be arranged Testing will very likely include crashing the machine more than once and doing some nasty things with the attached storage. Someone will have to plug the wire out of it while accessing the storage, reboot the switch and such stuff. This can really hurt in a production environment. >>I'll send some more cleanups to this driver in a few minutes (I'll CC you). >>What has to be done from my point of view is: >> >>-split up the interrupt handler in one small interrupt handler and one >> tasklet that does the actual work. I have a patch that would do this but >> I'm not familiar with this stuff. There are probably some bugs. >>-fix the stack abuse. I already sent a patch, this has to be made a bit >> nicer and better. >>-change the probe/remove stuff to use Linux 2.6 API. This is optional, but >> I think it will make this piece of dirt a bit cleaner ;) >>-the stopping of the kernel thread for every controller is a bit messy. >> There is a cleaner (and simpler) API in Linux 2.6 so this should also be >> adjusted. Not really critical, but it makes a lot of sense IMHO. >>-there is not much error checking. From my point of view there is to much >>trust in that everything is ok which can lead to serious trouble if the >> link sends you crap. > >For us everything more or less comes down to:is this feasible? I'm sure it is. >Currently we have three options: > >- Keep the current windows platform and not use 'full strength' of the >hardware (sunv20z), though controller and array will be EOL'd pretty >shortly by HP Before you throw it away send it to me ;) I like to have some obscure hardware around. >- Use a different controller (fyi HP's FCA2214) which needs a converter >for the GBIC's (2gb --> 1gb). And will be unsupported by HP Ugly. >- Sponsor someone (you) to update the driver to support 2.6 / amd64 in a >trusted fashion *g* >So for us it is little bit of risk management (jug :-) ) and we are >trying to find out our best option. I think the main stuff could be done in a week or two. My problem is that I can't test it on my own (and it's likely to do some bad things with data behind it) and that I would like to have someone experienced to review what I do. I'll keep sending this stuff to linux-scsi, but I have no reaction from anyone there. I hope they will wake up when the interesting stuff comes ;) Eike
Attachment:
pgp2Muhfrk0PG.pgp
Description: PGP signature
- References:
- Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA
- From: Bolke de Bruin <[email protected]>
- Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA
- Prev by Date: [PATCH] Bogus code in parsing of iocharset in isofs
- Next by Date: [PATCH 2.6.13-rc6] remove 2.4 compat code from cpqfcTS driver
- Previous by thread: Re: Kernel 2.6.5 - Compaq Fibre Channel 64-bit/66Mhz HBA [PATCH]
- Next by thread: 2.6.13-rc6-git3 undefined reference on _mntput
- Index(es):
