Date: Sat, 21 Nov 2015 10:06:51 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Allan Jude <allanjude@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: libUCL / UCL as FreeBSD config question Message-ID: <CE91041D-0888-412D-BCBA-448A874D38BA@rdsor.ro> In-Reply-To: <564F8E1F.8060600@freebsd.org> References: <5B598F72-C5DD-48FD-866D-F90E117D646E@rdsor.ro> <564F6118.5030702@freebsd.org> <5576AC9A-791F-4B52-9433-32D2806D35C9@rdsor.ro> <564F8E1F.8060600@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <allanjude@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CE91041D-0888-412D-BCBA-448A874D38BA>