Linuxisms in s6

[Warner Losh]

On Fri, Aug 26, 2016 at 4:44 AM, Jan Bramkamp <crest at rlwinm.de> wrote:
> On 25/08/16 23:17, Adrian Chadd wrote:
>>
>> On 25 August 2016 at 14:13, Warner Losh <imp at bsdimp.com> wrote:
>>>
>>> On Thu, Aug 25, 2016 at 3:08 PM, Adrian Chadd <adrian at freebsd.org> wrote:
>>>>
>>>> On 25 August 2016 at 12:48, Lars Engels <lars.engels at 0x20.net> wrote:
>>>>>
>>>>> On Thu, Aug 25, 2016 at 08:46:10AM -0700, Adrian Chadd wrote:
>>>>>>
>>>>>> On 24 August 2016 at 21:53, Jonathan de Boyne Pollard
>>>>>> <J.deBoynePollard-newsgroups at ntlworld.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> http://adrianchadd.blogspot.co.uk/2016/08/freebsd-on-tiny-system-whats-missing.html?showComment=1471236502051#c1305086913155850955
>>>>>>> , Adrian Chadd:
>>>>>>>
>>>>>>>> We're using s6 at work, and it works out mostly ok. Mostly once you
>>>>>>>> get
>>>>>>>> around the linuxisms, and the lack of sensible time code in it (its
>>>>>>>> calculations for daemon run duration is based on system time, not
>>>>>>>> wall
>>>>>>>> clock, so if your box boots jan 1, 1970 then gets NTP, things are..
>>>>>>>> hilarious), and some of the arcane bits to get logging working
>>>>>>>> right.
>>>>>>>>
>>>>>>> What are these Linuxisms in s6?  s6-linux-utils and s6-linux-init
>>>>>>> have
>>>>>>> Linuxisms, obviously.  But what Linuxisms does s6 have?
>>>>>>
>>>>>>
>>>>>> We just had a bunch of fun trying to get it to build right, and the
>>>>>> uptime stuff really threw us.
>>>>>>
>>>>>> It's fine though, I found that s6 may start growing an IPC mechanism
>>>>>> so we could possibly do a launchd/jobd style service later (ie to run
>>>>>> things upon event changes, like ifup, ifdown, ifcreate, ifdestroy,
>>>>>> arbitrary messages, etc) so I may try incorporating it again. :)
>>>>>>
>>>>>
>>>>> Can't this be done with devd?
>>>>
>>>>
>>>> Sure, but I'm looking for something more generic than just devd. Like,
>>>> notifications about events like "default route is up" can be done by
>>>> sniffing the rtsock, but notifications like "ntpdate has updated the
>>>> date, we can now do crypto services" doesn't happen there right now.
>>>
>>>
>>> devd was never intended to be limited to just device events from the
>>> kernel. It has grown beyond that, and could easily grow to cope with
>>> routing events and other notifications. No need to reinvent everything
>>> for that.
>>
>>
>> Right. I don't want to reinvent the wheel if it can be avoided.
>
>
> Afaik devd is limited handling events reported by the kernel on /etc/devctl.
> There is no way to inject events into arbitrary events from userspace into
> devd (no ptrace hacks don't count).

It would be trivial to add though, especially since the author is easy to
work with :). It already fans out data to multiple listeners.

Warner