Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3871438ybl; Tue, 21 Jan 2020 08:32:51 -0800 (PST) X-Google-Smtp-Source: APXvYqybtpJRllhnyN9+EA8O80+kvpk8tFLVX+3vlVDwb82HdRhwxu0rHRH8WU/39oD4VPFar/+L X-Received: by 2002:aca:36c1:: with SMTP id d184mr3628109oia.70.1579624370815; Tue, 21 Jan 2020 08:32:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579624370; cv=none; d=google.com; s=arc-20160816; b=tVojRUeOoJS2ew9lqlhrejgn131H3/+Io8e5zn+BTzQLs0SnywOueC8GI6AoCLUxYZ SLspYW+WKn43KsIS7jmYnZ+egKSifwMcucSD7SfoPGlAWYNdJdG0qaZ9A6uB5MErZ9ZJ 6CzP7IFQfJ9npvIEVziQBJFPy1h2+3fRZonCx5UyJGmbVzIrhfHiJQ3ceiFVhN6kFAWS Y9IXo6ti47gLRHOtPoPLbZveZn5uDcVDcFrnlrL3OLyxaBTniDDaVJ323gW/1Rtrvhml Xr2Clq0vMEH+hG037VA3j0KLCSQ5iC9dGM+CZqk+2ERj0qQl7iAn+EogNr4Ii9xZf1nm wehw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=SP0JhopGLwJLWQ5IKifnEJy03+XO6UAu5WURe/cFHUA=; b=ShyhCrS6+Thwe0HXP6DFyaPeor6Q1E17ODTeAe4iunnbgVSjqN1TmUOt/p2H+Rv2kN uN5ELPQ6usLiNDXEv72txQ9TvDGZBgn6oxFSpHT9VZyFvwGTFtpDO4CJTLlBx6al9Wve vElM5wPeR9wSOr0bR/i7/S+ind1Boqmx1IAzsNnLKa9lddWMZA/ZTJv5GcoU1Wx3QxSN BQKrVm5+dfPJzfNBphiFCKO24hAyYXuU63Zp4As6Ce8MEa77DLwGriGx3zoN25XNgaZc 6MKtjYdiarckoE2fWueekVg4xHmZNECWU13SMAx+itGGTHZYX+9aQt78H/QH3z4jxGUH Eigw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b17si20761364otl.320.2020.01.21.08.32.39; Tue, 21 Jan 2020 08:32:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729174AbgAUQb1 (ORCPT + 99 others); Tue, 21 Jan 2020 11:31:27 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:52182 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726555AbgAUQb1 (ORCPT ); Tue, 21 Jan 2020 11:31:27 -0500 Received: from callcc.thunk.org (rrcs-67-53-201-206.west.biz.rr.com [67.53.201.206]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00LGVBCR018494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 11:31:13 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 30D94420057; Tue, 21 Jan 2020 11:31:10 -0500 (EST) Date: Tue, 21 Jan 2020 11:31:10 -0500 From: "Theodore Y. Ts'o" To: Sam Hartman Cc: Zhenzhong Duan , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Arnd Bergmann Subject: Re: Question about dynamic minor number of misc device Message-ID: <20200121163110.GK15860@mit.edu> References: <20200120221323.GJ15860@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 21, 2020 at 08:56:37AM +0100, Arnd Bergmann wrote: > > > I think one patch to move the ones with unique names would be fine, > > > but then separate patches for > > > > > > - FLASH_MINOR move and rename to avoid conflict > > > - change speakup to dynamic minors > > > - support for high dynamic minor numbers if you are really motivated > > > (probably nobody needs these) > > > > Are we sure that reassigning minor device number conflits isn't going > > to break systems? Especially those on random, older, architectures > > they might not be using udev. > > To clarify: the only numbers that I think should be changed to dynamic > allocation are for drivers/staging/speakup. While this is a fairly old > subsystem, I would expect that it being staging means we can be a > little more progressive with the changes. Sam, Would you happen to know how commonly used the speakup system would be --- in particular, on non-udev systems where changing the minor number of the device node might break some folks? Does your hardware system use speakup, or some other interface? Also, who would be the best people to reach out at the linux-speakup.org project to verify what the potential impact might be of making this change. It looks like some of the web pages are a bit dated, so I wasn't sure what's up to date. Thanks!! - Ted