Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <69801f61-37b0-3e46-cbef-31ff80ae9a34@amd.com>
Date:   Thu, 27 Jul 2023 14:01:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [PATCH v6 3/4] drm: Expand max DRM device number to full
 MINORBITS
Content-Language: en-US
To:     Simon Ser <contact@emersion.fr>,
        =?UTF-8?Q?Micha=c5=82_Winiarski?= <michal.winiarski@intel.com>
Cc:     dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
        intel-gfx@lists.freedesktop.org, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Matthew Wilcox <willy@infradead.org>,
        Oded Gabbay <ogabbay@kernel.org>,
        James Zhu <James.Zhu@amd.com>,
        Pekka Paalanen <pekka.paalanen@collabora.com>,
        Emil Velikov <emil.l.velikov@gmail.com>
References: <20230724211428.3831636-1-michal.winiarski@intel.com>
 <20230724211428.3831636-4-michal.winiarski@intel.com>
 <83s0YPWEdYE6C2a8pa6UAa3EaWZ2zG-q7IL9M-y6W1ucF9V54VnZtigKj3BGKUA2FZpIrs0VVxmpHO2RAhs_FdOnss9vNLQNSHySY8uH7YA=@emersion.fr>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
In-Reply-To: <83s0YPWEdYE6C2a8pa6UAa3EaWZ2zG-q7IL9M-y6W1ucF9V54VnZtigKj3BGKUA2FZpIrs0VVxmpHO2RAhs_FdOnss9vNLQNSHySY8uH7YA=@emersion.fr>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SVFGdmIrSWExNUtCOVkyQ0R6YmlUcG1aV1RQZ2hZQWJDdkVXTnUvUW5xMzhu?=
 =?utf-8?B?clU0T24rc2hMSFcvNjcwQ1YzWTlxNGozVjN4OThKcVVZTVA3OHhFZFhYMVp4?=
 =?utf-8?B?NGdPcnRwRVZWR1M4Sk9zeEd6VStaUlZMekNEUW4ySUVwL3JPdG9lVCtCVUoz?=
 =?utf-8?B?aXNNT2U0K1BUSlUvaENjaXpockMySjY1bkNvUE5VTjNKU21wT25QZTZlL0tZ?=
 =?utf-8?B?S2N1Y1lSZ3ZxSC90ZHBYanY4MVlrYjROYmpSVm16ZFd3QnVKdGQ0UEx5T3ZW?=
 =?utf-8?B?RHFuN1FrbUZFMm5Qb1lCR3pKNzFseGY0MTFHdGltT2NxUDkxQW90Zm1GVC9V?=
 =?utf-8?B?S0JMdTd4emxKNmhWd2M2UlhLUVVzOFpIT0NNWFN4bXBURVU4SlNRNVdldVFv?=
 =?utf-8?B?VlVMcjNPdk1tUElMNlJxSHUvbDB3NjlCK2RvSm5PeHNSdkphTUJscTdORjVm?=
 =?utf-8?B?NUsyWFREQXh4VnhzRUViWU15YWNGTXpldWRZcGZLUnNPdythc2h0RGVFQTJC?=
 =?utf-8?B?WktRQXlQRFlEeXA2THNUbnBWb3Q4aXZIUCtmMGlJRTdUTmE2aEh2U3d3d0x4?=
 =?utf-8?B?Z21VMWpqeGx0Y2gxUHErNnE1c011ZVBVV3B1R1ZsYVd2SDNWOVBodGJZbEN4?=
 =?utf-8?B?Vm1ZWnplZk0vWHpwaENFMitPTEY1cEJjU01RZWFUSEdJc1lybEVLMklnaS81?=
 =?utf-8?B?cHg2SXZjeFBwR0JZTWpHZDlkZHlhYVgxSmtoRjQxb0NIODZZcUU0aXA1ckFa?=
 =?utf-8?B?VFh4QXhQMXg5Ty96SEhyMVpJNTc5eXlTSUYxa2Mwc3JLM3Q5VTZxbUxlWTA1?=
 =?utf-8?B?b2dZNmFkTldadjN2V29SMTRJQndib0ZKOFFuNWNVMUlpNVV0ay9FSHJxQWE3?=
 =?utf-8?B?V3E2cHY0K1MvWW9QQ05EaytiSWNUcElIM1BucnNwOGl4MnM4dlEzNlpscDh3?=
 =?utf-8?B?NWhEbExvWlB4OXRTL1ZTQy9aUkZMczBaRGoyOTJlL2grRTBhQi8wMEJraWNL?=
 =?utf-8?B?YS82RmtYdHhRRnZmRjRRSkhDK1B1UXB6SVhFS1R2QjI3c1hzMEFBUnpaNW5H?=
 =?utf-8?B?a0o1K05lZGxqZno4RktnNEdPQ0hzS3RJME1uK3V2d0VNYU8zMk5XNlBHMEF4?=
 =?utf-8?B?eWwxSFZJTVZkMDh2ZEllTy91RmIrbFF0UkJtYmh3eXF0VzVicmdvYmttclNr?=
 =?utf-8?B?cVZPcHUzb1ZRWmZtai9FMnlzU0tRRmN0QkI2SGRja2lMVi9aY2ZWMTlpZ2ln?=
 =?utf-8?B?czVDSm44NUtEbjhjcFl0T3NmOEpCbG9FZ3UrYzgvN0FHcjVaajZaVXRWcEJq?=
 =?utf-8?B?UEJ6bGlwYUd4SWNUcXRkZnp6Q29QemZPTU4zN3dvVVEzSUE5VkFYTk9sK0dh?=
 =?utf-8?B?TUxuSDdVZVVCZllJd3NHN3hJakV0RnRnZHJyRnIzVHk5R0ZtZm1OWHU2aVZN?=
 =?utf-8?B?WjZFcGJLd2VkRU9pdDJpWnptL3pEK0VQcHhxeXhBeDhLdHV3YUY4UUgzbFBC?=
 =?utf-8?B?bHEwVW8vNS9rN2VYR1lWemVOSTd0N3ljbE05bVBPTU4xNFFIY0pDWkFjUUZE?=
 =?utf-8?B?QzZSenkvbWZhWFVJNmlkTGlYelVGUVZBRVpRbm44ZVNmQnJqSFMwenQ2d0pJ?=
 =?utf-8?B?cG9ta241V1R4QmJzU2xybmlybzlMOS82TFJrNEFueldmYkNtTWx6QVRtL3lv?=
 =?utf-8?B?STVITnJXTEhzWk5qdUY2bUlFc0xoUHU2NTB5bThoOWhjR0I0M3ZUMml2K3JC?=
 =?utf-8?B?UW9sNDAvRjBkWTdNYTBBc2dGYU9yWmFkcmx2cXBpckFFbHpnWkhWK1RZcmFj?=
 =?utf-8?B?NE95M0h4TGY2MVZpZzZ1M0FSdHowNUpObFprMDRmMEE4VTBhWlRoaVVpVjhz?=
 =?utf-8?B?bC9pK0VoVzgyaVdNYWs0Mys2Z2Roc09PbTUzOU80MVRxQ3IxNjgvKzFvSE1w?=
 =?utf-8?B?Wmx5YXMvejFRaWpWbytyWXpuZHJDdlZjMlNGVGV5RncyU3VnTGk2ajFwTUY4?=
 =?utf-8?B?aEEweTlUam51dDMyaUJOZUZwKytjTStoVUhmZnNrbWxka2hsOFF6ek1hZW5G?=
 =?utf-8?B?YW84bXYrMVVtYmZMYVRNZHNadDMyb3dLb2ZpL0ZtNy95QjlIUGNYclNLOXJF?=
 =?utf-8?B?SVI3THRoUDBEeGJDS2Z3WTZON0dXKzVoY1pEWE5HL2lneHpmMk9nbEcwSW1Y?=
 =?utf-8?Q?6EDrz0rFDiqsKdTyMgz85Sxgo0ivv0SsVjHvKc3xsjHN?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a4173358-a1ec-499f-bb29-08db8e992cd7
X-MS-Exchange-CrossTenant-AuthSource: BN8PR12MB3587.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2023 12:01:13.9115
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: yUv3QIa90sclir4hSO6KH0fcHk3FDeS6VKsTPQjF4S6Ytjz2DqNe7UyhzY8ornpe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR12MB9272
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,NICE_REPLY_A,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 26.07.23 um 20:15 schrieb Simon Ser:
> On Monday, July 24th, 2023 at 23:14, Michał Winiarski <michal.winiarski@intel.com> wrote:
>
>> Having a limit of 64 DRM devices is not good enough for modern world
>> where we have multi-GPU servers, SR-IOV virtual functions and virtual
>> devices used for testing.
>> Let's utilize full minor range for DRM devices.
>> To avoid regressing the existing userspace, we're still maintaining the
>> numbering scheme where 0-63 is used for primary, 64-127 is reserved
>> (formerly for control) and 128-191 is used for render.
>> For minors >= 192, we're allocating minors dynamically on a first-come,
>> first-served basis.
> In general the approach looks good to me. Old libdrm will see the new
> nodes as nodes with an unknown type when it tries to infer the nod type
> from the minor, which is as good as it gets.

Yeah, agree. I wouldn't upstream patch #4, but apart from that it looks 
like it shouldn't break anything which wasn't broken before.

> We do need patches to stop trying to infer the node type from the minor
> in libdrm, though. Emil has suggested using sysfs, which we already do
> in a few places in libdrm.

That sounds like a really good idea to me as well.

But what do we do with DRM_MAX_MINOR? Change it or keep it and say apps 
should use drmGetDevices2() like Emil suggested?

Regards,
Christian.