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

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

[Adrian Bunk]

The patch below removes 41 unneeded EXPORT_SYMBOL's.


diffstat output:
 drivers/ieee1394/ieee1394_core.c |   41 -------------------------------
 1 files changed, 41 deletions(-)


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.10-rc3-mm1-full/drivers/ieee1394/ieee1394_core.c.old	2004-12-20 01:24:23.000000000 +0100
+++ linux-2.6.10-rc3-mm1-full/drivers/ieee1394/ieee1394_core.c	2004-12-20 02:31:01.000000000 +0100
@@ -1194,9 +1194,7 @@
 EXPORT_SYMBOL(hpsb_set_packet_complete_task);
 EXPORT_SYMBOL(hpsb_alloc_packet);
 EXPORT_SYMBOL(hpsb_free_packet);
-EXPORT_SYMBOL(hpsb_send_phy_config);
 EXPORT_SYMBOL(hpsb_send_packet);
-EXPORT_SYMBOL(hpsb_send_packet_and_wait);
 EXPORT_SYMBOL(hpsb_reset_bus);
 EXPORT_SYMBOL(hpsb_bus_reset);
 EXPORT_SYMBOL(hpsb_selfid_received);
@@ -1214,11 +1212,6 @@
 EXPORT_SYMBOL(hpsb_make_lock64packet);
 EXPORT_SYMBOL(hpsb_make_phypacket);
 EXPORT_SYMBOL(hpsb_make_isopacket);
-EXPORT_SYMBOL(hpsb_read);
-EXPORT_SYMBOL(hpsb_write);
-EXPORT_SYMBOL(hpsb_lock);
-EXPORT_SYMBOL(hpsb_lock64);
-EXPORT_SYMBOL(hpsb_send_gasp);
 EXPORT_SYMBOL(hpsb_packet_success);
 
 /** highlevel.c **/
@@ -1230,32 +1223,19 @@
 EXPORT_SYMBOL(hpsb_listen_channel);
 EXPORT_SYMBOL(hpsb_unlisten_channel);
 EXPORT_SYMBOL(hpsb_get_hostinfo);
-EXPORT_SYMBOL(hpsb_get_host_bykey);
 EXPORT_SYMBOL(hpsb_create_hostinfo);
 EXPORT_SYMBOL(hpsb_destroy_hostinfo);
 EXPORT_SYMBOL(hpsb_set_hostinfo_key);
-EXPORT_SYMBOL(hpsb_get_hostinfo_key);
 EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
 EXPORT_SYMBOL(hpsb_set_hostinfo);
-EXPORT_SYMBOL(highlevel_read);
-EXPORT_SYMBOL(highlevel_write);
-EXPORT_SYMBOL(highlevel_lock);
-EXPORT_SYMBOL(highlevel_lock64);
-EXPORT_SYMBOL(highlevel_add_host);
-EXPORT_SYMBOL(highlevel_remove_host);
 EXPORT_SYMBOL(highlevel_host_reset);
 
 /** nodemgr.c **/
-EXPORT_SYMBOL(hpsb_guid_get_entry);
-EXPORT_SYMBOL(hpsb_nodeid_get_entry);
 EXPORT_SYMBOL(hpsb_node_fill_packet);
-EXPORT_SYMBOL(hpsb_node_read);
 EXPORT_SYMBOL(hpsb_node_write);
-EXPORT_SYMBOL(hpsb_node_lock);
 EXPORT_SYMBOL(hpsb_register_protocol);
 EXPORT_SYMBOL(hpsb_unregister_protocol);
 EXPORT_SYMBOL(ieee1394_bus_type);
-EXPORT_SYMBOL(nodemgr_for_each_host);
 
 /** csr.c **/
 EXPORT_SYMBOL(hpsb_update_config_rom);
@@ -1292,32 +1272,11 @@
 EXPORT_SYMBOL(hpsb_iso_recv_flush);
 
 /** csr1212.c **/
-EXPORT_SYMBOL(csr1212_create_csr);
-EXPORT_SYMBOL(csr1212_init_local_csr);
-EXPORT_SYMBOL(csr1212_new_immediate);
-EXPORT_SYMBOL(csr1212_new_leaf);
-EXPORT_SYMBOL(csr1212_new_csr_offset);
 EXPORT_SYMBOL(csr1212_new_directory);
-EXPORT_SYMBOL(csr1212_associate_keyval);
 EXPORT_SYMBOL(csr1212_attach_keyval_to_directory);
-EXPORT_SYMBOL(csr1212_new_extended_immediate);
-EXPORT_SYMBOL(csr1212_new_extended_leaf);
-EXPORT_SYMBOL(csr1212_new_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_textual_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_string_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_icon_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_modifiable_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_keyword_leaf);
 EXPORT_SYMBOL(csr1212_detach_keyval_from_directory);
-EXPORT_SYMBOL(csr1212_disassociate_keyval);
 EXPORT_SYMBOL(csr1212_release_keyval);
-EXPORT_SYMBOL(csr1212_destroy_csr);
 EXPORT_SYMBOL(csr1212_read);
-EXPORT_SYMBOL(csr1212_generate_positions);
-EXPORT_SYMBOL(csr1212_generate_layout_order);
-EXPORT_SYMBOL(csr1212_fill_cache);
-EXPORT_SYMBOL(csr1212_generate_csr_image);
 EXPORT_SYMBOL(csr1212_parse_keyval);
-EXPORT_SYMBOL(csr1212_parse_csr);
 EXPORT_SYMBOL(_csr1212_read_keyval);
 EXPORT_SYMBOL(_csr1212_destroy_keyval);

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

[Dan Dennedy]

On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> The patch below removes 41 unneeded EXPORT_SYMBOL's.

Unneeded according to whom, just you? These functions are part of an
API. How do I know someone is not using these in a custom ieee1394
kernel module in some industrial or research setting or something new
under development to be contributed to linux1394 project?

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

[Adrian Bunk]

On Sun, Dec 19, 2004 at 09:10:10PM -0500, Dan Dennedy wrote:
> On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> > The patch below removes 41 unneeded EXPORT_SYMBOL's.
> 
> Unneeded according to whom, just you? These functions are part of an
> API. How do I know someone is not using these in a custom ieee1394
> kernel module in some industrial or research setting or something new
> under development to be contributed to linux1394 project?

If someone uses some of them in code to be contributed to the linux1394 
project, re-adding the EXPORT_SYMBOL's in question is trivial.

If someone uses some of them in a custom setting, re-adding them is 
trivial, too.

If the only user of one or more of these EXPORT_SYMBOL's was a non-free 
module, it's kernel policy that the EXPORT_SYMBOL's in question have to 
be removed.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Lee Revell]

On Mon, 2004-12-20 at 03:25 +0100, Adrian Bunk wrote:
> On Sun, Dec 19, 2004 at 09:10:10PM -0500, Dan Dennedy wrote:
> > On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> > > The patch below removes 41 unneeded EXPORT_SYMBOL's.
> > 
> > Unneeded according to whom, just you? These functions are part of an
> > API. How do I know someone is not using these in a custom ieee1394
> > kernel module in some industrial or research setting or something new
> > under development to be contributed to linux1394 project?
> 
> If someone uses some of them in code to be contributed to the linux1394 
> project, re-adding the EXPORT_SYMBOL's in question is trivial.
> 
> If someone uses some of them in a custom setting, re-adding them is 
> trivial, too.
> 
> If the only user of one or more of these EXPORT_SYMBOL's was a non-free 
> module, it's kernel policy that the EXPORT_SYMBOL's in question have to 
> be removed.

What do you tell a vendor who wants to write a driver for their device?
"OK, about half the functions you need are in the kernel, the other half
you have to port from this old kernel because we removed them.  Maybe we
will put them back if we really like your driver"?

Lee

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

[Dan Dennedy]

On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> On Mon, 2004-12-20 at 03:25 +0100, Adrian Bunk wrote:
> > On Sun, Dec 19, 2004 at 09:10:10PM -0500, Dan Dennedy wrote:
> > > On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> > > > The patch below removes 41 unneeded EXPORT_SYMBOL's.
> > > 
> > > Unneeded according to whom, just you? These functions are part of an
> > > API. How do I know someone is not using these in a custom ieee1394
> > > kernel module in some industrial or research setting or something new
> > > under development to be contributed to linux1394 project?
> > 
> > If someone uses some of them in code to be contributed to the linux1394 
> > project, re-adding the EXPORT_SYMBOL's in question is trivial.
> > 
> > If someone uses some of them in a custom setting, re-adding them is 
> > trivial, too.
> > 
> > If the only user of one or more of these EXPORT_SYMBOL's was a non-free 
> > module, it's kernel policy that the EXPORT_SYMBOL's in question have to 
> > be removed.
> 
> What do you tell a vendor who wants to write a driver for their device?
> "OK, about half the functions you need are in the kernel, the other half
> you have to port from this old kernel because we removed them.  Maybe we
> will put them back if we really like your driver"?

While I think some of Adrian's points are valid, I am exercising caution
because I am a new maintainer for linux1394 (although not new to the
project in general). This is an interface version management issue IMHO.
Adrian is not suggesting to remove the functions yet, but it is
effectively the same thing to an outsider. A vendor or services provider
would have to modify kernel source to let their driver work again, which
is not technically challenging to kernel hackers, but frustrating
situation to be in as a vendor or customer. It creates a mess in
support, distribution, deployment, etc.

Do I have specific examples where removing these symbols would cause
breakage? No, but I do provide contracted services based on linux1394, I
know of a guy developing a v4l2 driver that likely needs some of these,
and some have been considering new alsa and v4l2 drivers that could use
these. Besides, there is a lot in the wild we do not know about - free
or non-free. It would suck to say you can not use these custom or new
drivers on your distro's kernel and you need to wait for an upgrade if
not willing to customize and compile.

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

[Arne Caspari]

Adrian,

Some of these symbols are used by the open source driver "video-2-1394" 
( http://sourceforge.net/projects/video-2-1394 ).

This driver is supported by The Imaging Source Europe GmbH and used by 
quite a few of our customers. For most of these customers, it is OK to 
compile the driver but not to modify the kernel source.

Please please, do not break the kernel API out of the blue. Supporting a 
Linux driver is already very frustrating. Currently it is a lot more 
convenient for our customers to switch to Windows just because the 
installation and use of the software is much easier there - or at least 
it is easy enough there to handle the installation where it is not on Linux.

Breaking the API now will most likely stop The Imaging Source from 
supporting open source driver development anymore. We just can not 
effort any unneccessary development anymore. We are already blocked by 
shortcomings in the LDM and bugs in the Linux driver handling ( see my 
posings about a hotplugging issue and about the issue that IEEE-1394 
modules can not be unloaded ).

Thanks and best regards,

Arne Caspari

The Imaging Source Europe GmbH




Adrian Bunk wrote:
> The patch below removes 41 unneeded EXPORT_SYMBOL's.
> 
> 
> diffstat output:
>  drivers/ieee1394/ieee1394_core.c |   41 -------------------------------
>  1 files changed, 41 deletions(-)

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

[Arjan van de Ven]

On Mon, 2004-12-20 at 10:01 +0100, Arne Caspari wrote:
> Adrian,
> 
> Some of these symbols are used by the open source driver "video-2-1394" 
> ( http://sourceforge.net/projects/video-2-1394 ).


are you going to submit that driver for inclusion any time soon ?

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

[Arne Caspari]

Reply to the mail from Arjan van de Ven (arjan@infradead.org):

> On Mon, 2004-12-20 at 10:01 +0100, Arne Caspari wrote:
> > Adrian,
> > 
> > Some of these symbols are used by the open source driver "video-2-1394" 
> > ( http://sourceforge.net/projects/video-2-1394 ).
> 
> 
> are you going to submit that driver for inclusion any time soon ?

What would be the benefit if I do so? I have no access to linux1394 SVN or kernel repositories so I can only support the version on sourceforge. 

 -Arne

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

[Alan Cox]

On Llu, 2004-12-20 at 13:20, Arne Caspari wrote:
> > are you going to submit that driver for inclusion any time soon ?
> 
> What would be the benefit if I do so? I have no access to linux1394 SVN or kernel repositories so I can only support the version on sourceforge. 

Everyone can submit patches to the kernel tree. If your driver is open
source and you and your customers would benefit from having it just work
out of the box with distributions please consider submitting it. It also
helps maintainability because it becomes obvious when something will
break your driver and people can code accordingly (or submit fixes that
also fix up your driver code).

Alan

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

[Ben Collins]

How about adding those exports into an config option ifdef that says
"Export extra IEEE-1394 symbols" and in the help explains that the symbols
may be needed for some third party modules. Give video-2-1394 as an
example.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

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

[Alan Cox]

On Llu, 2004-12-20 at 14:39, Ben Collins wrote:
> How about adding those exports into an config option ifdef that says
> "Export extra IEEE-1394 symbols" and in the help explains that the symbols
> may be needed for some third party modules. Give video-2-1394 as an
> example.

You might as well remove the ifdef if you do that since vendors will
have to guess what the right answer is an will probably uniformly say
"Y". At that point its basically a non-option. Far better to submit the
driver

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

[Ben Collins]

On Mon, Dec 20, 2004 at 03:15:18PM +0000, Alan Cox wrote:
> On Llu, 2004-12-20 at 14:39, Ben Collins wrote:
> > How about adding those exports into an config option ifdef that says
> > "Export extra IEEE-1394 symbols" and in the help explains that the symbols
> > may be needed for some third party modules. Give video-2-1394 as an
> > example.
> 
> You might as well remove the ifdef if you do that since vendors will
> have to guess what the right answer is an will probably uniformly say
> "Y". At that point its basically a non-option. Far better to submit the
> driver

You are missing the point though. Lots of these are part of our API, and
may be used at anytime. Lots of college kids are emailing me about
projects they are working on, and quite a few of them are using this API.
None of those projects will ever get out of the classroom, much less get
into the kernel mainline. But that API is needed, none-the-less, to expose
the internals of the system.

I'd hate to think that our "license" worries outweigh the small hacker
community for some projects.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
WatchGuard - http://www.watchguard.com/

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

[Adrian Bunk]

On Mon, Dec 20, 2004 at 10:01:20AM +0100, Arne Caspari wrote:

> Adrian,

Hi Arne,

> Some of these symbols are used by the open source driver "video-2-1394" 
> ( http://sourceforge.net/projects/video-2-1394 ).
> 
> This driver is supported by The Imaging Source Europe GmbH and used by 
> quite a few of our customers. For most of these customers, it is OK to 
> compile the driver but not to modify the kernel source.
> 
> Please please, do not break the kernel API out of the blue. Supporting a 
> Linux driver is already very frustrating. Currently it is a lot more 
> convenient for our customers to switch to Windows just because the 
> installation and use of the software is much easier there - or at least 
> it is easy enough there to handle the installation where it is not on Linux.
> 
> Breaking the API now will most likely stop The Imaging Source from 
> supporting open source driver development anymore. We just can not 
> effort any unneccessary development anymore. We are already blocked by 
> shortcomings in the LDM and bugs in the Linux driver handling ( see my 
> posings about a hotplugging issue and about the issue that IEEE-1394 
> modules can not be unloaded ).

the perfect solution would be if you'd simply submit your driver for 
inclusion in the main kernel.

After grepping through your CVS sources, it seems hpsb_read and 
hpsb_write are the EXPORT_SYMBOLS affecting you?
So keeping them should address your concerns?

> Thanks and best regards,
> 
> Arne Caspari
> 
> The Imaging Source Europe GmbH

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Alan Cox]

On Llu, 2004-12-20 at 15:46, Ben Collins wrote:
> > You might as well remove the ifdef if you do that since vendors will
> > have to guess what the right answer is an will probably uniformly say
> > "Y". At that point its basically a non-option. Far better to submit the
> > driver
> 
> You are missing the point though. Lots of these are part of our API, and

I think you missed my point. Any vendor faced with that Config option
will say Y so almost every tree will always have it - so why ask as
opposed to keeping the status quo.

> into the kernel mainline. But that API is needed, none-the-less, to expose
> the internals of the system.
> 
> I'd hate to think that our "license" worries outweigh the small hacker
> community for some projects.

Sure but if Adrian was trying to just tidy licensing issues he'd submit
a switch to EXPORT_SYMBOL_GPL. (Admittedly for anything as closely tied
as the innards of the ieee1394 layer its probably implied anyway).

There are two conflicting goals here - to have clean complete API's and
to stamp out the large number of unused, historic and at times bogus
exports. If these API's are needed and used then they should stay just
as some others elsewhere in the kernel have.

Think of it as a case of the office cleaner having not realised the pile
of paper on the floor was important, thats all.

As to the video stuff - merging that is a parallel but unrelated
question and it seems it would be benefical to all involved.

Alan

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

[Lee Revell]

On Mon, 2004-12-20 at 18:51 +0100, Adrian Bunk wrote:
> > Please please, do not break the kernel API out of the blue. Supporting a 
> > Linux driver is already very frustrating. Currently it is a lot more 
> > convenient for our customers to switch to Windows just because the 
> > installation and use of the software is much easier there - or at least 
> > it is easy enough there to handle the installation where it is not on Linux.
> > 
> > Breaking the API now will most likely stop The Imaging Source from 
> > supporting open source driver development anymore. We just can not 
> > effort any unneccessary development anymore. We are already blocked by 
> > shortcomings in the LDM and bugs in the Linux driver handling ( see my 
> > posings about a hotplugging issue and about the issue that IEEE-1394 
> > modules can not be unloaded ).
> 
> the perfect solution would be if you'd simply submit your driver for 
> inclusion in the main kernel.
> 
> After grepping through your CVS sources, it seems hpsb_read and 
> hpsb_write are the EXPORT_SYMBOLS affecting you?
> So keeping them should address your concerns?

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?

Lee

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

[girish wadhwani]

> 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   
> 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
>

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

[Adrian Bunk]

On Sun, Dec 19, 2004 at 11:27:50PM -0500, Dan Dennedy wrote:
> On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> > On Mon, 2004-12-20 at 03:25 +0100, Adrian Bunk wrote:
> > > On Sun, Dec 19, 2004 at 09:10:10PM -0500, Dan Dennedy wrote:
> > > > On Mon, 2004-12-20 at 02:53 +0100, Adrian Bunk wrote:
> > > > > The patch below removes 41 unneeded EXPORT_SYMBOL's.
> > > > 
> > > > Unneeded according to whom, just you? These functions are part of an
> > > > API. How do I know someone is not using these in a custom ieee1394
> > > > kernel module in some industrial or research setting or something new
> > > > under development to be contributed to linux1394 project?
> > > 
> > > If someone uses some of them in code to be contributed to the linux1394 
> > > project, re-adding the EXPORT_SYMBOL's in question is trivial.
> > > 
> > > If someone uses some of them in a custom setting, re-adding them is 
> > > trivial, too.
> > > 
> > > If the only user of one or more of these EXPORT_SYMBOL's was a non-free 
> > > module, it's kernel policy that the EXPORT_SYMBOL's in question have to 
> > > be removed.
> > 
> > What do you tell a vendor who wants to write a driver for their device?
> > "OK, about half the functions you need are in the kernel, the other half
> > you have to port from this old kernel because we removed them.  Maybe we
> > will put them back if we really like your driver"?
> 
> While I think some of Adrian's points are valid, I am exercising caution
> because I am a new maintainer for linux1394 (although not new to the
> project in general). This is an interface version management issue IMHO.
> Adrian is not suggesting to remove the functions yet, but it is
> effectively the same thing to an outsider. A vendor or services provider
> would have to modify kernel source to let their driver work again, which
> is not technically challenging to kernel hackers, but frustrating
> situation to be in as a vendor or customer. It creates a mess in
> support, distribution, deployment, etc.

The solution is simple:
The vendor or services provider submits his driver for inclusion into 
the kernel which is the best solution for everyone.

> Do I have specific examples where removing these symbols would cause
> breakage? No, but I do provide contracted services based on linux1394, I
> know of a guy developing a v4l2 driver that likely needs some of these,
> and some have been considering new alsa and v4l2 drivers that could use
> these. Besides, there is a lot in the wild we do not know about - free
> or non-free. It would suck to say you can not use these custom or new
> drivers on your distro's kernel and you need to wait for an upgrade if
> not willing to customize and compile.

You didn't explicitely say whether the results of the contracted 
services you offer are free or non-free.

If the result is free, inclusion into the kernel is simply the optimal 
solution.

If the result is non-free, it;s kernel policy that there are no 
EXPORT_SYMBOL's specifically for non-free modules (and that a free 
module might some day use them is not a reason).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Lee Revell]

On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> On Sun, Dec 19, 2004 at 11:27:50PM -0500, Dan Dennedy wrote:
> > On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> > > What do you tell a vendor who wants to write a driver for their device?
> > > "OK, about half the functions you need are in the kernel, the other half
> > > you have to port from this old kernel because we removed them.  Maybe we
> > > will put them back if we really like your driver"?
> > 
> > While I think some of Adrian's points are valid, I am exercising caution
> > because I am a new maintainer for linux1394 (although not new to the
> > project in general). This is an interface version management issue IMHO.
> > Adrian is not suggesting to remove the functions yet, but it is
> > effectively the same thing to an outsider. A vendor or services provider
> > would have to modify kernel source to let their driver work again, which
> > is not technically challenging to kernel hackers, but frustrating
> > situation to be in as a vendor or customer. It creates a mess in
> > support, distribution, deployment, etc.
> 
> The solution is simple:
> The vendor or services provider submits his driver for inclusion into 
> the kernel which is the best solution for everyone.
> 

What if the driver is under development and doesn't work yet?

Lee

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

[Adrian Bunk]

On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > On Sun, Dec 19, 2004 at 11:27:50PM -0500, Dan Dennedy wrote:
> > > On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> > > > What do you tell a vendor who wants to write a driver for their device?
> > > > "OK, about half the functions you need are in the kernel, the other half
> > > > you have to port from this old kernel because we removed them.  Maybe we
> > > > will put them back if we really like your driver"?
> > > 
> > > While I think some of Adrian's points are valid, I am exercising caution
> > > because I am a new maintainer for linux1394 (although not new to the
> > > project in general). This is an interface version management issue IMHO.
> > > Adrian is not suggesting to remove the functions yet, but it is
> > > effectively the same thing to an outsider. A vendor or services provider
> > > would have to modify kernel source to let their driver work again, which
> > > is not technically challenging to kernel hackers, but frustrating
> > > situation to be in as a vendor or customer. It creates a mess in
> > > support, distribution, deployment, etc.
> > 
> > The solution is simple:
> > The vendor or services provider submits his driver for inclusion into 
> > the kernel which is the best solution for everyone.
> > 
> 
> What if the driver is under development and doesn't work yet?

For a driver developer, it shouldn't be a big problem to re-add an 
EXPORT_SYMBOL or even to undo an #if 0 of a currently unused function.

> Lee

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Lee Revell]

On Tue, 2004-12-21 at 00:02 +0100, Adrian Bunk wrote:
> On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> > On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > > On Sun, Dec 19, 2004 at 11:27:50PM -0500, Dan Dennedy wrote:
> > > > On Sun, 2004-12-19 at 21:42 -0500, Lee Revell wrote:
> > > > > What do you tell a vendor who wants to write a driver for their device?
> > > > > "OK, about half the functions you need are in the kernel, the other half
> > > > > you have to port from this old kernel because we removed them.  Maybe we
> > > > > will put them back if we really like your driver"?
> > > > 
> > > > While I think some of Adrian's points are valid, I am exercising caution
> > > > because I am a new maintainer for linux1394 (although not new to the
> > > > project in general). This is an interface version management issue IMHO.
> > > > Adrian is not suggesting to remove the functions yet, but it is
> > > > effectively the same thing to an outsider. A vendor or services provider
> > > > would have to modify kernel source to let their driver work again, which
> > > > is not technically challenging to kernel hackers, but frustrating
> > > > situation to be in as a vendor or customer. It creates a mess in
> > > > support, distribution, deployment, etc.
> > > 
> > > The solution is simple:
> > > The vendor or services provider submits his driver for inclusion into 
> > > the kernel which is the best solution for everyone.
> > > 
> > 
> > What if the driver is under development and doesn't work yet?
> 
> For a driver developer, it shouldn't be a big problem to re-add an 
> EXPORT_SYMBOL or even to undo an #if 0 of a currently unused function.
> 

OK, fair enough.  The lack of any IEEE-1394 audio support has been a big
topic on alsa-devel and I just want to make sure we don't do anything
that would make life more difficult for vendors trying to get their
hardware supported.  Keep in mind that many vendors only have dealt with
Windows and OSX drivers, so their driver developers might be very
skilled but have not dealt with Linux before - they are used to working
with published APIs.

Anyway since the freebob project does not care about these I have no
objection to unexporting them.

Lee

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

[Alan Cox]

On Llu, 2004-12-20 at 23:02, Adrian Bunk wrote:
> > What if the driver is under development and doesn't work yet?
> 
> For a driver developer, it shouldn't be a big problem to re-add an 
> EXPORT_SYMBOL or even to undo an #if 0 of a currently unused function.

Except that the driver author now has to compile entire kernels, can't
redistribute it easily to others for testing without them all rebuilding
the kernel and has no idea of what things the author intended to be API.
In this case it isnt a clean up, but a game plan to reduce the amount
and quality of driver submission. 

On this one you've clearly gone too far. USB had a pile of API functions
before drivers used them, video4linux did the same and that made sense
just like this does.  Tidy it up in 12-18 months when the drivers exist
to know what is worth keeping and what should be removed.

Alan

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

[Adrian Bunk]

On Mon, Dec 20, 2004 at 06:51:56PM +0100, Adrian Bunk wrote:
>...
> After grepping through your CVS sources, it seems hpsb_read and 
> hpsb_write are the EXPORT_SYMBOLS affecting you?
> So keeping them should address your concerns?
>...


Updated patch that no longer removes these two EXPORT_SYMBOL's:


<--  snip  -->


The patch below removes 39 unneeded EXPORT_SYMBOL's.


diffstat output:
 drivers/ieee1394/ieee1394_core.c |   39 -------------------------------
 1 files changed, 39 deletions(-)


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.10-rc3-mm1-full/drivers/ieee1394/ieee1394_core.c.old	2004-12-20 01:24:23.000000000 +0100
+++ linux-2.6.10-rc3-mm1-full/drivers/ieee1394/ieee1394_core.c	2004-12-21 00:36:49.000000000 +0100
@@ -1194,9 +1194,7 @@
 EXPORT_SYMBOL(hpsb_set_packet_complete_task);
 EXPORT_SYMBOL(hpsb_alloc_packet);
 EXPORT_SYMBOL(hpsb_free_packet);
-EXPORT_SYMBOL(hpsb_send_phy_config);
 EXPORT_SYMBOL(hpsb_send_packet);
-EXPORT_SYMBOL(hpsb_send_packet_and_wait);
 EXPORT_SYMBOL(hpsb_reset_bus);
 EXPORT_SYMBOL(hpsb_bus_reset);
 EXPORT_SYMBOL(hpsb_selfid_received);
@@ -1216,9 +1214,6 @@
 EXPORT_SYMBOL(hpsb_make_isopacket);
 EXPORT_SYMBOL(hpsb_read);
 EXPORT_SYMBOL(hpsb_write);
-EXPORT_SYMBOL(hpsb_lock);
-EXPORT_SYMBOL(hpsb_lock64);
-EXPORT_SYMBOL(hpsb_send_gasp);
 EXPORT_SYMBOL(hpsb_packet_success);
 
 /** highlevel.c **/
@@ -1230,32 +1225,19 @@
 EXPORT_SYMBOL(hpsb_listen_channel);
 EXPORT_SYMBOL(hpsb_unlisten_channel);
 EXPORT_SYMBOL(hpsb_get_hostinfo);
-EXPORT_SYMBOL(hpsb_get_host_bykey);
 EXPORT_SYMBOL(hpsb_create_hostinfo);
 EXPORT_SYMBOL(hpsb_destroy_hostinfo);
 EXPORT_SYMBOL(hpsb_set_hostinfo_key);
-EXPORT_SYMBOL(hpsb_get_hostinfo_key);
 EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
 EXPORT_SYMBOL(hpsb_set_hostinfo);
-EXPORT_SYMBOL(highlevel_read);
-EXPORT_SYMBOL(highlevel_write);
-EXPORT_SYMBOL(highlevel_lock);
-EXPORT_SYMBOL(highlevel_lock64);
-EXPORT_SYMBOL(highlevel_add_host);
-EXPORT_SYMBOL(highlevel_remove_host);
 EXPORT_SYMBOL(highlevel_host_reset);
 
 /** nodemgr.c **/
-EXPORT_SYMBOL(hpsb_guid_get_entry);
-EXPORT_SYMBOL(hpsb_nodeid_get_entry);
 EXPORT_SYMBOL(hpsb_node_fill_packet);
-EXPORT_SYMBOL(hpsb_node_read);
 EXPORT_SYMBOL(hpsb_node_write);
-EXPORT_SYMBOL(hpsb_node_lock);
 EXPORT_SYMBOL(hpsb_register_protocol);
 EXPORT_SYMBOL(hpsb_unregister_protocol);
 EXPORT_SYMBOL(ieee1394_bus_type);
-EXPORT_SYMBOL(nodemgr_for_each_host);
 
 /** csr.c **/
 EXPORT_SYMBOL(hpsb_update_config_rom);
@@ -1292,32 +1274,11 @@
 EXPORT_SYMBOL(hpsb_iso_recv_flush);
 
 /** csr1212.c **/
-EXPORT_SYMBOL(csr1212_create_csr);
-EXPORT_SYMBOL(csr1212_init_local_csr);
-EXPORT_SYMBOL(csr1212_new_immediate);
-EXPORT_SYMBOL(csr1212_new_leaf);
-EXPORT_SYMBOL(csr1212_new_csr_offset);
 EXPORT_SYMBOL(csr1212_new_directory);
-EXPORT_SYMBOL(csr1212_associate_keyval);
 EXPORT_SYMBOL(csr1212_attach_keyval_to_directory);
-EXPORT_SYMBOL(csr1212_new_extended_immediate);
-EXPORT_SYMBOL(csr1212_new_extended_leaf);
-EXPORT_SYMBOL(csr1212_new_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_textual_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_string_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_icon_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_modifiable_descriptor_leaf);
-EXPORT_SYMBOL(csr1212_new_keyword_leaf);
 EXPORT_SYMBOL(csr1212_detach_keyval_from_directory);
-EXPORT_SYMBOL(csr1212_disassociate_keyval);
 EXPORT_SYMBOL(csr1212_release_keyval);
-EXPORT_SYMBOL(csr1212_destroy_csr);
 EXPORT_SYMBOL(csr1212_read);
-EXPORT_SYMBOL(csr1212_generate_positions);
-EXPORT_SYMBOL(csr1212_generate_layout_order);
-EXPORT_SYMBOL(csr1212_fill_cache);
-EXPORT_SYMBOL(csr1212_generate_csr_image);
 EXPORT_SYMBOL(csr1212_parse_keyval);
-EXPORT_SYMBOL(csr1212_parse_csr);
 EXPORT_SYMBOL(_csr1212_read_keyval);
 EXPORT_SYMBOL(_csr1212_destroy_keyval);

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

[Arne Caspari]

Alan Cox wrote:
> On Llu, 2004-12-20 at 15:46, Ben Collins wrote:
> 
>>>You might as well remove the ifdef if you do that since vendors will
>>>have to guess what the right answer is an will probably uniformly say
>>>"Y". At that point its basically a non-option. Far better to submit the
>>>driver
>>
>>You are missing the point though. Lots of these are part of our API, and
> 
> 
> I think you missed my point. Any vendor faced with that Config option
> will say Y so almost every tree will always have it - so why ask as
> opposed to keeping the status quo.

My concerns with this option is actually that some mainstream 
distribution will say "N" here accidentally. So every customer with this 
distribution will call us and require intense support. If Linux will 
cause intense support, it will just not be supported at all because 
Windows support is almost zero in this regard and we make almost zero 
profits with Linux sales - and 99.99 % of our income with Windows sales.

> Sure but if Adrian was trying to just tidy licensing issues he'd submit
> a switch to EXPORT_SYMBOL_GPL. (Admittedly for anything as closely tied
> as the innards of the ieee1394 layer its probably implied anyway).

I do not see the licensing issue of a stable kernel API where venders 
can rely on. Our driver is GPL so there should no be a licensing issue.


The reason why I have not submitted this driver is as follows:

If I submit a driver and there is a firmware change in our device that 
breaks compatibility to older drivers ( as there once was ), customers 
which get the new devices will have a driver that is not working. So 
each customer asks us for support and we need to guide him to replace 
the kernel driver with the new one. This situation will remain until 
mainstream distributions update their kernel.

In the current situation we just have a website which says that you have 
to get the driver from sourceforge and compile it yourself. This works 
rather good: Customers that bought a device automatically got the right 
driver. And if I need to make some changes in the driver ( ie. fix bugs 
or add functionality ), I do not need to wait until the patches go into 
mainstream distributions ( you can not wait for that ) but just update 
the SF site and let the customer go through the same steps he already 
had gone through in the beginning.

It is all about avoiding ( expensive ) support. I can not stress this 
point enough: If supporting Linux becomes a cost factor it will just not 
be supported. There is virtually no profit for us in this market.

> There are two conflicting goals here - to have clean complete API's and
> to stamp out the large number of unused, historic and at times bogus
> exports. If these API's are needed and used then they should stay just
> as some others elsewhere in the kernel have.

On Windows I can rely on a stable kernel API for many years now. We have 
single drivers that work on the WindowsXP of today and also work on 
Windows 2000 which is almost 5 years old. They would most likely even 
work on Windows98 if we would support that platform. Windows circumvents 
the symbol export problem by using their IO Request Blocks etc. which 
makes things more complicated but at least stable.

Linux does not have such a model. So in my eyes, special care has to be 
taken to generate an API that is valid today and will remain valid for 
some years. Vendors need to be able to rely on a stable API.

I would take it like in a library: The API should not change between 
minor versions - likewise it should be stable in the kernel among all 
2.6.x versions. If it changes to version 2.7.x or 2.8.x it would be OK 
since we could release a driver for a 2.8.x tree then.

  /Arne

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

[Arne Caspari]

girish wadhwani wrote:
> 
> 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.

I also would like to write an ALSA audio driver for the Apple iSight and 
I can assure you: Removal of the exports will make this impossible to.

  /Arne

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

[Arne Caspari]

Adrian Bunk wrote:
> On Mon, Dec 20, 2004 at 06:51:56PM +0100, Adrian Bunk wrote:
> 
>>...
>>After grepping through your CVS sources, it seems hpsb_read and 
>>hpsb_write are the EXPORT_SYMBOLS affecting you?
>>So keeping them should address your concerns?
>>...

Adrian,

A stable API for the 2.6.x tree would address my concerns :-)

There is one thing missing in the module: It does not allocate 
bandwidth. This will require at least a compare_and_swap function. I 
have not looked into this yet but the required exports for this might be 
the "hpsb_lock" and "hpsb_lock64".

Interesting exports ( by looking through your patch ) would also be
EXPORT_SYMBOL(hpsb_guid_get_entry);
EXPORT_SYMBOL(hpsb_nodeid_get_entry);
Maybe they could be used to make the ConfigROM scan code in the driver 
more generic and cleaner? But if they will be removed, would it be 
better to leave the crappy version with hardcoded offsets in the driver?

I can not answer this question now since I am running low on battery and 
I do not have a power cord with me right now :-(

So to keep the current functionality: Yes, only the _read and _write 
functions are required.

  /Arne

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

[Bernard Leach]

The basis for removal of these exports was an alledged policy that
states unless there is at least one known opensource (GPL?) driver that
uses them they should not exist.  (I hope that paraphrase captured the
essence of the previous statements).

If this policy is as stated then its clearly short sighted.  If the
kernel is simply (the kernel and) the set of interfaces that support the
_existing_ drivers then that is all it will ever be.  I'm not saying
that is impossible for a driver writer to construct new interfaces that
their driver will require but I would suggest that in most cases this is
an unreasonable requirement.

APIs are a mechanism to export functionality from a particular
black-box, does it make sense that the constructor of that black-box
defines this API or some poor sod who has been given that black box on a
Friday afternoon and asked to deliver a driver on Monday?

Anyhow I think Ben has made it quite clear that this API exists for a
reason.

My point would be that waving some arbitrary policy around like the holy
grail does nothing to build a better kernel.

cheers,
bern.

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

[Adrian Bunk]

On Tue, Dec 21, 2004 at 09:33:45AM +0100, Arne Caspari wrote:
>...
> I would take it like in a library: The API should not change between 
> minor versions - likewise it should be stable in the kernel among all 
> 2.6.x versions. If it changes to version 2.7.x or 2.8.x it would be OK 
> since we could release a driver for a 2.8.x tree then.

The current development model published by Linus Torvalds and
Andrew Morton is that there will be no 2.7.x in the forseeable future, 
but instead the changes that would go into a 2.7 series go into the 2.6 
series...

>  /Arne

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Arne Caspari]

Adrian Bunk schrieb:

>On Tue, Dec 21, 2004 at 09:33:45AM +0100, Arne Caspari wrote:
>  
>
>>...
>>I would take it like in a library: The API should not change between 
>>minor versions - likewise it should be stable in the kernel among all 
>>2.6.x versions. If it changes to version 2.7.x or 2.8.x it would be OK 
>>since we could release a driver for a 2.8.x tree then.
>>    
>>
>
>The current development model published by Linus Torvalds and
>Andrew Morton is that there will be no 2.7.x in the forseeable future, 
>but instead the changes that would go into a 2.7 series go into the 2.6 
>series...
>  
>

To make a long decision short:

There is no stable kernel API that an external developer can rely on?
And this is by intent: The only way for a vendor to write a driver for 
Linux is to submit it to the kernel tree?

 /Arne

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

[Greg KH]

On Tue, Dec 21, 2004 at 09:46:15AM +0100, Arne Caspari wrote:
> Adrian Bunk wrote:
> >On Mon, Dec 20, 2004 at 06:51:56PM +0100, Adrian Bunk wrote:
> >
> >>...
> >>After grepping through your CVS sources, it seems hpsb_read and 
> >>hpsb_write are the EXPORT_SYMBOLS affecting you?
> >>So keeping them should address your concerns?
> >>...
> 
> Adrian,
> 
> A stable API for the 2.6.x tree would address my concerns :-)

Please read Documentation/stable_api_nonesense.txt for details about why
that will never happen :)

thanks,

greg k-h

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

[Greg KH]

On Tue, Dec 21, 2004 at 01:49:56PM +0100, Arne Caspari wrote:
> 
> To make a long decision short:
> 
> There is no stable kernel API that an external developer can rely on?

That is correct.  Please see Documentation/stable_api_nonsense.txt for
details as to why this is so.

> And this is by intent: The only way for a vendor to write a driver for 
> Linux is to submit it to the kernel tree?

That's the best way.  See the above mentioned file for details as to why
it is a benifit for you to submit it to the tree.

thanks,

greg k-h

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

[Greg KH]

On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > The solution is simple:
> > The vendor or services provider submits his driver for inclusion into 
> > the kernel which is the best solution for everyone.
> > 
> 
> What if the driver is under development and doesn't work yet?

Many drivers have been accepted into the kernel tree before they worked
properly :)

thanks,

greg k-h

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

[Lee Revell]

On Tue, 2004-12-21 at 09:17 -0800, Greg KH wrote:
> On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> > On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > > The solution is simple:
> > > The vendor or services provider submits his driver for inclusion into 
> > > the kernel which is the best solution for everyone.
> > > 
> > 
> > What if the driver is under development and doesn't work yet?
> 
> Many drivers have been accepted into the kernel tree before they worked
> properly :)

Yeah but I hope you can understand why someone would be hesitant to
submit a broken driver.  It just makes the author look bad.  I would not
feel right submitting something that didn't work.

Lee

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

[Greg KH]

On Tue, Dec 21, 2004 at 12:20:32PM -0500, Lee Revell wrote:
> On Tue, 2004-12-21 at 09:17 -0800, Greg KH wrote:
> > On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> > > On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > > > The solution is simple:
> > > > The vendor or services provider submits his driver for inclusion into 
> > > > the kernel which is the best solution for everyone.
> > > > 
> > > 
> > > What if the driver is under development and doesn't work yet?
> > 
> > Many drivers have been accepted into the kernel tree before they worked
> > properly :)
> 
> Yeah but I hope you can understand why someone would be hesitant to
> submit a broken driver.  It just makes the author look bad.  I would not
> feel right submitting something that didn't work.

Everyone has their own comfort levels :)

Anyway, a number of drivers have been submitted to the tree that were
never even tested on hardware (written only to specs).  Then, over time
they were properly debugged by people who had access to the hardware
(debugging over email does have long lags, but it works out in the end.)
An example of this was the first usb bluetooth driver.

But we are getting pretty far off-topic here, sorry.

greg k-h

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

[Arne Caspari]

Greg KH schrieb:

>On Tue, Dec 21, 2004 at 01:49:56PM +0100, Arne Caspari wrote:
>  
>
>>To make a long decision short:
>>
>>There is no stable kernel API that an external developer can rely on?
>>    
>>
>
>That is correct.  Please see Documentation/stable_api_nonsense.txt for
>details as to why this is so.
>
>  
>

There is no such file in the 2.6.9 release :-(

/Arne

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

[Greg KH]

On Tue, Dec 21, 2004 at 07:51:05PM +0100, Arne Caspari wrote:
> Greg KH schrieb:
> >On Tue, Dec 21, 2004 at 01:49:56PM +0100, Arne Caspari wrote:
> >>To make a long decision short:
> >>
> >>There is no stable kernel API that an external developer can rely on?
> >
> >That is correct.  Please see Documentation/stable_api_nonsense.txt for
> >details as to why this is so.
> 
> There is no such file in the 2.6.9 release :-(

It's in 2.6.10-rc3, and available online at:
	http://www.kroah.com/log/linux/stable_api_nonsense.html

thanks,

greg k-h

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

[Theodore Ts'o]

On Tue, Dec 21, 2004 at 12:20:32PM -0500, Lee Revell wrote:
> On Tue, 2004-12-21 at 09:17 -0800, Greg KH wrote:
> > On Mon, Dec 20, 2004 at 05:58:06PM -0500, Lee Revell wrote:
> > > On Mon, 2004-12-20 at 23:53 +0100, Adrian Bunk wrote:
> > > > The solution is simple:
> > > > The vendor or services provider submits his driver for inclusion into 
> > > > the kernel which is the best solution for everyone.
> > > > 
> > > 
> > > What if the driver is under development and doesn't work yet?
> > 
> > Many drivers have been accepted into the kernel tree before they worked
> > properly :)
> 
> Yeah but I hope you can understand why someone would be hesitant to
> submit a broken driver.  It just makes the author look bad.  I would not
> feel right submitting something that didn't work.

That's what CONFIG_EXPERIMENTAL is for....

						- Ted

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@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
>
>  
>

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

[Lee Revell]

On Wed, 2004-12-22 at 00:35 +0100, Pieter Palmers wrote:
> 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...

Ideally, not at all.  For example ALSA provides a very clean API for
driver writers.  If you know your hardware you could implement a driver
in a few days.

http://www.alsa-project.org/~iwai/writing-an-alsa-driver/

Lee

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

[Arjan van de Ven]

On Mon, 2004-12-20 at 14:20 +0100, Arne Caspari wrote:
> Reply to the mail from Arjan van de Ven (arjan@infradead.org):
> 
> > On Mon, 2004-12-20 at 10:01 +0100, Arne Caspari wrote:
> > > Adrian,
> > > 
> > > Some of these symbols are used by the open source driver "video-2-1394" 
> > > ( http://sourceforge.net/projects/video-2-1394 ).
> > 
> > 
> > are you going to submit that driver for inclusion any time soon ?
> 
> What would be the benefit if I do so? 

you get a lot more eyes on the code; other people help adjusting your
code to new apis etc etc

> I have no access to linux1394 SVN or kernel repositories 
> so I can only support the version on sourceforge. 

well.. you do have access to the kernel one basically; just submit well
isolated patches to akpm/linus and they'll show up in a not-too-long
time....

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

[Stefan Richter]

Arjan van de Ven wrote:
> On Mon, 2004-12-20 at 14:20 +0100, Arne Caspari wrote:
>>>are you going to submit that driver for inclusion any time soon ?
>>What would be the benefit if I do so? 
> you get a lot more eyes on the code; other people help adjusting your
> code to new apis etc etc

...which works best if submitters of patches remember to make use of the 
communication channels suggested in MAINTAINERS.
-- 
Stefan Richter
-=====-=-=-- ==-- =-==-
http://arcgraph.de/sr/

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

[Christoph Hellwig]

On Wed, Dec 22, 2004 at 09:57:48AM +0100, Stefan Richter wrote:
> Arjan van de Ven wrote:
> >On Mon, 2004-12-20 at 14:20 +0100, Arne Caspari wrote:
> >>>are you going to submit that driver for inclusion any time soon ?
> >>What would be the benefit if I do so? 
> >you get a lot more eyes on the code; other people help adjusting your
> >code to new apis etc etc
> 
> ...which works best if submitters of patches remember to make use of the 
> communication channels suggested in MAINTAINERS.

Except when those are disfunct, and hord their changes in CVS or SVN
repositories..

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

[Arne Caspari]

Christoph Hellwig wrote:
> Except when those are disfunct, and hord their changes in CVS or SVN
> repositories..

No flamewar, please.

linux1394 maintainers will give me SVN access to their repositories so 
the driver will go into the standard kernel anytime soon.

The way things go on Linux is just very uncommon for vendors and they 
can easily be scared off ( as I almost was ).

  /Arne

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

[Alan Cox]

On Maw, 2004-12-21 at 22:19, Theodore Ts'o wrote:
> > Yeah but I hope you can understand why someone would be hesitant to
> > submit a broken driver.  It just makes the author look bad.  I would not
> > feel right submitting something that didn't work.
> 
> That's what CONFIG_EXPERIMENTAL is for....

If the symbols are not there then this doesn't help vendors wanting to
produce GPL drivers because people have to rebuild entire kernels not
just add a driver. 

You are also ignoring the cultural issues and personal preferences that
lead some users not to submit code until it passes some quality level.
This is common in both businesses and individuals and you see it
regularly.

Alan

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

[Stefan Richter]

Christoph Hellwig wrote:
> On Wed, Dec 22, 2004 at 09:57:48AM +0100, Stefan Richter wrote:
>> ...which works best if submitters of patches remember to make use of the 
>> communication channels suggested in MAINTAINERS.
> Except when those are disfunct,

Correct, which is when MAINTAINERS needs to be updated.

> and hord their changes in CVS or SVN repositories..

An extra public repo is just a tool. Its effect depends on how skillful
it is used. But this is apriori unrelated to the consideration whether
to put a driver into mainline.
-- 
Stefan Richter
-=====-=-=-- ==-- =-==-
http://arcgraph.de/sr/