mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kyle Moffett <kyle@moffetthome.net>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: How to tell whether a struct file is held by a process?
Date: Fri, 22 May 2009 10:53:13 +0100	[thread overview]
Message-ID: <20090522105313.63e309f0@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <f73f7ab80905211828te5c49dcx863a18c8e428a59f@mail.gmail.com>

> the OP), is to make there be a global "prevent kernel drivers from
> autobinding to  devices on his port" flag, and manage the rest with
> lockfiles in userspace.

Your "practical example" seems to bear no relation to the other stuff,
its a separate topic altogether.

Yes a "don't probe this port" would make sense. The fact kernel space
probes the USB devices by default like the fact we probe partitions by
default and scan scsi busses by default are all really mistakes inherited
from traditional OS designs which also mess up virtualisation the same
way.

So add a skip_ports= facility to the usb core code (or a general
auto_enumerate=0 and a udev interface to trigger scanning so your udev
rules can enumerate just the ports you want). That is probably cleaner
because it makes the identification of ports rather cleaner and clearer.

Alan

  reply	other threads:[~2009-05-22  9:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-19 16:57 Alan Stern
2009-05-21  9:52 ` Al Viro
2009-05-21 14:06   ` Alan Stern
2009-05-21 21:07     ` Kay Sievers
2009-05-21 21:27       ` Alan Stern
2009-05-22 13:30         ` Pantelis Koukousoulas
2009-05-22 13:38           ` Oliver Neukum
2009-05-22 13:43           ` Alan Cox
2009-05-22 13:52             ` Pantelis Koukousoulas
2009-05-22 14:12               ` Alan Cox
2009-05-22 14:29                 ` Pantelis Koukousoulas
2009-05-21 22:14       ` Alan Cox
2009-05-22  1:28         ` Kyle Moffett
2009-05-22  9:53           ` Alan Cox [this message]
2009-05-22 15:12             ` Alan Stern
2009-05-22 15:20               ` Alan Cox
2009-05-22 16:04                 ` Alan Stern
2009-05-22 16:23                   ` Pantelis Koukousoulas
2009-05-22 18:19                     ` Alan Stern
2009-05-22 15:21               ` Kay Sievers
2009-05-22 15:54                 ` Alan Stern
2009-05-22 18:24                   ` Kay Sievers
2009-05-22 18:48                     ` Pantelis Koukousoulas
2009-05-22 19:31                     ` Alan Stern
2009-05-22 21:54                       ` Kay Sievers
2009-05-22 22:07                         ` Alan Stern
2009-05-23 22:47                           ` Kay Sievers
2009-05-22  8:36         ` Oliver Neukum
2009-05-21 22:22     ` Alan Cox
2009-05-22 12:26     ` Oliver Neukum

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=20090522105313.63e309f0@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=kay.sievers@vrfy.org \
    --cc=kyle@moffetthome.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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

all inboxes | Powered by JetHome®