Subject: Re: User mode drivers: part 2: PCI device handling (patch 1/2 for
	2.6.11)
From: Albert Cahalan <albert@users.sf.net>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Albert Cahalan <albert@users.sourceforge.net>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
       peterc@gelato.unsw.edu.au
In-Reply-To: <1110568542.15927.76.camel@localhost.localdomain>
References: <1110518308.1949.67.camel@cube>
	 <1110568542.15927.76.camel@localhost.localdomain>
Content-Type: text/plain
Date: Fri, 11 Mar 2005 16:04:28 -0500
Message-Id: <1110575069.1949.72.camel@cube>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1072
Lines: 30

On Fri, 2005-03-11 at 19:15 +0000, Alan Cox wrote:
> > You forgot the PCI domain (a.k.a. hose, phb...) number.
> > Also, you might encode bus,slot,function according to
> > the PCI spec. So that gives:
> > 
> > long usr_pci_open(unsigned pcidomain, unsigned devspec, __u64 dmamask);
> 
> Still insufficient because the device might be hotplugged on you. You
> need a file handle that has the expected revocation effects on unplug
> and refcounts

I was under the impression that a file handle would be returned.

I'm not so sure that is a sane way to handle hot-plug though.
First of all, in general, it's going to be like this:

Fan, meet shit.
Shit, meet fan.

Those who care might best be served by SIGBUS with si_code
and si_info set appropriately. Perhaps a revoke() syscall
that handled mmap() would work the same way.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/