[alsa-devel] question on snd minors
Hi,
for the compressed path work I had a question regarding the minor numbers.
Looks like we have 32 minors (5 bits) and going by current table there is no space for new devices. So should i increase the number to 64 (6bits), add compressed playback and capture devices as 32-39, 40-48 respectively and keep rest as reserved, or would you like it to be kept 32 and realign the table?
At Tue, 15 Nov 2011 09:39:23 +0530, Vinod Koul wrote:
Hi,
for the compressed path work I had a question regarding the minor numbers.
Looks like we have 32 minors (5 bits) and going by current table there is no space for new devices. So should i increase the number to 64 (6bits), add compressed playback and capture devices as 32-39, 40-48 respectively and keep rest as reserved, or would you like it to be kept 32 and realign the table?
For the large number of concurrent accesses, we usually take an approach with sub-streams instead of scattering too many device files.
Takashi
On Tue, 2011-11-15 at 07:39 +0100, Takashi Iwai wrote:
At Tue, 15 Nov 2011 09:39:23 +0530, Vinod Koul wrote:
Hi,
for the compressed path work I had a question regarding the minor numbers.
Looks like we have 32 minors (5 bits) and going by current table there is no space for new devices. So should i increase the number to 64 (6bits), add compressed playback and capture devices as 32-39, 40-48 respectively and keep rest as reserved, or would you like it to be kept 32 and realign the table?
For the large number of concurrent accesses, we usually take an approach with sub-streams instead of scattering too many device files.
Perhaps I should have worded my question better :)
For compressed path (i had posted RFC roughly two months back [1]), we are creating new devices /dev/snd/comprCxDxp which would be registered as SNDRV_DEV_COMPRESS. For the registration part we need to assign the minors, right? Hence the above question
Or did I miss something very obvious here...
This is how I wrote it now, I wanted to run this with you folks first
diff --git a/include/sound/core.h b/include/sound/core.h index 1fa2407..9d1e54b 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -62,6 +62,7 @@ typedef int __bitwise snd_device_type_t; #define SNDRV_DEV_BUS ((__force snd_device_type_t) 0x1007) #define SNDRV_DEV_CODEC ((__force snd_device_type_t) 0x1008) #define SNDRV_DEV_JACK ((__force snd_device_type_t) 0x1009) +#define SNDRV_DEV_COMPRESS ((__force snd_device_type_t) 0x100A) #define SNDRV_DEV_LOWLEVEL ((__force snd_device_type_t) 0x2000)
typedef int __bitwise snd_device_state_t; diff --git a/include/sound/minors.h b/include/sound/minors.h index 8f76420..ffa6001 100644 --- a/include/sound/minors.h +++ b/include/sound/minors.h @@ -23,10 +23,10 @@
#define SNDRV_OS_MINORS 256
-#define SNDRV_MINOR_DEVICES 32 -#define SNDRV_MINOR_CARD(minor) ((minor) >> 5) -#define SNDRV_MINOR_DEVICE(minor) ((minor) & 0x001f) -#define SNDRV_MINOR(card, dev) (((card) << 5) | (dev)) +#define SNDRV_MINOR_DEVICES 64 +#define SNDRV_MINOR_CARD(minor) ((minor) >> 6) +#define SNDRV_MINOR_DEVICE(minor) ((minor) & 0x003f) +#define SNDRV_MINOR(card, dev) (((card) << 6) | (dev))
/* these minors can still be used for autoloading devices (/dev/aload*) */ #define SNDRV_MINOR_CONTROL 0 /* 0 */ @@ -40,6 +40,8 @@ #define SNDRV_MINOR_RAWMIDI 8 /* 8 - 15 */ #define SNDRV_MINOR_PCM_PLAYBACK 16 /* 16 - 23 */ #define SNDRV_MINOR_PCM_CAPTURE 24 /* 24 - 31 */ +#define SNDRV_MINOR_COMPR_PLAYBACK 32 /* 32 - 35 */ +#define SNDRV_MINOR_COMPR_CAPTURE 36 /* 36 - 39 */
At Tue, 15 Nov 2011 13:15:39 +0530, Vinod Koul wrote:
On Tue, 2011-11-15 at 07:39 +0100, Takashi Iwai wrote:
At Tue, 15 Nov 2011 09:39:23 +0530, Vinod Koul wrote:
Hi,
for the compressed path work I had a question regarding the minor numbers.
Looks like we have 32 minors (5 bits) and going by current table there is no space for new devices. So should i increase the number to 64 (6bits), add compressed playback and capture devices as 32-39, 40-48 respectively and keep rest as reserved, or would you like it to be kept 32 and realign the table?
For the large number of concurrent accesses, we usually take an approach with sub-streams instead of scattering too many device files.
Perhaps I should have worded my question better :)
For compressed path (i had posted RFC roughly two months back [1]), we are creating new devices /dev/snd/comprCxDxp which would be registered as SNDRV_DEV_COMPRESS. For the registration part we need to assign the minors, right? Hence the above question
Or did I miss something very obvious here...
Yes, take a look at PCM devices, for example. They have sub-streams. So, you can open a single device file multiple times to assign multiple sub-streams. If any specific substream with a given index is needed, it can be specified via ioctl before open. Otherwise, the next empty substream is assigned.
The similar implementation is found in rawmidi, too.
Takashi
This is how I wrote it now, I wanted to run this with you folks first
diff --git a/include/sound/core.h b/include/sound/core.h index 1fa2407..9d1e54b 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -62,6 +62,7 @@ typedef int __bitwise snd_device_type_t; #define SNDRV_DEV_BUS ((__force snd_device_type_t) 0x1007) #define SNDRV_DEV_CODEC ((__force snd_device_type_t) 0x1008) #define SNDRV_DEV_JACK ((__force snd_device_type_t) 0x1009) +#define SNDRV_DEV_COMPRESS ((__force snd_device_type_t) 0x100A) #define SNDRV_DEV_LOWLEVEL ((__force snd_device_type_t) 0x2000)
typedef int __bitwise snd_device_state_t; diff --git a/include/sound/minors.h b/include/sound/minors.h index 8f76420..ffa6001 100644 --- a/include/sound/minors.h +++ b/include/sound/minors.h @@ -23,10 +23,10 @@
#define SNDRV_OS_MINORS 256
-#define SNDRV_MINOR_DEVICES 32 -#define SNDRV_MINOR_CARD(minor) ((minor) >> 5) -#define SNDRV_MINOR_DEVICE(minor) ((minor) & 0x001f) -#define SNDRV_MINOR(card, dev) (((card) << 5) | (dev)) +#define SNDRV_MINOR_DEVICES 64 +#define SNDRV_MINOR_CARD(minor) ((minor) >> 6) +#define SNDRV_MINOR_DEVICE(minor) ((minor) & 0x003f) +#define SNDRV_MINOR(card, dev) (((card) << 6) | (dev))
/* these minors can still be used for autoloading devices (/dev/aload*) */ #define SNDRV_MINOR_CONTROL 0 /* 0 */ @@ -40,6 +40,8 @@ #define SNDRV_MINOR_RAWMIDI 8 /* 8 - 15 */ #define SNDRV_MINOR_PCM_PLAYBACK 16 /* 16 - 23 */ #define SNDRV_MINOR_PCM_CAPTURE 24 /* 24 - 31 */ +#define SNDRV_MINOR_COMPR_PLAYBACK 32 /* 32 - 35 */ +#define SNDRV_MINOR_COMPR_CAPTURE 36 /* 36 - 39 */
-- ~Vinod
1: http://mailman.alsa-project.org/pipermail/alsa-devel/2011-September/043408.h...
On Tue, 2011-11-15 at 09:11 +0100, Takashi Iwai wrote:
For compressed path (i had posted RFC roughly two months back [1]),
we
are creating new devices /dev/snd/comprCxDxp which would be
registered
as SNDRV_DEV_COMPRESS. For the registration part we need to assign
the
minors, right? Hence the above question
Or did I miss something very obvious here...
Yes, take a look at PCM devices, for example. They have sub-streams. So, you can open a single device file multiple times to assign multiple sub-streams. If any specific substream with a given index is needed, it can be specified via ioctl before open. Otherwise, the next empty substream is assigned.
The similar implementation is found in rawmidi, too.
Okay Thanks a bunch, I wanted to avoid these kind of mistakes :)
right now we don't have PCM devices or substreams notion. The DSP driver registers the compressed_ops (not pcm) with framework and we create the device nodes. framework would call them based on state and file_ops called.
From what I read in rawmidi and your suggestion about PCM devices, I
think you are suggesting to use a single file ops only (this a single minor number (or two, including capture) would suffice instead of a range, right? Any suggestion of which number to use? (well i followed the usually convention of PCM for minor numbers, although I cannot envision a device with multiple/large DSPs for audio offload)
At Tue, 15 Nov 2011 14:55:33 +0530, Vinod Koul wrote:
On Tue, 2011-11-15 at 09:11 +0100, Takashi Iwai wrote:
For compressed path (i had posted RFC roughly two months back [1]),
we
are creating new devices /dev/snd/comprCxDxp which would be
registered
as SNDRV_DEV_COMPRESS. For the registration part we need to assign
the
minors, right? Hence the above question
Or did I miss something very obvious here...
Yes, take a look at PCM devices, for example. They have sub-streams. So, you can open a single device file multiple times to assign multiple sub-streams. If any specific substream with a given index is needed, it can be specified via ioctl before open. Otherwise, the next empty substream is assigned.
The similar implementation is found in rawmidi, too.
Okay Thanks a bunch, I wanted to avoid these kind of mistakes :)
right now we don't have PCM devices or substreams notion. The DSP driver registers the compressed_ops (not pcm) with framework and we create the device nodes. framework would call them based on state and file_ops called.
From what I read in rawmidi and your suggestion about PCM devices, I
think you are suggesting to use a single file ops only (this a single minor number (or two, including capture) would suffice instead of a range, right? Any suggestion of which number to use? (well i followed the usually convention of PCM for minor numbers, although I cannot envision a device with multiple/large DSPs for audio offload)
OK, if there aren't so many devices, we may still reserved slots (minor 2 and 3). These can be assigned for the new type. Will be there two completely different DSPs? If it's unlikely, just grab one minor as the start, I'd say. You can still implement the substreams in a single device.
Note that the above story is only for the case without CONFIG_SND_DYNAMIC_MIONRS. If you use CONFIG_SND_DYNAMIC_MINORS (this is usually set for all modern distros), there is no restriction but the total number of minors since the minor numbers are assigned dynamically. So you can forget all in the above.
Takashi
On Tue, 2011-11-15 at 11:12 +0100, Takashi Iwai wrote:
OK, if there aren't so many devices, we may still reserved slots (minor 2 and 3). These can be assigned for the new type. Will be there two completely different DSPs? If it's unlikely, just grab one minor as the start, I'd say. You can still implement the substreams in a single device.
Note that the above story is only for the case without CONFIG_SND_DYNAMIC_MIONRS. If you use CONFIG_SND_DYNAMIC_MINORS (this is usually set for all modern distros), there is no restriction but the total number of minors since the minor numbers are assigned dynamically. So you can forget all in the above.
Okay thanks. I won't try to guess which options the OSes would try to use, so taking safer approach and ensure they work for both. Any case if someone doesn't like the restriction they can use SND_DYNAMIC_MINORS :)
At Tue, 15 Nov 2011 16:21:08 +0530, Vinod Koul wrote:
On Tue, 2011-11-15 at 11:12 +0100, Takashi Iwai wrote:
OK, if there aren't so many devices, we may still reserved slots (minor 2 and 3). These can be assigned for the new type. Will be there two completely different DSPs? If it's unlikely, just grab one minor as the start, I'd say. You can still implement the substreams in a single device.
Note that the above story is only for the case without CONFIG_SND_DYNAMIC_MIONRS. If you use CONFIG_SND_DYNAMIC_MINORS (this is usually set for all modern distros), there is no restriction but the total number of minors since the minor numbers are assigned dynamically. So you can forget all in the above.
Okay thanks. I won't try to guess which options the OSes would try to use, so taking safer approach and ensure they work for both. Any case if someone doesn't like the restriction they can use SND_DYNAMIC_MINORS :)
Yeah, but in that case, the driver will have the limitation of free minors anyway. Changing the static minor number assignment (e.g. change MINORS to 64) isn't allowed at all. If any, we'd need to extend the minors up from 256 instead of changing the existing ones.
Takashi
participants (2)
-
Takashi Iwai -
Vinod Koul