linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Elizabeth Figura <zfigura@codeweavers.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	wine-devel@winehq.org, "André Almeida" <andrealmeid@igalia.com>,
	"Wolfram Sang" <wsa@kernel.org>,
	"Arkadiusz Hiler" <ahiler@codeweavers.com>,
	"Peter Zijlstra" <peterz@infradead.org>
Subject: Re: [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range.
Date: Wed, 24 Jan 2024 04:32:13 -0800	[thread overview]
Message-ID: <2024012454-cosmos-sprint-7db7@gregkh> (raw)
In-Reply-To: <1875326.tdWV9SEqCh@terabithia>

On Tue, Jan 23, 2024 at 09:43:09PM -0600, Elizabeth Figura wrote:
> > Why do you need a fixed minor number?  Can't your userspace handle
> > dynamic numbers?  What systems require a static value?
> 
> I believe I added this because it's necessary for MODULE_ALIAS (and, more 
> broadly, because I was following the example of vaguely comparable devices 
> like /dev/loop-control). I suppose I could instead just remove MODULE_ALIAS 
> (or even remove the ability to compile ntsync as a module entirely).

Do you really need MODULE_ALIAS()?  Having it for char devices to be
auto-loaded is not generally considered a good idea anymore as systems
should have the module loaded before userspace goes and asks for it.

It also reduces suprises when any random userspace program can cause
kernel modules to be loaded for no real reason.

> It's a bit difficult to figure out what's the preferred way to organize things 
> like this (there not being a lot of precedent for this kind of driver) so I'd 
> appreciate any direction.

For now, I'd just stick to a dynamic id, no module alias, and if it's
ever needed in the future, it can be added.  But if you add it now, we
can't ever remove it as it's user-visible functionality.

thanks,

greg k-h

  reply	other threads:[~2024-01-24 12:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-24  0:40 [RFC PATCH 0/9] NT synchronization primitive driver Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 1/9] ntsync: Introduce the ntsync driver and character device Elizabeth Figura
2024-01-24  7:38   ` Arnd Bergmann
2024-01-24 17:51     ` Elizabeth Figura
2024-01-24 21:26   ` Andy Lutomirski
2024-01-24 22:56     ` Elizabeth Figura
2024-01-25  3:42       ` Elizabeth Figura
2024-01-25 16:47         ` Arnd Bergmann
2024-01-25 18:21           ` Elizabeth Figura
2024-01-25 18:55         ` Andy Lutomirski
2024-01-25 21:45           ` Elizabeth Figura
2024-01-25  7:41       ` Alexandre Julliard
2024-01-24  0:40 ` [RFC PATCH 2/9] ntsync: Reserve a minor device number and ioctl range Elizabeth Figura
2024-01-24  0:54   ` Greg Kroah-Hartman
2024-01-24  3:43     ` Elizabeth Figura
2024-01-24 12:32       ` Greg Kroah-Hartman [this message]
2024-01-24 17:59         ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 3/9] ntsync: Introduce NTSYNC_IOC_CREATE_SEM and NTSYNC_IOC_DELETE Elizabeth Figura
2024-01-24  1:14   ` Greg Kroah-Hartman
2024-01-24  3:35     ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 4/9] ntsync: Introduce NTSYNC_IOC_PUT_SEM Elizabeth Figura
2024-01-25  8:59   ` Nikolay Borisov
2024-01-24  0:40 ` [RFC PATCH 5/9] ntsync: Introduce NTSYNC_IOC_WAIT_ANY Elizabeth Figura
2024-01-24  7:56   ` Arnd Bergmann
2024-01-24 18:02     ` Elizabeth Figura
2024-01-24 19:52       ` Arnd Bergmann
2024-01-24 22:28         ` Elizabeth Figura
2024-01-25 17:02           ` Arnd Bergmann
2024-01-25 18:30             ` Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 6/9] ntsync: Introduce NTSYNC_IOC_WAIT_ALL Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 7/9] ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX Elizabeth Figura
2024-01-24  0:40 ` [RFC PATCH 8/9] ntsync: Introduce NTSYNC_IOC_PUT_MUTEX Elizabeth Figura
2024-01-24  7:42   ` Arnd Bergmann
2024-01-24 18:03     ` Elizabeth Figura
2024-01-24 19:53       ` Arnd Bergmann
2024-01-24  0:40 ` [RFC PATCH 9/9] ntsync: Introduce NTSYNC_IOC_KILL_OWNER Elizabeth Figura
2024-01-24  0:59 ` [RFC PATCH 0/9] NT synchronization primitive driver Greg Kroah-Hartman
2024-01-24  1:37   ` Elizabeth Figura
2024-01-24 12:29     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024012454-cosmos-sprint-7db7@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=ahiler@codeweavers.com \
    --cc=andrealmeid@igalia.com \
    --cc=arnd@arndb.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=wine-devel@winehq.org \
    --cc=wsa@kernel.org \
    --cc=zfigura@codeweavers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).