From owner-freebsd-current@FreeBSD.ORG Mon Oct 11 18:13:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7A2106578A; Mon, 11 Oct 2010 18:13:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 364698FC13; Mon, 11 Oct 2010 18:13:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E1CC946B35; Mon, 11 Oct 2010 14:13:37 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 040AF8A029; Mon, 11 Oct 2010 14:13:37 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 11 Oct 2010 11:03:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <4CA3BD7C.9080306@feral.com> <20101010155340.GQ1733@garage.freebsd.pl> <4CB22833.70304@FreeBSD.org> In-Reply-To: <4CB22833.70304@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201010111103.26780.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 11 Oct 2010 14:13:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Alexander Motin , Pawel Jakub Dawidek , Andriy Gapon , sos@freebsd.org Subject: Re: letting glabel recognise a media change X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:13:41 -0000 On Sunday, October 10, 2010 4:55:15 pm Alexander Motin wrote: > Pawel Jakub Dawidek wrote: > > On Thu, Sep 30, 2010 at 08:46:11PM +0300, Alexander Motin wrote: > >> Andriy Gapon wrote: > >>> on 30/09/2010 01:28 Matthew Jacob said the following: > >>>> If something like that was in place, I assure you that things would start to use > >>>> it very quickly. > >>> I am not sure about this. > >>> Because, e.g. I don't see an easy way to know that media is changed in scsi_cd > >>> driver. That is, without polling. I don't consider polling to be an easy way for > >>> a number of reasons. > >> SATA specification defines concept of Asynchronous Notification. It is > >> already used by port multipliers to report about PHY events. It is also > >> supposed to be used by CD drives to report media change. I haven't seen > >> such devices yet, but hope they may appear sometimes. > >> > >> And even without AN support it would be nice to implement proper > >> handling for SCSI "UA - media changed" errors within CAM. It still won't > >> be perfect without using polling, but probably still something. > > > > I'd like to know the original reason why CD device is represented by > > GEOM provider and not CD media. For my naive thinking CD media should be > > GEOM provider that we taste once the media is inserted and orphan once > > the media is removed. I don't see any reasons for CD device to be useful > > GEOM provider, but maybe I'm overlooking something. > > > > Poul-Henning or Soren, do you remember who made and why this design choice? > > SCSI drivers receive no notification on media insertion. Somebody should > poll device. At this moment it is handled by consumers. Indeed not sure > it is the best idea. If we want driver to bother with this polling - we > may do as you propose. Actually in sdhci(4) driver I am doing this way - > mmcsdX device appears when card inserted and disappears on removal. > > I think first thing that may brake if there will be no cdX device - > loading the media with some commands. Also it may be non-intuitive that > drive is present, but disk is not registered in GEOM. With CD drives you are also rather stuck in that the existing ABI for controlling CD drives (e.g. ioctls in 3rd party software to eject a CD) are done on the /dev/cdX device. Ideally enclosures for removable media would be separate devices from the removable media itself, but a lot of existing software for CD's would break if this changes now. -- John Baldwin