From owner-freebsd-hackers@freebsd.org Sat Nov 21 08:06:53 2015 Return-Path: Delivered-To: freebsd-hackers@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 265F1A2AD97 for ; Sat, 21 Nov 2015 08:06:53 +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 6978F1826; Sat, 21 Nov 2015 08:06:52 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from [192.168.1.100] (unknown [79.119.24.18]) by mail.rdsor.ro (Postfix) with ESMTP id 3DCA11F150; Sat, 21 Nov 2015 10:06:51 +0200 (EET) Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: libUCL / UCL as FreeBSD config question From: Dan Partelly In-Reply-To: <564F8E1F.8060600@freebsd.org> Date: Sat, 21 Nov 2015 10:06:51 +0200 Cc: freebsd-hackers@freebsd.org Message-Id: References: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org> To: Allan Jude X-Mailer: Apple Mail (2.3096.5) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2015 08:06:53 -0000 I gather then that concurrency was deemed s not important , probably not = even mentioned in those talks.=20 I think you guys should think more at concurrency issues, and give them = first class citizen status. Please do not rush a solution. =20 It;s not about making sure that 2 instances of uclcomand don't overlap, = it is to make sure=20 that **nothing** overlaps when accessing that file. No arbitrary n tools = / daeomns whatever.=20 It is a , after all, an OS config file, not the config file of a game. Absent the will to adopt a proper, fully transactional and atomic = mechanism of storing OS configuration,=20 I would go back to the drawing board for a while. It may even be a long = while. Please do not employ an=20 half breed solution to this problem/ Leave things as they are today = until you figure it all out from all angles. > On 20 Nov 2015, at 23:18, Allan Jude wrote: >=20 > On 2015-11-20 15:46, Dan Partelly wrote: >> Allan, >>=20 >> Thanks for clearing my confusion, and furthering my understanding on = whats cooking on this front. >>=20 >> The tool is dandy. I have another issue I want to ask about: >>=20 >> concurrency. Is there any support in either uclib and the tools like = uclcmd to ensure=20 >> atomic access to the ucl files ? And not on advisory level, (although = if utilities would respect=20 >> adviasory looking =E2=80=A6 it would be better than nothing). I mean = something on the lines >> of mandatory locking.=20 >>=20 >> Was the question of concurrency discussed ? >>=20 >> Dan >>=20 >>=20 >=20 > Most of the discussion centered around the design of the config files, > and the library. My tool is in the early stages and was only briefly > discussed with the goal of showing the power of UCL from an automation > standpoint. Obviously uclcmd can use locking to ensure that two > instances do not overlap. Updates to the file would also be atomic = (save > to tmpfile then rename into place), and it could check that the > modification date of the file has not changed since it was read, to > avoid overlapping any other access to the file. >=20 > In the end, I picture it being somewhat like 'vipw' >=20 > --=20 > Allan Jude