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

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

[Ali Nasrolahi]

Hi everyone,

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?

2. Has this limit been discussed previously, or is there any relevant
   discussion that I may have missed?

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.

Cheers,
-Ali

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

[Mauro Carvalho Chehab]

On Sun, 2 Aug 2026 08:24:29 +0330
Ali Nasrolahi <a.nasrolahi01@gmail.com> wrote:

> Hi everyone,
> 
> 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?

Thanks,
Mauro