On Tue, 2011-11-08 at 20:16 +0200, Tanu Kaskinen wrote: > On Tue, 2011-11-08 at 14:21 +0100, David Henningsson wrote: > > On 11/08/2011 11:30 AM, Arun Raghavan wrote: > > > On Thu, 2011-11-03 at 21:04 +0200, Tanu Kaskinen wrote: > > >> Somehow keeping a list of profiles in the ports doesn't feel right - > > >> it's as if that list would have been thrown there just to make things > > >> convenient for some random code... But I guess there's a reason, which > > >> just isn't apparent from this patch yet, for having that list there. > > > > > > This is my largest concern as well. > > > > There is nothing wrong with every port knowing what profiles that port > > is a part of; it follows naturally with having port belonging to cards. > > I think I agree after all. I tried to come up with a better > counterargument than "it doesn't feel right", but I failed. Here's my reasoning -- if you look at this from a pure ALSA perspective, profiles are a list of PCMs and associated mixer paths. Put this way, the jack -> profile pointer could makes sense. More generically, though, profiles represent some set of mutually exclusive input/output paths. Defining them this way, there isn't really a relation between the ports and profiles, only between the ports and the input/output paths that the profiles represent. (which is why I believe my alternative makes sense) Looking at it merely as the code stands today, the first interpretation makes sense -- we only really support ports on ALSA devices. But that's only the short-term view, and IMO it makes more sense to take the long-term view when defining your classes and their relations. -- Arun
