Re: [RFC] Discussion: VIDEO_NUM_DEVICES limit in v4l2-dev.c

On 26/08/03 09:04AM, Hans Verkuil wrote:
> On 02/08/2026 20:25, Ali Nasrolahi wrote:
> > On 26/08/02 12:57PM, Mauro Carvalho Chehab wrote:
> >> On Sun, 2 Aug 2026 08:24:29 +0330
> >> Ali Nasrolahi <[email protected]> wrote:
> >>> I'm working on a project involving high density video processing on a
> >>> single server using a large number of v4l2 loopback devices to route
> >>> virtual video streams to tenants.
> >>>
> >>> While doing so, I ran into the hard limit imposed by `VIDEO_NUM_DEVICES`
> >>> (currently 256) in `drivers/media/v4l2-core/v4l2-dev.c`. Looking through
> >>> the code and git history, this limit has been there for quite a long time.
> >>> However, after searching the mailing list archives, I couldn't find any
> >>> previous discussion regarding this limitation.
> >>>
> >>> May I ask:
> >>>
> >>> 1. Is there any internal design constraint that requires limiting the
> >>>    number of V4L2 devices to 256 on modern kernels?
> >>
> >> There was a constraint at the very beginning due to the way minors
> >> were generated. If I'm not mistaken, this was long gone.
> >>
> >> Still, having a maximum limit is desirable as there is a hard limit
> >> in terms of the memory.
> >>
> >>> 2. Has this limit been discussed previously, or is there any relevant
> >>>    discussion that I may have missed?
> >>
> >> Probably, but likely very years ago. I can't recall last time we
> >> discussed this particular limit.
> >>
> >>> If the current limit is no longer intentional and there's no historical
> >>> context that I might've missed, I'd be happy to work on a patch series to
> >>> address it, and I would appreciate any guidance on the preferred direction.
> >>
> >> What is the maximum limit your hardware has? Can you provide some
> >> documentation related to it?
> > 
> > Assuming I understood your question correctly, because the workloads run
> > on a server, theoretically, there is no fixed limit on the number of
> > virtual video devices that could be used. As long as there is enough cpu
> > power, memory, and i/o bandwidth available, it is beneficial to be able
> > to add devices and, consequently, run more workloads.
> > 
> > That being said, to give some rough numbers, I think supporting at least
> > 1000 to 2000 devices would likely cover most practical cases.
> > 
> > This is why I was wondering whether making this limit dynamically
> > allocated or at least configurable might be beneficial, so, for example,
> > mahcines with limited memory would not have to reserve an unnecessarily
> > large array, while systems with more resources could scale accordingly.
> 
> It shouldn't be too hard to add a module option to set the max number of
> devices. Minimum and default value would be 256, max 4096 (it can go higher: the
> minor number has 20 bits, but I'd cap it to 4096 for now).
>
> This module option is only available if CONFIG_VIDEO_FIXED_MINOR_RANGES is
> not set, as that would cause problems (and perhaps it is time to retire
> CONFIG_VIDEO_FIXED_MINOR_RANGES).

That makes sense.
If that's okay with you, I'd be happy to work on this change and send a
corresponding patch series. Before that though, I'd just like to make
sure my understanding of the implementation is aligned with what you
have in mind.

That is:

- Add a new module parameter (e.g. `max_nr_devices`) with a default of
    256, and within the range of 256 to 4096.

- Convert the static allocations that currently depend on
    `VIDEO_NUM_DEVICES` so they honor the `max_nr_devices` parameter.
    This would apply to `video_devices`, the associated bitmaps,
    character device region registration, etc.

- Make this parameter available only when VIDEO_FIXED_MINOR_RANGES is
    disabled. Otherwise, the current limit of 256 devices should remain
    unchanged.

This is my understanding based on your comments. Please let me know if I
have misunderstood anything or if there are any implementation-specific
considerations that should be kept in mind while working on this.

> You're the first in my 20+ years of V4L experience who needed more than 256
> devices, so this is not a common request :-)

Well, v4l2 devices are so well-tested and well-supported by userspace
applications such as ffmpeg, gstreamer, and many others that they become
a natural choice for many video processing workloads :)

Thanks,
-Ali