From owner-freebsd-current@freebsd.org Thu Apr 21 20:48:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B74ECB17D0D for ; Thu, 21 Apr 2016 20:48:08 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id D1D1F1AAB; Thu, 21 Apr 2016 20:48:07 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.101] (unknown [79.117.119.78]) by mail.rdsor.ro (Postfix) with ESMTP id E7CA4DC102; Thu, 21 Apr 2016 23:48:00 +0300 (EEST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [CFT] packaging the base system with pkg(8) From: Dan Partelly In-Reply-To: <20160421202023.GB33506@brick> Date: Thu, 21 Apr 2016 23:48:00 +0300 Cc: freebsd-current Message-Id: <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> References: <76093.1461096570@critter.freebsd.dk> <5716AD65.8070007@shrew.net> <5716FA70.4080604@freebsd.org> <571765BB.3050908@quip.cz> <79117ce18bd3332c7df3e55e12a161b4@rdsor.ro> <20160421095706.GA57206@brick> <30F6CCDE-E099-49EF-9A1A-68F147FBF50B@rdsor.ro> <20160421202023.GB33506@brick> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 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: Thu, 21 Apr 2016 20:48:08 -0000 Yes, you are right it misses the media change handler in devd.conf.=20 maybe it should bementioned somewhere in a man page if it is not already there. Thanks for the pointer. Anyway, if I would have written the system, what I would have done is to consolidate both user mode daemons into one and make this daemon a client of devd, fstyp a library, and handle all removable=20 media inside transparent to the user, without requiring any = modifications to devd.conf, and without relaying on shell scripts.=20 Is there any reason you did not took this approach ? This is not criticism, I am genuinely interested. > and simply > retrofit the changes back to autofs - but that hasn't happened (yet). Please consider doing it. A kevent on /media would allow other programs to see how volumes come and go, and I can imagine several situations=20 where this can be handy. And too many directories left there do become annoying.=20 > On 21 Apr 2016, at 23:20, Edward Tomasz Napiera=C5=82a = wrote: >=20 > On 0421T1526, Dan Partelly wrote: >> The scenario is: >>=20 >> Let=E2=80=99s say I have autofs_enable , working with media map. >>=20 >> If I have a CD in CD drive , all is well and when the system is fully = booted up >> /media contains a directory through which I can access the content of = the=20 >> CD-ROM. Now if you eject this CD , and insert a new one, nothing = happens. >> /media does not contain a new access point for the new disk inserted = in the=20 >> device. =20 >>=20 >> What I would expect is when I change the media in Cd-rom , a new=20 >> access point for the volume in question should be reated in /media. >>=20 >> Perhaps this functionality is exposed differently by the automounter, >> but them I would not expect the CDrom to be accessible at all though = the=20 >> media map.=20 >=20 > If by "access point" you mean the directory, then it will, unless the = CD > doesn't have a label - in that case the device name will be used = instead, > and since it's the same device, it will be the same name - usually = "cd0". >=20 > However - I've just checked to make sure and it works the way it = should. > What you're decribing seems like you're missing the part of = devd.conf(5) > responsible for notifying autofs about media change. Do you? >=20 >>> he problem here is that it's quite hard to fix, there's a risk >>> of breaking existing functionality, and the problem is largely = cosmetic. >>=20 >> until you have more than 10 of them there, when it largely annoying. >> anyway, what is the reason it is very hard to fix and it would break = existing >> functionality. can you please shed some light ? =20 >=20 > Basically, the autofs doesn't support removing the nodes. It wasn't > really required for the usual use case, and it simplified the code a = lot. > Plan was to pick it up again with my next filesystem project, and = simply > retrofit the changes back to autofs - but that hasn't happened (yet). >=20 > [..]