asihpi - how much further?

asihpi - how much further?

[Eliot Blennerhassett]

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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: asihpi - how much further?

[Takashi Iwai]

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

Re: asihpi - how much further?

[Eliot Blennerhassett]

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

-- 
--
Eliot Blennerhassett
www.audioscience.com

Re: asihpi - how much further?

[Lee Revell]

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

Re: asihpi - hwdep

[Eliot Blennerhassett]

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

-- 
--
Eliot Blennerhassett
www.audioscience.com

Re: asihpi - hwdep

[Takashi Iwai]

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