From owner-freebsd-current@freebsd.org Fri Apr 22 08:36:50 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 A95B4B1762A for ; Fri, 22 Apr 2016 08:36:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 368C11FC0 for ; Fri, 22 Apr 2016 08:36:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id n3so2660737wmn.1 for ; Fri, 22 Apr 2016 01:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ng6bGGRa22pXnjiTVC/YEN4cnaEChKGBW/LQVxvA3Pg=; b=cKq2fVeJeFL4ZEX1sA3B6fnN4JwQQ8J2YoT1VUrfQdX4JYGS6ETXEqKuF992n7HL0g PYN4PzjxDSg1RKPcXHvRwYTdhlfM7dCo75r/QN5G/rI5WqbWV0iQuudoRw8aYRAgANu0 nMChHJIDWK4S+2KzuSxYS1LQRb1ZyW9wkf+1RQWf7cq5rSKJPAS+M99r89Ouczw0cs4/ ShpglS43Pt9mH8Vd5td0nbM949DdCh73W1v1dLf+Md1rX99wn3ylDCcXg+2kuMjnNh8/ /yfubHqBy+8m8e1Mwc1f/Dp9bhYF0kR0JEcrr6A3ZuOD8aG8iyWd+5zaYMW8Cm7SR+Q0 CJOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ng6bGGRa22pXnjiTVC/YEN4cnaEChKGBW/LQVxvA3Pg=; b=goUNkE6T5DOtt10eGIljw1w/Ar84TS2cy9KkZzbM1yT64LE41XQaMzuUU87PcHcUrH a5OKORXiacFYUUFdGH+tQKLy8Qf2FDhk3IULIOzQDAADQjN1F3EB4CCKTytMMiS1dDAG hZ9BIc69oMfL6lTEMaIfV6IRLBuQpk5mHJUlpWjV1bWfhdJkOkuuxZ5wxnlEAXFepMBr 7pL56mojRNG/jY7WDZdeM9HV/ZQ2EQ9eJ6L8TfbLRIb4+D76hRLg4iVN/zfSlbpVxkES im4KzVjXXu3QaYo8S1XRGHfJn45NW37yNoqzWxchGV3T5zS0qRFxuyoYzEYdfYcIPJ/h 6bUw== X-Gm-Message-State: AOPr4FUfCiDaaAfnCNwDM/1wbG9HKrZVW0bOGbcxTNcsW8JO+d7O5WH6oKY7p2RS6t34Rg== X-Received: by 10.28.127.80 with SMTP id a77mr2513236wmd.84.1461314207980; Fri, 22 Apr 2016 01:36:47 -0700 (PDT) Received: from brick (esr141.neoplus.adsl.tpnet.pl. [83.20.137.141]) by smtp.gmail.com with ESMTPSA id w2sm6907475wjg.42.2016.04.22.01.36.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Apr 2016 01:36:46 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 22 Apr 2016 10:36:43 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Dan Partelly Cc: freebsd-current Subject: Re: [CFT] packaging the base system with pkg(8) Message-ID: <20160422083643.GA1479@brick> Mail-Followup-To: Dan Partelly , freebsd-current 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> <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7F12F680-080B-4DB3-81A5-CC5282B78034@rdsor.ro> User-Agent: Mutt/1.6.0 (2016-04-01) 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: Fri, 22 Apr 2016 08:36:50 -0000 On 0421T2348, Dan Partelly wrote: > Yes, you are right it misses the media change handler in devd.conf. > maybe it should bementioned somewhere in a man page if it is not > already there. Thanks for the pointer. It's mentioned in a comment in auto_master file. But yeah, mentioning it in a manual page seems like a good idea. > 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 > media inside transparent to the user, without requiring any modifications > to devd.conf, and without relaying on shell scripts. > > Is there any reason you did not took this approach ? This is not > criticism, I am genuinely interested. Yes - I actually like shell scripts. I like being able to provide the glue in a way that's easy to debug and modify, without having to rebuild anything, so that it can be tailored to specific needs by the system administrator. In this case the problem, I think, is not with the shell scripting. It's just that it doesn't "enable itself" when needed, or isn't just enabled by default. > > 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 > where this can be handy. And too many directories left there do become > annoying. Well, you have devd notifications for this - and it gives you much more flexibility. > > On 21 Apr 2016, at 23:20, Edward Tomasz Napierała wrote: > > > > On 0421T1526, Dan Partelly wrote: > >> The scenario is: > >> > >> Let’s say I have autofs_enable , working with media map. > >> > >> 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 > >> 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 > >> device. > >> > >> What I would expect is when I change the media in Cd-rom , a new > >> access point for the volume in question should be reated in /media. > >> > >> Perhaps this functionality is exposed differently by the automounter, > >> but them I would not expect the CDrom to be accessible at all though the > >> media map. > > > > 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". > > > > 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? > > > >>> 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. > >> > >> 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 ? > > > > 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). > > > > [..] >