Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Andi Kleen <[EMAIL PROTECTED]> wrote:
>> we were talking about the load order. This will solve the load order,
>> but if we have races like the kind you described, then the whole mISDN
>> design is broken.
>
> It's more a generic problem of the module code.
It's a problem of not enough synchronisation before a module load completes.
If a module provides an interface, but needs some time after being load to
initialize, it obviously MUST provide a way to wait for it. Since you'll
need some i-need-module-foo functions anyway, why not: (bar needs foo)
-foo.c---
DECLARE_COMPLETION(init_complete); /* static? */
module_foo_init_async() {
...
void complete_all(&init_complete);
}
void usemod_foo()
{
wait_for_completion(&init_complete);
}
EXPORT_SYMBOL(usemod_foo)
-bar.c---
DECLARE_COMPLETION(init_complete);
module_bar_init_async() {
usemod_foo();
...
void complete_all(&init_complete);
}
void usemod_bar()
{
wait_for_completion(&init_complete);
}
EXPORT_SYMBOL(usemod_bar)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi Karsten. > Normally I reserved the complete last week for working on mISDN to get it > ready to submit it to -mm, but reality did hit me and I had to do some > other importent stuff :-( When you do your first submission can you please submit the minimal possible configuration. I tried enabling the AVM!Fritz and I could see that with this driver alone the following files got build: avm_fritz.c layer3.c l3_udss1.c capi.c contr.c listen.c appl.c plci.c app_plci.c ncci.c asn1.c asn1_aoc.c asn1_comp.c asn1_generic.c asn1_diversion.c asn1_basic_service.c asn1_address.c asn1_enc.c capi_enc.c supp_serv.c core.c stack.c udevice.c helper.c debug.c fsm.c channel.c l3helper.c sysfs_obj.c sysfs_inst.c sysfs_st.c dtmf.c isac.c arcofi.c layer1.c layer2.c tei.c x25_dte.c x25_l3.c And that a *lot* to review in one go. So if you could squeze that down to less files it would be nice. And only one simple HW drivers (I randomly selected avm_fritz above). When we get this in shape you can follow up with more HW drivers. Thanks, Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi, sorry that I step in so late, procmail sorted this thread in the wrong box. Normally I reserved the complete last week for working on mISDN to get it ready to submit it to -mm, but reality did hit me and I had to do some other importent stuff :-( On Thu, Feb 21, 2008 at 11:33:04AM +0100, Simon Richter wrote: > Hi, > > Tilman Schmidt wrote: > > > mISDN has two problems, which are of course interrelated: > > mISDN has one problem that is even bigger than these: the kernel oopses > if modules aren't loaded in the right order. misdn-init works around > that, but if it doesn't work for some reason (and I can think of > multiple here), the user is left with a kernel that oopses during > hardware discovery and never gets to a stage where this can be > rectified, as almost all distributions now have hardware discovery > before the first opportunity to get a shell. At least these were my > experiences the last time I tried it on my test box. > > This is the reason I've kept mISDN out of the last two Debian stable > releases, despite users' requests. > > When a hardware driver module is loaded, it should only do basic > hardware initialisation; it is certainly not necessary to set up the > entire stack (or even decide on a protocol, which currently needs to be > handed in via module parameter -- before userland code is there that > wants to talk to the hardware, there is no reason to have the hardware > active). > These design issues are fixed in the new mISDN socket branch. The old mISDN design was too complicated because it allow access to every layer and build the ISDN stack dynamically, both feature were never needed in practice and contain many race conditions. The new design only has one core module and hardware specific modules with a very simple interface. The interface to the userspace are sockets (one per channel). -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi Simon, mISDN has two problems, which are of course interrelated: mISDN has one problem that is even bigger than these: the kernel oopses if modules aren't loaded in the right order. misdn-init works around that, but if it doesn't work for some reason (and I can think of multiple here), the user is left with a kernel that oopses during hardware discovery and never gets to a stage where this can be rectified, as almost all distributions now have hardware discovery before the first opportunity to get a shell. At least these were my experiences the last time I tried it on my test box. that is not a big problem at all. If you have to enforce a specific module load order then create some dummy exports like misdn_load() and use them from the module that depends on it. It is not beautiful, but sometimes you have to do it this way. So if that is stopping mainline inclusion it is a lame excuse. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Simon Richter wrote: Hi, Tilman Schmidt wrote: mISDN has two problems, which are of course interrelated: mISDN has one problem that is even bigger than these: the kernel oopses if modules aren't loaded in the right order. misdn-init works around that, but if it doesn't work for some reason (and I can think of multiple here), the user is left with a kernel that oopses during hardware discovery and never gets to a stage where this can be rectified, as almost all distributions now have hardware discovery before the first opportunity to get a shell. At least these were my experiences the last time I tried it on my test box. This is the reason I've kept mISDN out of the last two Debian stable releases, despite users' requests. When a hardware driver module is loaded, it should only do basic hardware initialisation; it is certainly not necessary to set up the entire stack (or even decide on a protocol, which currently needs to be handed in via module parameter -- before userland code is there that wants to talk to the hardware, there is no reason to have the hardware active). Simon -- hi there simon ive not bothered with isdn-init i use some modprobe magic to sort out the mess here it is ... edit the flags as required.i agree this is not ideal and most drivers should have a default ill take this under advisement and when there is some time ill look at setting it as default.this recipe plays nicely with hotplug and friends. # #Protocol Flags # #0x001 1TR6 (Not Available) #0x002 DSS1 #0x010 NT Mode #0x020 PTP Mode #0x040 PCM Slave Mode #0x080 Negative Frame Pulse #0x100 Use Setting From Previous Driver And Add To Previous Stack #0x200 Switch DU/DD Interface # #Typical Usage # #0x02 TE Mode #0x12 NT Mode # #Layer Mask To Select Layers In D Channel Stack Layer 0 (HW) is always included # #0x1 Layer 1 #0x2 Layer 2 (Only Layers 1 and 2 are needed for NT Mode) #0x4 Layer 3 #0x8 Layer 4 # #Typical Usage # #0x0f TE Mode #0x03 NT Mode # #Debug Mask # #0x01 IRQ Status #0x02 D-Channel Events #0x04 D-Channel FIFO Data #0x08 B-Channel Events #0x10 B-Channel FIFO Data # #DSP Options # #0x01 ULAW (Instead Of ALAW) #0x10 Software Bridging (Instead Of Hardware) options avmfritz protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options avmfritz layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options avmfritz debug=0x0 options hfcpci protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options hfcpci layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options hfcpci debug=0x0 options hfcmulti type=8 options hfcmulti protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options hfcmulti layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options hfcmulti debug=0x0 options w6692pci protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options w6692pci layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options w6692pci debug=0x0 options sedlfax protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options sedlfax layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options sedlfax debug=0x0 options hfcsusb protocol=0x2,0x2,0x2,0x2,0x2,0x2,0x2,0x2 options hfcsusb layermask=0xf,0xf,0xf,0xf,0xf,0xf,0xf,0xf options hfcsusb poll=128 options hfcsusb debug=0x0 options mISDN_dsp options=0x10 options mISDN_dsp debug=0x0 options mISDN_dsp poll=128 install avmfritz /usr/sbin/mkisdnnod avmfritz install hfcpci /usr/sbin/mkisdnnod hfcpci install hfcmulti /usr/sbin/mkisdnnod hfcmulti install w6692pci /usr/sbin/mkisdnnod w6692pci install sedlfax/usr/sbin/mkisdnnod sedlfax install hfcsusb/usr/sbin/mkisdnnod hfcsusb /usr/sbin/mkisdnnod #!/bin/bash if [ -e /var/run/isdnprobe.pid ];then CURPID=`cat /var/run/isdnprobe.pid` if [ "$CURPID" != "$$" ] && [ -d /proc/$CURPID ] && [ "$CURPID" ];then exit; else echo $$ > /var/run/isdnprobe.pid fi; else echo $$ > /var/run/isdnprobe.pid fi; if [ ! -e /dev/mISDN ];then /bin/mknod /dev/mISDN c 46 0; /sbin/modprobe mISDN_l1; /sbin/modprobe mISDN_l2; /sbin/modprobe l3udss1; /sbin/modprobe mISDN_isac; /sbin/modprobe mISDN_x25dte; /sbin/modprobe mISDN_dtmf; /sbin/modprobe mISDN_dsp; /sbin/modprobe mISDN_debugtool if [ "$1" ];then /sbin/modprobe -s -q --ignore-install $1; fi; rm /var/run/isdnprobe.pid else /sbin/modprobe -s -q --ignore-install $1; fi; -- This message has been scanned for viruses and dangerous content by Superset Technology, and is believed to be clean. http://www.superset.co.za -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi, Tilman Schmidt wrote: mISDN has two problems, which are of course interrelated: mISDN has one problem that is even bigger than these: the kernel oopses if modules aren't loaded in the right order. misdn-init works around that, but if it doesn't work for some reason (and I can think of multiple here), the user is left with a kernel that oopses during hardware discovery and never gets to a stage where this can be rectified, as almost all distributions now have hardware discovery before the first opportunity to get a shell. At least these were my experiences the last time I tried it on my test box. This is the reason I've kept mISDN out of the last two Debian stable releases, despite users' requests. When a hardware driver module is loaded, it should only do basic hardware initialisation; it is certainly not necessary to set up the entire stack (or even decide on a protocol, which currently needs to be handed in via module parameter -- before userland code is there that wants to talk to the hardware, there is no reason to have the hardware active). Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
did someone say interface/API documentation ooops ... seriously this is lacking and im sure as time goes on some volenteer (sucker) will get it up and running.this is not a show stoper but a nice to have.ill perhaps even help out a bit with things, i have some comments on useage and module parameters that could be usefull to the would be users.remember mISDN is just the kernel bits there is a user lib that takes care of userland bits. > >> b) still doesn't support all the hardware isdn4linux supports. > > That's a show stopper of course. of course not all hardware is supported and in some cases more hardware is supported ... there is a precident for this OSS/ALSA where the one is marked as DEPRICATED and the other promoted initialy as EXPERMENTAL ... over all the most common devices are better supported under mISDN than isdn4linux. and as with OSS/ALSA both can coexist on the system as modules (only one can be loaded at a time or else they dont play nice). i really think this is a storm in a tea cup been blown into a hurricane after all if it were mainlined (in -mm even) the result would be better support and more choice there are far worse supported drivers than the mISDN stack.the reality is that isdn4linux is dead idealy unsuported drivers need to be ported to mISDN or kept on life support. -- This message has been scanned for viruses and dangerous content by Superset Technology, and is believed to be clean. http://www.superset.co.za -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
> mISDN has two problems, which are of course interrelated: > > a) complete lack of documentation for the in-kernel driver interface >(equivalent of Documentation/isdn/INTERFACE) Most subsystems in the kernel would disqualify under that rule Did you ever look for full documentation on how to write Ethernet drivers for example? Some bits are documented, but far from all I'm not defending that, but it's how it is. > > b) still doesn't support all the hardware isdn4linux supports. That's a show stopper of course. > (maintainer of an isdn4linux driver, waiting desperately for > documentation on how to convert to the new CAPI/mISDN world > but tired of asking for it in vain) My advice is that you just read the source of some existing drivers for examples and copy them and of the subsystem itself if anything is unclear. That is how Linux drivers are usually written. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
> mISDN has two problems, which are of course interrelated: > > a) complete lack of documentation for the in-kernel driver interface > (equivalent of Documentation/isdn/INTERFACE) > > b) still doesn't support all the hardware isdn4linux supports. > > As long as those problems aren't solved, the old stuff cannot be removed. > Perhaps merging the current state of mISDN into the -mm tree would help > with this. Perhaps not. It should get put into the -mm tree so it can be worked on, and if they won't do that it should probably get binned and people them know what is going on and can fix the existing isdn code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Marcel Holtmann schrieb: My proposal is to merge mISDN and then see what falls out. My guess it won't be that bad as everybody thinks and then we go from there. Next step is to remove ISDN4Linux since that should not be used at all anymore. No. Next step is to create the missing documentation. The step after that is to convert the remaining isdn4linux drivers to mISDN. Then you can remove isdn4linux. HTH T. -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Gregory Nietsky schrieb: ive been hackin away at mISDN for a while and use it with recent kernels 2.6.2X and have a patch for 2.6.24 (move from semaphore to complition) the distro we built is heavily reliant on mISDN (voip) i dont use the isdn kernel drivers at all any longer. im all for mISDN been mainlined into the kernel and the old stuff been removed there could be users still it is marked as depricated and the plan was with 2.6 to use mISDN from the start. mISDN has two problems, which are of course interrelated: a) complete lack of documentation for the in-kernel driver interface (equivalent of Documentation/isdn/INTERFACE) b) still doesn't support all the hardware isdn4linux supports. As long as those problems aren't solved, the old stuff cannot be removed. Perhaps merging the current state of mISDN into the -mm tree would help with this. Perhaps not. Regards, Tilman (maintainer of an isdn4linux driver, waiting desperately for documentation on how to convert to the new CAPI/mISDN world but tired of asking for it in vain) -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Hi Andi, If noone in the isdn community step up and take some responsibility for the current isdn drivers in Linux then we should just delete them. So you're saying anything that has no active maintainer should be immediately deleted? You do not recognize a provocation when you see it? I wanted a reaction from the isdn community - and I got so. So lets look forward. Well it was more a lie because you couldn't possibly make up to your threat anyways. I'm not sure either it's a good idea to try to merge mISDN if the maintainers don't think it is ready yet. you can't wait until it is perfect. Then it never gets merged. The out- of-tree ISDN stuff has always been painful. And that was already in the ISDN4Linux days which were Linux 2.2 days or even earlier. My proposal is to merge mISDN and then see what falls out. My guess it won't be that bad as everybody thinks and then we go from there. Next step is to remove ISDN4Linux since that should not be used at all anymore. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Sam Ravnborg wrote: I'm not sure either it's a good idea to try to merge mISDN if the maintainers don't think it is ready yet. In the spirit of relase early - relase often we should at least see what is going on. well to add mISDN to the kernel tree is straight forward ./std2kern and the out of tree set becomes in tree a bit of git magic and you have a patch. im advocating it for now alongside isdn4linux prehaps marked as "EXPERIMENTAL" im not involved in the mISDN team im a contributor/hacker. need the buy in from Cristian R/Karsten K. FYI here in south africa ISDN BRI is widely available with the high costs of ISDN PRI this is the best/most practical solution for VOIP.with ADSL only now becoming availble on mass the "fastest" connection is still 64/128k ISDN in many areas.the hardware is easily available from all outlets.my device of choice is a cheap USB modem that comes in @ 30$ US per port (can use upto 8) the 4 port digium card comes in @ 650$. Greg -- This message has been scanned for viruses and dangerous content by Superset Technology, and is believed to be clean. http://www.superset.co.za -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
> > I'm not sure either it's a good idea to try to merge mISDN if the > maintainers don't think it is ready yet. In the spirit of relase early - relase often we should at least see what is going on. And Gregory wrote: > ive been hackin away at mISDN for a while and use it with recent kernels > 2.6.2X and have a patch for 2.6.24 (move from semaphore to complition) > the distro we built is heavily reliant on mISDN (voip) i dont use the > isdn kernel drivers at all any longer. So not useless and having it in the kernel may cause more people to contribute. I for one do prefer to hack on something in the kernel and not hidden in some repository far away. But until we see patches lets wait and see. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Tue, 19 Feb 2008, Andi Kleen wrote: On Tue, Feb 19, 2008 at 10:56:22AM +0100, Sam Ravnborg wrote: If noone in the isdn community step up and take some responsibility for the current isdn drivers in Linux then we should just delete them. So you're saying anything that has no active maintainer should be immediately deleted? You do not recognize a provocation when you see it? I wanted a reaction from the isdn community - and I got so. So lets look forward. Well it was more a lie because you couldn't possibly make up to your threat anyways. I'm not sure either it's a good idea to try to merge mISDN if the maintainers don't think it is ready yet. Without having any opinion here or understanding what the problem is, I just want to remind everyone that ISDN in the linux kernel (isdn4linux) is not just mISDN. There are drivers for common devices/interfaces, the CAPI interface and of course hardware drivers for other ISDN cards like the active ones as well. Armin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Tue, Feb 19, 2008 at 10:56:22AM +0100, Sam Ravnborg wrote: > > > > > If noone in the isdn community step up and take some responsibility > > > for the current isdn drivers in Linux then we should just delete them. > > > > So you're saying anything that has no active maintainer should > > be immediately deleted? > > You do not recognize a provocation when you see it? > I wanted a reaction from the isdn community - and I got so. > So lets look forward. Well it was more a lie because you couldn't possibly make up to your threat anyways. I'm not sure either it's a good idea to try to merge mISDN if the maintainers don't think it is ready yet. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
> > > If noone in the isdn community step up and take some responsibility > > for the current isdn drivers in Linux then we should just delete them. > > So you're saying anything that has no active maintainer should > be immediately deleted? You do not recognize a provocation when you see it? I wanted a reaction from the isdn community - and I got so. So lets look forward. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Tue, Feb 19, 2008 at 11:25:06AM +0200, Gregory Nietsky wrote: > ive been hackin away at mISDN for a while and use it with recent kernels > 2.6.2X and have a patch for 2.6.24 (move from semaphore to complition) > the distro we built is heavily reliant on mISDN (voip) i dont use the > isdn kernel drivers at all any longer. > > im all for mISDN been mainlined into the kernel and the old stuff been > removed there could be users still it is marked as depricated and the > plan was with 2.6 to use mISDN from the start. Great! First step would be to send a properly splitted up patchset for review if is is ready. Release early - relase often is the best way. I will do my best to review the bits I can help with. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
ive been hackin away at mISDN for a while and use it with recent kernels 2.6.2X and have a patch for 2.6.24 (move from semaphore to complition) the distro we built is heavily reliant on mISDN (voip) i dont use the isdn kernel drivers at all any longer. im all for mISDN been mainlined into the kernel and the old stuff been removed there could be users still it is marked as depricated and the plan was with 2.6 to use mISDN from the start. Greg Sam Ravnborg wrote: On Mon, Feb 18, 2008 at 01:08:33PM +0100, Andi Kleen wrote: Greg KH <[EMAIL PROTECTED]> writes: If Jeff does that, I still can't drop those PCI functions from the PCI core, which I desperatly want to do as they do not play nice with modern systems (meaning hotplug...). So either way, I think his patches should go in. Merging essentially untested patches does not seem like a good strategy. And there is definitely still a large ISDN user base too. Only issue seems that this large ISDN user base is not very active in respect to Linux driver development. Or at least not judging from the missing responses to their mailing list and the limited traffic on said mailing list. Reading the isdn4linux it is obvious that the way forward are the mISDN code base so maybe that explains why noone steps up and test the patches of Jeff's. If noone in the isdn community step up and take some responsibility for the current isdn drivers in Linux then we should just delete them. If anyone cares they can always be forwardported or even better we can integrate the much more flexible mISDN solution. My personal guess is that there are far more ISDN users than (non cardbus) PCI/PCI-e hotplug users. My guess is that very very few uses ISDN in combination with a recent kernel. Hmm, wonder if it is more fun hacking isdn drivers than kbuild stuff and section mismatches ;-) Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- This message has been scanned for viruses and dangerous content by Superset Technology, and is believed to be clean. http://www.superset.co.za -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Tue, Feb 19, 2008 at 09:50:33AM +0100, Sam Ravnborg wrote: > Only issue seems that this large ISDN user base is not very active > in respect to Linux driver development. They don't need to because this stuff basically works and there isn't much new hardware anymore and no new standards and it also doesn't really need much tuning. Or rather the new hardware development (like Asterisk support etc.) seemed to be mostly done on out of tree mISDN. > If noone in the isdn community step up and take some responsibility > for the current isdn drivers in Linux then we should just delete them. So you're saying anything that has no active maintainer should be immediately deleted? I suspect after you would be done with that a lot of (working) code in Linux would be gone. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Mon, Feb 18, 2008 at 01:08:33PM +0100, Andi Kleen wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > > > If Jeff does that, I still can't drop those PCI functions from the PCI > > core, which I desperatly want to do as they do not play nice with modern > > systems (meaning hotplug...). > > > > So either way, I think his patches should go in. > > Merging essentially untested patches does not seem like a good strategy. > And there is definitely still a large ISDN user base too. Only issue seems that this large ISDN user base is not very active in respect to Linux driver development. Or at least not judging from the missing responses to their mailing list and the limited traffic on said mailing list. Reading the isdn4linux it is obvious that the way forward are the mISDN code base so maybe that explains why noone steps up and test the patches of Jeff's. If noone in the isdn community step up and take some responsibility for the current isdn drivers in Linux then we should just delete them. If anyone cares they can always be forwardported or even better we can integrate the much more flexible mISDN solution. > My personal guess is that there are far more ISDN users than (non cardbus) > PCI/PCI-e hotplug users. My guess is that very very few uses ISDN in combination with a recent kernel. Hmm, wonder if it is more fun hacking isdn drivers than kbuild stuff and section mismatches ;-) Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Jeff Garzik <[EMAIL PROTECTED]> writes: >> And there is definitely still a large ISDN user base too. > > This is what I'm curious about. My personal guess is that there is a > lot of ISDN hardware available, but not necessarily the telco ISDN > availability. At least Germany has about 100% ISDN telco availability. I don't know the exact numbers of how many people use ISDN, but it is likely into the double digit millions. The big ex monopoly telco has been pushing ISDN aggressively for quite some time. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Andi Kleen wrote: Merging essentially untested patches does not seem like a good strategy. Agreed. I don't want my stuff going in without knowing it works. And there is definitely still a large ISDN user base too. This is what I'm curious about. My personal guess is that there is a lot of ISDN hardware available, but not necessarily the telco ISDN availability. But I have no way to gauge the Linux ISDN userbase size (beyond responses from isdn maintainers and list users), so I'm a poor judge. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Mon, 18 Feb 2008 13:08:33 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > > > If Jeff does that, I still can't drop those PCI functions from the PCI > > core, which I desperatly want to do as they do not play nice with modern > > systems (meaning hotplug...). > > > > So either way, I think his patches should go in. > > Merging essentially untested patches does not seem like a good strategy. > And there is definitely still a large ISDN user base too. > > My personal guess is that there are far more ISDN users than (non cardbus) > PCI/PCI-e hotplug users. pci_find_ breaks Cardbus too in some cases. It should die. So either we apply the patches or mark the offenders as BROKEN. Clearly they are not maintained as they've been left broken this way for ages and are not going to get fixed unless persuasion is applied. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
Greg KH <[EMAIL PROTECTED]> writes: > > If Jeff does that, I still can't drop those PCI functions from the PCI > core, which I desperatly want to do as they do not play nice with modern > systems (meaning hotplug...). > > So either way, I think his patches should go in. Merging essentially untested patches does not seem like a good strategy. And there is definitely still a large ISDN user base too. My personal guess is that there are far more ISDN users than (non cardbus) PCI/PCI-e hotplug users. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...
On Sun, Feb 17, 2008 at 08:52:35PM +0100, Sam Ravnborg wrote: > Hi Karsten et al. > > Seeing the work Jeff puts into ISDN I was wondering what are the > state of mISDN. Will we soon see mISDN hit the tree or has > development stalled? > > I was wondering if Jeff should go for the much simpler patch: If Jeff does that, I still can't drop those PCI functions from the PCI core, which I desperatly want to do as they do not play nice with modern systems (meaning hotplug...). So either way, I think his patches should go in. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
