Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's

[Pieter Palmers]

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@xxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/