| Newsgroups |
gmane.linux.kernel.streams |
| Message-ID |
<OF1919BA9C.D067AEB9-ON80256FB0.002DF741-80256FB0.0031681E@lon.sita.aero> |
Dear All,
I've been in communication with Brian Bidulock and Christian Hildner
regarding problems with XTI.
This is to record my thoughts at present, because I don't know where its
going, and perhaps some other poor soul will benefit from my experience.
I am using Redhat Linux with a 2.4.21-27.0.2.ELsmp kernel and dual Intel
processors.
I can configure, make and install the driver. I can run the test programs.
The original GCOM site indicates that the driver is o.k. with SMP, which
would tend to be supported by the test programs.
My legacy program from AIX uses tcp. It compiles against the driver. It
doesn't run.
The sample programs from HOB compiled after changes to the include files. I
think that's all I did, but when it ran
it crashed the kernel on transferring data.
My thought process has worked as follows:-
1 Are there any test programs that come with the driver which do work in
this situation.
a) test-xnet, superficially seems representative. GDB wouldn't 'follow a
child fork' so it was down
to taking a long look at the code. Although this code does execute the
XTI interface, it does so over a pipe
and as a result none of the data structure need to be populated for it
to run.
So its not very representative, and not really a comprehensive test
for any transport other than a pipe. In the
here and now, it would be a brave person who would say thattcp was not
a driving force.
b) test-inet_tcp also seemed a good candidate, but inspection of the code
(few comments as ever) revealed that
it wasn't what I was looking for being more streams based.
c) I couldn't find anything else that fitted the bill.
2. I'm sure that the test programs are comprehensive in their own way, but
they're certainly not all encompassing, and don#t cover tcp over XTI.
3. Because the test programs work on my SMP box, it might lead me to
believe that the driver software was sound.
4. My belief now is that the driver isn't sound, because no user space
program should bring the system down.
5. How do I report it? How do I report what! Unless someone has the
time/machine to debug the driver it is unlilely to get fixed, even if I
could offer more information about the bug which I can't. I could spend
project time debugging the driver, but it is becoming more difficult to
justify the amount of time I am spending not getting
my legacy code going.
6. Having spent a fair few days believing that XTI would work on this
Driver I felt that my project would have been better served by just
converting the legacy software to sockets.
7. O.k., so as Christian says its beta, but I've used beta stuff before,
and at that stage you would expect it to
be a little better than crashing the system.
At a crossroads... is XTI too old hat? even though this driver software
isn't finished?