ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
PATCH 1/1 ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
The patch below removes 41 unneeded EXPORT_SYMBOL's.
diffstat output:
drivers/ieee1394/ieee1394_core.c | 41 ------------------------------- 1 files changed, 41 deletions(-)
drivers/ieee1394/ieee1394_core.c renamed from drivers/ieee1394/ieee1394_core.c.old +0 -41
@@ -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);
Quoted 1 line · Adrian Bunk
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?
Quoted 7 lines · Dan Dennedy
Quoted 1 line · Adrian Bunk
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
Signature · 4 lines
"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 SeedQuoted 12 lines · Adrian Bunk
Quoted 7 lines · Dan Dennedy
Quoted 1 line · Adrian Bunk
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.
Quoted 6 lines
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
Quoted 16 lines · Lee Revell
Quoted 15 lines · Adrian Bunk
Quoted 7 lines · Dan Dennedy
Quoted 1 line · Adrian Bunk
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 26 lines · Dan Dennedy
Quoted 16 lines · Lee Revell
Quoted 15 lines · Adrian Bunk
Quoted 7 lines · Dan Dennedy
Quoted 1 line · Adrian Bunk
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.
Quoted 8 lines
Quoted 3 lines
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"?
Quoted 9 lines
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.
Quoted 8 lines
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
Signature · 4 lines
"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 SeedQuoted 17 lines · Adrian Bunk
Quoted 6 lines · Dan Dennedy
Quoted 4 lines · Lee Revell
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"?
Quoted 9 lines
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.
Quoted 4 lines
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
Quoted 18 lines · Lee Revell
Quoted 17 lines · Adrian Bunk
Quoted 15 lines · Dan Dennedy
Quoted 4 lines · Lee Revell
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 1 line
Lee
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 24 lines · Adrian Bunk
Quoted 23 lines · Lee Revell
Quoted 21 lines · Adrian Bunk
Quoted 6 lines · Dan Dennedy
Quoted 4 lines · Lee Revell
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"?
Quoted 9 lines
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.
Quoted 5 lines
Quoted 1 line
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_SYMBOLor 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
Quoted 4 lines · Adrian Bunk
Quoted 1 line
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_SYMBOLor 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
Quoted 7 lines · Lee Revell
Quoted 4 lines · Adrian Bunk
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
Quoted 11 lines · Greg KH
Quoted 7 lines · Lee Revell
Quoted 4 lines · Adrian Bunk
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
Quoted 8 lines · Lee Revell
Quoted 7 lines · Greg KH
Quoted 6 lines · Lee Revell
Quoted 4 lines · Adrian Bunk
The solution is simple:
The vendor or services provider submits his driver for inclusion into the kernel which is the best solution for everyone.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 8 lines · Lee Revell
Quoted 7 lines · Greg KH
Quoted 6 lines · Lee Revell
Quoted 4 lines · Adrian Bunk
The solution is simple:
The vendor or services provider submits his driver for inclusion into the kernel which is the best solution for everyone.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 5 lines · Theodore Ts'o
Quoted 3 lines
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_EXPERIMENTALis 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
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
Quoted 6 lines · Adrian Bunk
The patch below removes 41 unneeded EXPORT_SYMBOL's.
diffstat output:
drivers/ieee1394/ieee1394_core.c | 41 ------------------------------- 1 files changed, 41 deletions(-)
Quoted 4 lines · Arne Caspari
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 ?
Reply to the mail from Arjan van de Ven ([email protected]):
Quoted 8 lines · Arne Caspari
Quoted 4 lines
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
Quoted 3 lines · Arne Caspari
Quoted 1 line
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
Quoted 5 lines · Arne Caspari
Reply to the mail from Arjan van de Ven ([email protected]):
Quoted 3 lines · Arne Caspari
Quoted 2 lines
Adrian,
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 2 lines
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....
Quoted 5 lines · Arjan van de Ven
Quoted 2 lines · Arne Caspari
Quoted 1 line
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.
Signature · 3 lines
Stefan Richter -=====-=-=-- ==-- =-==- http://arcgraph.de/sr/
Quoted 9 lines · Stefan Richter
Quoted 5 lines · Arjan van de Ven
Quoted 2 lines · Arne Caspari
Quoted 1 line
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..
Quoted 2 lines · Christoph Hellwig
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
Quoted 4 lines · Christoph Hellwig
Quoted 2 lines · Stefan Richter
...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.
Quoted 1 line
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.
Signature · 3 lines
Stefan Richter -=====-=-=-- ==-- =-==- http://arcgraph.de/sr/
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.
Signature · 4 lines
Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Quoted 4 lines · 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.
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
Quoted 10 lines · Alan Cox
Quoted 4 lines · 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.
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.
Signature · 4 lines
Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ WatchGuard - http://www.watchguard.com/
Quoted 6 lines · Ben Collins
Quoted 4 lines
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.
Quoted 5 lines
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
Quoted 7 lines · Alan Cox
Quoted 5 lines · Ben Collins
Quoted 4 lines
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
Quoted 6 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 5 lines · Arne Caspari
...
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...
Quoted 1 line
/Arne
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 12 lines · Adrian Bunk
Quoted 4 lines · Arne Caspari
...
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
Quoted 4 lines · Arne Caspari
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.
Quoted 2 lines
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
Quoted 14 lines · Greg KH
Quoted 5 lines · Arne Caspari
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.txtfor details as to why this is so.
There is no such file in the 2.6.9 release :-(
/Arne
Quoted 10 lines · Arne Caspari
Quoted 7 lines · Greg KH
Quoted 3 lines · Arne Caspari
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.txtfor 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
Quoted 1 line · Arne Caspari
Adrian,
Hi Arne,
Quoted 13 lines
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.
Quoted 6 lines
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?
Quoted 5 lines
Thanks and best regards,
Arne Caspari
The Imaging Source Europe GmbH
cu
Adrian
Signature · 4 lines
"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 SeedQuoted 13 lines · Adrian Bunk
Quoted 6 lines
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.
Quoted 6 lines
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 ).
Quoted 6 lines
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_readandhpsb_writeare theEXPORT_SYMBOLSaffecting 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
Quoted 10 lines
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
Quoted 12 lines
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
Quoted 7 lines · girish wadhwani
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
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.
Quoted 20 lines · girish wadhwani
Quoted 8 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
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
Quoted 26 lines
Quoted 14 lines
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 [email protected]
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
Quoted 3 lines · Pieter Palmers
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
updated: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
In reply to Adrian BunkQuoted 5 lines · Adrian Bunk
...
After grepping through your CVS sources, it seemshpsb_readandhpsb_writeare theEXPORT_SYMBOLSaffecting 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(-)
drivers/ieee1394/ieee1394_core.c renamed from drivers/ieee1394/ieee1394_core.c.old +0 -39
@@ -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: updated: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
Quoted 6 lines · Adrian Bunk
Quoted 4 lines · Adrian Bunk
...
After grepping through your CVS sources, it seemshpsb_readandhpsb_writeare theEXPORT_SYMBOLSaffecting 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 beEXPORT_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: updated: [2.6 patch] ieee1394_core.c: remove unneeded EXPORT_SYMBOL's
Quoted 9 lines · Arne Caspari
Quoted 7 lines · Adrian Bunk
Quoted 5 lines · Adrian Bunk
...
After grepping through your CVS sources, it seemshpsb_readandhpsb_writeare theEXPORT_SYMBOLSaffecting you?
So keeping them should address your concerns?
...
Quoted 3 lines
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