lkml.org 
[lkml]   [2004]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
girish wadhwani wrote:

>>Please, can't you just hold off on breaking the ieee1394 API at all for
>>now? Currently there are no supported IEEE-1394 audio devices. This is
>>a big deal as most new pro audio interfaces are IEEE-1394 devices.
>>There are a few under development, see http://freebob.sf.net. But they
>>don't work yet. If you rip out half the API you will make it that much
>>harder for these developers, by requiring them to be kernel hackers as
>>well as driver writers.
>>
>>How about waiting until there is _one_ IEEE-1394 audio driver in the
>>tree before breaking the API?
>>
>>
>
>I don't think the symbols are an issue for the Freebob project.
>Atleast, not right now. The code doesn't use the symbols. Most of the
>driver is intended to be in userspace anyways.
>Moreover, if you are going to break in the interface, you might as
>well do it before the driver
>is written rather than after.
>
>Just my 2c.
>
>-Girish
>
>
At this point were not looking at any kernel symbols at all. The driver
is intended indeed as a userspace driver, depending heavily on the
userspace libs available. I personally would go to kernel space only if
perfomance issues arise. Or maybe if implementing an ALSA kernel space
driver would be easier than implementing it in user space (small chance).

So wrt to the kernel symbols, I personally don't mind them changing... I
have to learn them from scratch anyway (as you point out).

And should we be implementing some sort of kernel driver, chances are
that it will only implement the AMDTP packaging and ISO transport.
Connection management and other non-RT tasks will most likely remain in
user space, based upon well-tested libs. So the number of interface
functions used will be rather small, and they will probably be available
anyway because other drivers also use them.

And isn't driver writing a bit of kernel hacking anyway? As far as I
know, you have to be very aware of kernel issues/internals when writing
a driver...

Greets,

Pieter Palmers
Freebob developer

>>Lee
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://productguide.itmanagersjournal.com/
>>_______________________________________________
>>mailing list linux1394-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/linux1394-devel
>>
>>
>>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://productguide.itmanagersjournal.com/
>_______________________________________________
>mailing list linux1394-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/linux1394-devel
>
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.105 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site