From: Pieter Palmers <pieterp@joow.be>
To: girish wadhwani <girish.wadh@gmail.com>
Cc: Lee Revell <rlrevell@joe-job.com>, Adrian Bunk <bunk@stusta.de>,
Arne Caspari <arnem@informatik.uni-bremen.de>,
bcollins@debian.org, linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
Date: Wed, 22 Dec 2004 00:35:12 +0100 [thread overview]
Message-ID: <41C8B330.8050803@joow.be> (raw)
In-Reply-To: <e2e1047f04122013493f5b0151@mail.gmail.com>
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
>
>
>
next prev parent reply other threads:[~2004-12-22 0:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-20 1:53 [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's Adrian Bunk
2004-12-20 2:10 ` Dan Dennedy
2004-12-20 2:25 ` Adrian Bunk
2004-12-20 2:42 ` Lee Revell
2004-12-20 4:27 ` Dan Dennedy
2004-12-20 22:53 ` Adrian Bunk
2004-12-20 22:58 ` Lee Revell
2004-12-20 23:02 ` Adrian Bunk
2004-12-20 23:21 ` Lee Revell
2004-12-21 0:40 ` Alan Cox
2004-12-21 17:17 ` Greg KH
2004-12-21 17:20 ` Lee Revell
2004-12-21 17:27 ` Greg KH
2004-12-21 22:19 ` Theodore Ts'o
2004-12-22 14:08 ` Alan Cox
2004-12-20 9:01 ` Arne Caspari
2004-12-20 12:15 ` Arjan van de Ven
2004-12-20 13:20 ` Arne Caspari
2004-12-20 14:35 ` Alan Cox
2004-12-22 8:29 ` Arjan van de Ven
2004-12-22 8:57 ` Stefan Richter
2004-12-22 12:01 ` Christoph Hellwig
2004-12-22 12:21 ` Arne Caspari
2004-12-22 16:04 ` Stefan Richter
2004-12-20 14:39 ` Ben Collins
2004-12-20 15:15 ` Alan Cox
2004-12-20 15:46 ` Ben Collins
2004-12-20 20:15 ` Alan Cox
2004-12-21 8:33 ` Arne Caspari
2004-12-21 12:00 ` Adrian Bunk
2004-12-21 12:49 ` Arne Caspari
2004-12-21 17:15 ` Greg KH
2004-12-21 18:51 ` Arne Caspari
2004-12-21 18:58 ` Greg KH
2004-12-20 17:51 ` Adrian Bunk
2004-12-20 21:05 ` Lee Revell
2004-12-20 21:49 ` girish wadhwani
2004-12-21 8:37 ` Arne Caspari
2004-12-21 9:06 ` Bernard Leach
2004-12-21 23:35 ` Pieter Palmers [this message]
2004-12-22 0:56 ` Lee Revell
2004-12-21 0:42 ` updated: " Adrian Bunk
2004-12-21 8:46 ` Arne Caspari
2004-12-21 17:13 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41C8B330.8050803@joow.be \
--to=pieterp@joow.be \
--cc=arnem@informatik.uni-bremen.de \
--cc=bcollins@debian.org \
--cc=bunk@stusta.de \
--cc=girish.wadh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=rlrevell@joe-job.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox