Bug#431724: Situation regarding mISDN

[Tzafrir Cohen]

On Mon, Aug 20, 2007 at 01:52:27PM +0200, Simon Richter wrote:
> Hi,
> 
> Lee Garrett wrote:
> 
> > Simon, if I get to write the HOWTO discussed in bug #431724, will you
> > drop (comment out in the scripts) building module packages for the
> > debian kernels?
> 
> Already done in my local tree.
> 
> > I guess for Lenny mISDN might have stabilized a little
> > and it would be easier to maintain them then. I think its ten times more
> > important to have up-to-date misdn libraries to work on than module
> > packages. Do you have any other plans or ideas with this?
> 
> There will be a separate source package that builds these, but that 
> depends on my "xcontrol" tool, so it probably will be another two weeks 
> until I roll that out. Given that this has to go through NEW anyway, I 
> don't think that matters much.
> 
> The difficult bit is going to be a sane init system.
> 
> Possible plan:
> 
> 1. Upload 1.1.5-1 to unstable without any init system at all (so no 
> change from earlier versions, should work as a drop-in replacement with 
> whatever scripts users have built for themselves), and a DebConf note 
> telling people to turn to experimental if they want to test the new init 
> system (obviously, we keep that out of testing).
> 
> 2. Upload 1.1.5-* to experimental with new udev-based init system. This 
> will require a lot of scripting, as mISDN can coexist with I4L, and some 
> people might want to run it in this way. Basically we need to get a list 
> of all ISDN adapters (I guess the files in upstream's kernel package are 
> going to be helpful there), and ask whether they want to use them with 
> mISDN or I4L, then set up udev rules for that. 

When exactly will this be done? modules are loaded at boot.

Note that qozap, zaphfc and vzaphfc from zaptel-modules also combat with 
misdn in the fight to be the default for the device IDs.

> Also we probably need to 
> set up fake dependencies from the hardware driver modules to the l1, l2 
> and l3 modules, I haven't checked that yet.

> 
> 3. When that init system works, upload to unstable. Whether or not to 
> remove the testing blocker at this point should be decided then.
> 
> 4. Work with/against upstream to get a real init system working, which 
> means teaching the kernel to defer loading the l1-3 drivers (this will, 
> guess what, change the kernel<->userspace API/ABI again, but we can 
> probably catch that in libmISDN). That was originally my plan for the 
> CCCamp, but I was sick in bed during that time.

What do you mean here?

Do you mean that every non-blacklisted module will get the hardware
before your module?

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir