From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 06:16:25 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F498106564A for ; Wed, 29 Feb 2012 06:16:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 632948FC0C for ; Wed, 29 Feb 2012 06:16:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1T6Fcrx008022; Wed, 29 Feb 2012 17:15:38 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 29 Feb 2012 17:15:38 +1100 (EST) From: Ian Smith To: vermaden In-Reply-To: Message-ID: <20120229163223.L80360@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Andriy Gapon , Hans Petter Selasky , Alexander Leidinger Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 06:16:25 -0000 On Tue, 28 Feb 2012, vermaden wrote: > "Andriy Gapon" pisze: > > on 29/02/2012 00:04 vermaden said the following: > > > "Andriy Gapon" said: > > >> on 28/02/2012 17:26 Alexander Leidinger said the following: > > >>> The kernel does not poll for CD changes, and the people guarding the relevant CD > > >>> code where against something like this in the kernel everytime this came up in > > >>> the past. So no devd event for this. > > >> > > >> My impression was that lately people were asking for it (and nobody actually > > >> "guarded" the code), but there is no good design on how to do it. > > > > > > The mentioned earlier sysctl OID changes whenever CD is in the > > > drive or not, something changes that ... so adding appreciate > > > events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class > > > should be enought to handle them and mount/umount the > > > medium with script like mine with appreciate devd(8) config. > > > > I don't think that there is any kernel component that pro-actively changes that > > value. Most likely you have something like hald running or otherwise tried to > > access the device before the change was noted. > > I do not even have working CD drive in my laptop, so I cant tell ;) > > Ivan Klymenko sent this earlier in that thread: > > NO CD: > > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 > > CD IN: > > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 That looks like a DVD, I only have a CDRW in this .. but inserting either a music or a data CD has no effect whatsoever on that sysctl here, on 8.2-RELEASE anyway, which still has /dev/acd0 as well. Further, it's not so easy to parse: t23# sysctl kern.geom.conftxt t23# ie nothing, but no 'unknown oid' either, huh? t23# sysctl -d kern.geom.conftxt kern.geom.conftxt: Dump the GEOM config in txt Hmm, checking sysctl(8), only the -b switch seems to dump it: t23# sysctl -b kern.geom.conftxt 0 DISK cd0 534181888 2048 hd 0 sc 0 0 DISK ad0 120034123776 512 hd 16 sc 63 1 PART ad0s4 34143137280 512 i 4 o 85888373760 ty freebsd xs MBR xt 165 [.. partitions on slices s4, s3, s2 and DOS slice s1 shown, omitted ..] but: t23# sysctl -b kern.geom.conftxt | grep cd0 Binary file (standard input) matches Note also that the above entry for cd0 does NOT change after inserting various different data CDs, all different sizes, nor after mounting one, so that 534181888 entry is from some time before, perhaps the first CD inserted after boot, not sure? Also the sizes are bytes, regardless of sector size (DVD above, while ad0s4 is a 32GiB slice on a 120GB disk). Doesn't look like this one is going to fly. cheers, Ian (meanwhile other progress is looking good, maybe I'll get some time next month to play with it, still behind due to aforesaid near-disaster :)