Status of misdn support

[Simon Richter]

Hello,

Alessandro Polverini wrote:

> I tried to send Simon Richter a couple of mails on the subject but I had
> no response.

Yes, I'm busy. Your mail is still flagged "to do". :-/

No, it should not be released with etch. There are lots of issues in the
code that need to be worked out before. The fact that it is in use in
production systems means that these systems are not doing anything else,
never reconfigure their ports or start/stop asterisk. Fixing that will
require changing the API, the ABI and a zillion places in the kernel.

Yes, there is an amd64 version. In fact, I'm using it, but it only works
for one of the cards I happen to have. The code is not 64 bit clean. The
code is not endian clean. The funky memory corruption issues seem to
have gone for the moment, although I didn't run a code coverage test
yet, so I cannot tell what interesting things may lurk somewhere.

No, MC Hammer has no idea of how to deal with the current kernel
packages, and also fails to fail.

Yes, uupdate can be used to bring in new versions. Movement in the
upstream CVS is pretty slow these days, so I guess you're not missing
much by simply taking the existing misdn-source package and compiling
modules for your kernel with m-a. The upstream author is paid to work on
mISDN and at the same time fix bugs in i4l, and the latter project has
been seeing more commits lately, so I guess that priorities are
elsewhere currently.

No, you are not supposed to upload new versions. There was at least one
change that broke binary compatibility. When a new version is uploaded,
it needs to be coordinated among all packages. asterisk-chan-misdn
currently needs to conflict with asterisk-config since that ships
misdn.conf. The bug report asking for the removal and possible proper
handover of that file appears to be gone, however. I guess I should
refile it, and will do so when I get home.

Yes, the modifications to the build system are there on purpose. I was
not on crack while I did them, although I'm not sure what made me add
the rules for rewriting debian/rules into debian/rules.

No, said rules will not be in the next version, although the rules for
debian/control will remain. Only MC Hammer can touch this.

Yes, there are other things that make me think that mISDN is not ready
for release. Integration with udev and hotplug, for example. The init
sequence. The unload sequence. I have a git repository that has some
patches that fix a bit of these, but ATM my duties at my workplace lie
elsewhere *cough*Windows drivers*cough*, so I don't have a testing setup
right now.

Sorry for not being more helpful,

   Simon