Bug 112605

Summary:	Missing CAPI support in Fedora Kernels
Product:	[Fedora] Fedora	Reporter:	Robert Scheck <redhat-bugzilla>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	1
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-02-05 00:02:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert Scheck 2003-12-24 13:09:23 UTC

Description of problem and actual results:
After an update from Red Hat Linux 9 to Fedora Core 1 had I to state that the CAPI support is removed. That's invidious and bitchy! And there's no excuse for it. Yes, I know, that sentence is not very polite, but in my eyes still true.

In my eyes, the Fedora Kernel team violates against the own ojectives (http://fedora.redhat.com/about/objectives.html) - and the step to remove the CAPI support damages the users more than it helps.

So let me put the facts together: A team in the USA decides that the users in Europe don't need CAPI support any longer. Very friendly and user-oriented</ironie>.

Yes, of course, I can rebuild my own kernel, but why is there a distribution, then? If I have to rebuild my kernel to get basic features (!) needed in Europe, I don't need any distribution! I thought a distribution is there to make the use of Linux easier and more comfortable...but that fact doesn't seem to match at the Fedora Kernel :-( (yepp, I know that distribution != linux)

And yeah, I know we are only in the "old Europe"...but your thinking destroys in my eyes the work of programmers, which coded the CAPI support to the Linux kernel. And the reason, that Europe is still ignored at development can't be used, because then you've got to remove crypt routines and programes from Fedora, too. They aren't allowed in some countries...

Last but not least: The modular implementation of CAPI in further Fedora kernels doesn't cause any license conflicts! Also I can't see any reason why that mistake was done.

Sorry, for the partially very unpolite and direct things, I wrote. But in my personal opinion, it's fact. Maybe you can teach me something better and reimplement the CAPI support?!

Version-Release number of selected component (if applicable):
ALL Fedora Kernels

Expected results:
CAPI support in the next kernel rebuild for Fedora and any further kernels in the Fedora distribution.

Comment 1 Arjan van de Ven 2003-12-24 13:11:54 UTC

CONFIG_ISDN_CAPI=m
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m

/me thinks CAPI hasn't been removed at all

Comment 2 Arjan van de Ven 2003-12-24 13:14:09 UTC

CAPI indeed is GPL so it's compatible with the linux kernel indeed

Comment 3 Robert Scheck 2003-12-24 13:29:45 UTC

All correct, you said, but (maybe I wrote that text too early and):

--- snipp ---
-rwxr--r--    1 root    root            23356 Dez 15 22:03 /lib/modules/2.4.22-1.2135.nptl/unsupported/drivers/isdn/avmb1/capi.o
-rwxr--r--    1 root    root            33964 Dez 15 22:03 /lib/modules/2.4.22-1.2135.nptl/unsupported/drivers/isdn/avmb1/capidrv.o
-rwxr--r--    1 root    root             7264 Dez 15 22:03 /lib/modules/2.4.22-1.2135.nptl/unsupported/drivers/isdn/avmb1/capifs.o
-rwxr--r--    1 root    root            20668 Dez 15 22:03 /lib/modules/2.4.22-1.2135.nptl/unsupported/drivers/isdn/avmb1/capiutil.o
-rwxr--r--    1 root    root            24340 Dez 15 22:03 /lib/modules/2.4.22-1.2135.nptl/unsupported/drivers/isdn/avmb1/kernelcapi.o
--- snapp ---

All corresponding CAPI modules are moved to "unsupported". So at times of Red Hat Linux, "unsupporte modules" were removed from the kernel in one of the next versions. 

You'll really and fixed say, that this isn't case at Fedora Core?

Comment 4 Arjan van de Ven 2003-12-24 13:36:35 UTC

"unsupported" means we won't actively go try to fix bugs in things;
not that we plan to remove it in the future.
(Having said that, the 2.6 kernel has a reworked ISDN system and I
don't know if and how that has CAPI)

Comment 5 Robert Scheck 2003-12-24 22:38:59 UTC

But the singularity of the Fedora kernel to use non-standardized directory trees like "unsupported" is a problem e.g. for external drivers and programs, especially in this case for the AVM CAPI 2.0 drivers (these are used for internal DSL modems). There aren't always patchable sources from external drivers to recompile them for the non-standard-Fedora kernel - which needs time and work, too.

So I mark "unsupported" for the CAPI drivers as a bug...could you please solve this problem? Would be very nice :)

BTW: Yes, 2.6 has a reworked ISDN system, but ISDN HiSAX will be in the future removed and replaced by ISDN CAPI. But this replacement is done step by step, because it affects big parts of the telekommunication layer.

All in all, it should be reason enough, to move CAPI also in 2.4 from unsupported to the normal Kernel module hierarchy.

Comment 6 Joachim 2004-02-04 21:12:19 UTC

Dear Arjan,
I would strongly suggest to include CAPI support to the current and to
future releases of Fedora Linux.  Why that?  Rather simply because it
is one of the core features for your core audience -- at least in
Europe.  If Fedora aims at the home desktop user, ISDN is of utmost
importance, not only in Germany but also in other contries such as
Italy, Spain, France, Scandinavia, etc.  In these countries, ISDN is
the standard telephony solution for most home computer users.  If
Fedora wants to keep its user base or even extend it, ISDN support is
crucial.  Please keep in mind that there are other popular and
user-friendly distributions like Mandrake and SuSE.

Therefore, I can only recommend to tackle potential issues with IP
(which seems to be easy accourding to what Robert wrote) and actively
support CAPI in current and future releases of Fedora.

Thanks!

Comment 7 Dave Jones 2004-02-05 00:02:43 UTC

It is there already. It's unsupported. This is not changing.
The fact its in an 'unsupported' directory means absolutely nothing to
the usability of these modules. They just imply that we will not
actively fix bugs there, but instead point folks upstream.

closing as NOTABUG _again_.