[alsa-devel] asihpi - how much further?
Hi Takashi,
My boss has started asking how long is it going to take to get our driver into mainline. I.e. a list of things we need to do, that when all those items have been dealt with, then the driver is accepted. Is it possible to make such a list?
thanks and regards
Eliot Blennerhassett www.audioscience.com
P.S. Heres a quote that I feel has some relevance:
http://linux-foundation.org/weblogs/openvoices/linus-torvalds-part-ii/
Jim Zemlin: But in a sense, over time, you win because you set the bar high and you encourage people to get it into the main line.
Linus Torvalds: One of the problems is we have people who have so high criteria for what is acceptable or not that it scares away people who want to do new code and do new experiments.
We mustn’t set the bar that high. New code, new drivers, there will be problems and I’d rather take them and then improve them than expect driver authors, especially when they stand outside the main tree and feel kind of like outsiders even though maybe they really are part of the same whole development community, but they feel like outsiders because their driver hasn’t made it into the tree yet.
And then asking them to jump through hoops and make their driver perfect when they’re standing there alone and don’t have help; I think that’s unfair. And there are people in the kernel community that feel that way that things have to be just right before you can accept them and I’m much more of a laissez-faire kind of person. We don’t want to accept bad things, but on the other hand, hey, everything starts from less-than-perfect roots and it’s much better to accept things that work but may not be perfect and then improve on them when we can all improve on them and all the different vendors can fix the small nagging issues they have instead of keeping them at arm’s length until they’re perfect because maybe they’ll never be perfect without help.
At Fri, 22 Feb 2008 12:26:59 +1300, Eliot Blennerhassett wrote:
Hi Takashi,
My boss has started asking how long is it going to take to get our driver into mainline. I.e. a list of things we need to do, that when all those items have been dealt with, then the driver is accepted. Is it possible to make such a list?
I think the all coding style issues have been already listed in out previous mails, even about pretty picky ones. What I personally still don't think good is the infrastructure of the driver - the separate mangament of asihpi and hpimod. This makes it hard to understand the code flow. But, if it's your inevitable requirement, we can keep this as is. So, try to clean up the code as much as you can do now, and then let's check and move to alsa-kernel tree.
My remaining concern is the further maintenance. If I understand correctly, you would like to maintain your driver code from the common code-base among difference OSes and convert to the linux native one via a script. This would be difficult to pick up the upstream changes. But, again, it's your choice. I'd just need to be careful about the further merge from you in order not to break the upstream changes...
thanks and regards
Eliot Blennerhassett www.audioscience.com
P.S. Heres a quote that I feel has some relevance:
Well, the merge is easy but the maintenance is not... :)
thanks,
Takashi
Thanks Takashi,
is that the light at the end of the tunnel, or a train coming towards me ;)
On Saturday 23 February 2008 06:14:30 Takashi Iwai wrote:
At Fri, 22 Feb 2008 12:26:59 +1300,
Eliot Blennerhassett wrote:
Hi Takashi,
My boss has started asking how long is it going to take to get our driver into mainline. I.e. a list of things we need to do, that when all those items have been dealt with, then the driver is accepted. Is it possible to make such a list?
I think the all coding style issues have been already listed in out previous mails, even about pretty picky ones.
OK. I shall carry on chipping at the rock...
What I personally still don't think good is the infrastructure of the driver - the separate mangament of asihpi and hpimod. This makes it hard to understand the code flow. But, if it's your inevitable requirement, we can keep this as is.
The 'inevitable' requirement is that HPI ioctl remains. (at least as an option, perhaps disabled by default, enabled by module option).
I'm open to merging all or part hpimod code into (alsa) asihpi.c, and restructuring so that the asihpi.c code is 'master'.
You also mentioned handling the ioctl via alsa hwdep. I'm interested in hearing more about this. Can it be made so that applications using HPI_IOCTL and using /dev/asihpi still work? I just don't know enough about how to start on hwdep implementation.
So, try to clean up the code as much as you can do now, and then let's check and move to alsa-kernel tree.
OK. As you saw, I'm working on replacing the volatile with memory barriers, which is the remaining major style issue that checkpatch complains about. (There are some other complaints about macros without parentheses, but I think these are spurious)
My remaining concern is the further maintenance. If I understand correctly, you would like to maintain your driver code from the common code-base among difference OSes and convert to the linux native one via a script.
This is how the patches I send to you are currently generated: I put our generated files into Hg sandbox, then Hg diff. At this point I backport changes in Hg that came from outside. (E.g. the various changes that Clemens has made - thanks) Then regenerate the files, make a patch.
I live in hope that the patches will get smaller over time ;)
This would be difficult to pick up the upstream changes. But, again, it's your choice. I'd just need to be careful about the further merge from you in order not to break the upstream changes...
The alternative (completely separate codebases) means that "mythical somebody" has to track AudioScience source releases, figure out how translate changes into ALSA codebase, and do it.
P.S. Heres a quote that I feel has some relevance:
Well, the merge is easy but the maintenance is not... :)
I guess we just differ on whether any other way of doing things will make the maintenance any easier...
regards
On Fri, Feb 22, 2008 at 4:10 PM, Eliot Blennerhassett linux@audioscience.com wrote:
You also mentioned handling the ioctl via alsa hwdep. I'm interested in hearing more about this. Can it be made so that applications using HPI_IOCTL and using /dev/asihpi still work? I just don't know enough about how to start on hwdep implementation.
Please take a look at snd_emu10k1_fx8010_ioctl in alsa-kernel/pci/emu10k1/emufx.c for examples of hwdep ioctl usage.
Lee
Thanks Lee,
On Saturday 23 February 2008 13:52:13 Lee Revell wrote:
On Fri, Feb 22, 2008 at 4:10 PM, Eliot Blennerhassett
linux@audioscience.com wrote: I just don't know enough
about how to start on hwdep implementation.
Please take a look at snd_emu10k1_fx8010_ioctl in alsa-kernel/pci/emu10k1/emufx.c for examples of hwdep ioctl usage.
that wasn't too hard. I have implemented stubs just to see how it fits together.
It doesn't do quite what I want. The existing HPI ioctl has one device file for the driver, whether one or sixteen cards are installed, and its name doesn't change depending on the card index. (I.e. userspace accesses the whole (HPI) audio subsystem through the one /dev/asihpi)
ALSA makes one device file per card, and the file name depends on the card index. Is there any way I can make a single device for the driver that has an unchanging name (preferably /dev/asihpi)
regards
At Sat, 23 Feb 2008 20:41:48 +1300, Eliot Blennerhassett wrote:
Thanks Lee,
On Saturday 23 February 2008 13:52:13 Lee Revell wrote:
On Fri, Feb 22, 2008 at 4:10 PM, Eliot Blennerhassett
linux@audioscience.com wrote: I just don't know enough
about how to start on hwdep implementation.
Please take a look at snd_emu10k1_fx8010_ioctl in alsa-kernel/pci/emu10k1/emufx.c for examples of hwdep ioctl usage.
that wasn't too hard. I have implemented stubs just to see how it fits together.
It doesn't do quite what I want. The existing HPI ioctl has one device file for the driver, whether one or sixteen cards are installed, and its name doesn't change depending on the card index. (I.e. userspace accesses the whole (HPI) audio subsystem through the one /dev/asihpi)
ALSA makes one device file per card, and the file name depends on the card index. Is there any way I can make a single device for the driver that has an unchanging name (preferably /dev/asihpi)
Unfortuantely, the hwdep doesn't work for such a purpose. It's strictly bound to a specific card instance.
As HPI is a global control, this looks like an exceptional case. Normally, the driver data is bound to the device as 1:1.
Maybe, the basic question now is which is the primary driver instance, asihpi or hpimod. I feel asihpi could be better as the primary driver (like other drivers), and we can add HPI interface as a kind of hook. Well, this is an internal implementation detail after all, and can be changed gradually.
Takashi
participants (3)
-
Eliot Blennerhassett -
Lee Revell -
Takashi Iwai