Date: Tue, 12 Oct 2010 09:08:23 -0400 From: John Baldwin <jhb@freebsd.org> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: Alexander Motin <mav@freebsd.org>, freebsd-current@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, sos@freebsd.org Subject: Re: letting glabel recognise a media change Message-ID: <201010120908.24120.jhb@freebsd.org> In-Reply-To: <20101011201156.GB2346@garage.freebsd.pl> References: <4CA3BD7C.9080306@feral.com> <201010111103.26780.jhb@freebsd.org> <20101011201156.GB2346@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, October 11, 2010 4:11:56 pm Pawel Jakub Dawidek wrote: > On Mon, Oct 11, 2010 at 11:03:26AM -0400, John Baldwin wrote: > > 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. > > Right, but I still wonder if we could execute provider orphan and > retaste on various events like media insertion or removal. If media is > removed we orphan provider and recreate it, which will trigger retaste, > and this is fine there will be nothing to read from or write to (we will > simply return errors as we do now, I think). This way we nicely > co-operate with GEOM, but also with other tools that don't require media > to be present (if there is no media devfs entry still exists and handles > ioctls, it just return errors on read requests). Oh, I would be fine with that. I was just explaining the legacy reasons for why we can't do the obvious thing and have separate devices for media and media holders. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010120908.24120.jhb>