All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Koegler <martin.koegler@chello.at>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Martin Koegler <martin.koegler@chello.at>
Subject: Re: [PATCH] Provide card number / PID via sequencer client	info
Date: Mon, 15 Feb 2016 19:32:43 +0100	[thread overview]
Message-ID: <20160215183243.GA26482@mail.zuhause> (raw)
In-Reply-To: <s5htwlab70o.wl-tiwai@suse.de>

On Mon, Feb 15, 2016 at 11:30:15AM +0100, Takashi Iwai wrote:
> The idea looks good.  One remaining question is whether only providing
> the card number or pid is sufficient for all cases.

I only care about the kernel client. 
 
> > @@ -357,7 +357,8 @@ struct snd_seq_client_info {
> >  	unsigned char event_filter[32];	/* event filter bitmap */
> >  	int num_ports;			/* RO: number of ports */
> >  	int event_lost;			/* number of lost events */
> > -	char reserved[64];		/* for future use */
> > +	int owner;			/* RO: card number[kernel] / PID[user] */
> > +	char reserved[64 - sizeof(int)]; /* for future use */
> 
> The sizeof(int) is always 4.  So let's make it explicit.
> 
> But, please make sure that this change won't lead to any
> incompatibility.  Some architectures might align with 64bit long,
> although the 32bit int and the rest char[] should be fine on all known
> architectures, AFAIK.

Sorry, I don't have access to the various non x86-architectures, so I can't test.

I will change to 
int card; 
int pid; 
char reserve[56];

More safety would just provide a much more complex (ugly?) structure:

struct _int_snd_seq_client_info_old {
        int client;                     /* client number to inquire */
        snd_seq_client_type_t type;     /* client type */
        char name[64];                  /* client name */
        unsigned int filter;            /* filter flags */
        unsigned char multicast_filter[8]; /* multicast filter bitmap */
        unsigned char event_filter[32]; /* event filter bitmap */
        int num_ports;                  /* RO: number of ports */
        int event_lost;                 /* number of lost events */
        char reserved[64]; /* for future use */
};

struct _int_snd_seq_client_info_new {
        int client;                     /* client number to inquire */
        snd_seq_client_type_t type;     /* client type */
        char name[64];                  /* client name */
        unsigned int filter;            /* filter flags */
        unsigned char multicast_filter[8]; /* multicast filter bitmap */
        unsigned char event_filter[32]; /* event filter bitmap */
        int num_ports;                  /* RO: number of ports */
        int event_lost;                 /* number of lost events */
        int card;
        int pid;
        char reserved[64]; /* for future use */
};

struct snd_seq_client_info {
        int client;                     /* client number to inquire */
        snd_seq_client_type_t type;     /* client type */
        char name[64];                  /* client name */
        unsigned int filter;            /* filter flags */
        unsigned char multicast_filter[8]; /* multicast filter bitmap */
        unsigned char event_filter[32]; /* event filter bitmap */
        int num_ports;                  /* RO: number of ports */
        int event_lost;                 /* number of lost events */
        int card;
        int pid;
        char reserved[64 - sizeof(struct _int_snd_seq_client_info_new) + sizeof(_int_snd_seq_client_info_old)]; /* for future use */
};

This should handle all alignment and type size issues automatically.

If you really want this, I can provide the apropriate patches.

> >  
> > diff --git a/sound/core/seq/seq_clientmgr.c b/sound/core/seq/seq_clientmgr.c
> > index 58e79e0..ac07ab7 100644
> > --- a/sound/core/seq/seq_clientmgr.c
> > +++ b/sound/core/seq/seq_clientmgr.c
> > @@ -364,6 +364,7 @@ static int snd_seq_open(struct inode *inode, struct file *file)
> >  	/* fill client data */
> >  	user->file = file;
> >  	sprintf(client->name, "Client-%d", c);
> > +	client->data.user.owner = get_pid(task_pid(current));
> >  
> >  	/* make others aware this new client */
> >  	snd_seq_system_client_ev_client_start(c);
> > @@ -380,6 +381,7 @@ static int snd_seq_release(struct inode *inode, struct file *file)
> >  		seq_free_client(client);
> >  		if (client->data.user.fifo)
> >  			snd_seq_fifo_delete(&client->data.user.fifo);
> > +		put_pid(client->data.user.owner);
> >  		kfree(client);
> >  	}
> 
> Shouldn't the counterpart (put_pid()) be called anywhere else?

The only way to free a client structure is seq_free_client1 (static).
This is called by snd_seq_open before get_pid [=> irelevant] and 
seq_free_client (static).
seq_free_client is called by snd_seq_release, which calls put_pid and
snd_seq_delete_kernel_client, which destroys a kernel client.

Are I'm missing a code path?

Regards,
Martin

  parent reply	other threads:[~2016-02-15 18:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-13 13:42 [PATCH] Provide sequencer sound card number / PID via alsa-lib Martin Koegler
2016-02-13 13:42 ` [PATCH] Show sequencer sound card numer/PID via aconnect Martin Koegler
2016-02-13 13:42 ` [PATCH] Provide card number / PID via sequencer client info Martin Koegler
2016-02-15 10:30   ` Takashi Iwai
2016-02-15 10:37     ` Clemens Ladisch
2016-02-15 18:32     ` Martin Koegler [this message]
2016-02-15 19:08       ` Takashi Iwai
2016-02-15 21:44         ` Martin Koegler
2016-02-15 22:34           ` Takashi Iwai
2016-02-16  8:03             ` Martin Koegler
2016-02-16  8:41               ` Takashi Iwai
2016-02-16  8:59                 ` Clemens Ladisch
2016-02-16  9:27                   ` Takashi Iwai
2016-02-16 18:21                     ` Martin Koegler
2016-02-17 14:07                       ` Takashi Iwai
2016-02-17 21:30                         ` Martin Koegler
2016-02-15 10:39 ` [PATCH] Provide sequencer sound card number / PID via alsa-lib Clemens Ladisch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160215183243.GA26482@mail.zuhause \
    --to=martin.koegler@chello.at \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.