Bug 112605 - Missing CAPI support in Fedora Kernels
Missing CAPI support in Fedora Kernels
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2003-12-24 08:09 EST by Robert Scheck
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-04 19:02:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2003-12-24 08:09:23 EST
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 08:11:54 EST

/me thinks CAPI hasn't been removed at all
Comment 2 Arjan van de Ven 2003-12-24 08:14:09 EST
CAPI indeed is GPL so it's compatible with the linux kernel indeed
Comment 3 Robert Scheck 2003-12-24 08:29:45 EST
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 08:36:35 EST
"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 17:38:59 EST
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 16:12:19 EST
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.

Comment 7 Dave Jones 2004-02-04 19:02:43 EST
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_.

Note You need to log in before you can comment on or make changes to this bug.