Re: tests

2018-01-11 Thread Laurent Bercot

Are there tests for s6?
Are there plans to reach decent code coverage?


 Hi Viktor,
 Sorry for the delayed answer.
 There are no automated tests at the moment. It is hard to design
both a test infrastructure and tests themselves for such a low-level
project. At the moment I'm testing everything by hand, which takes
time.

 If you want to contribute tests (that don't make the package
dependencies significantly heavier), they will be welcome.

--
 Laurent



Re: tests

2018-01-11 Thread SZÉPE Viktor

Idézem/Quoting Laurent Bercot :


Are there tests for s6?
Are there plans to reach decent code coverage?


 Hi Viktor,
 Sorry for the delayed answer.
 There are no automated tests at the moment. It is hard to design
both a test infrastructure and tests themselves for such a low-level
project. At the moment I'm testing everything by hand, which takes
time.

 If you want to contribute tests (that don't make the package
dependencies significantly heavier), they will be welcome.


Hi Laurent!

I was thinking about unit test to test your functions,
and building your code and installing it into a Docker container.
Projects with PID 1 in Docker exist: https://github.com/Yelp/dumb-init



SZÉPE Viktor, honlap üzemeltetés
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
--
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület






Re: tests

2018-01-11 Thread Laurent Bercot

I was thinking about unit test to test your functions,
and building your code and installing it into a Docker container.


 That's the very point: s6 is organized into several small
executables interacting together, so unit tests for functions are
pretty difficult to write. The units that would need testing are
individual executables, so you'd need to come up with a mock
environment to test every executable separately. I'm not sure how
to proceed with this, and have not prioritized it so far because
hand-testing is still manageable for now and I have much more
interesting projects to work on :P



Projects with PID 1 in Docker exist: https://github.com/Yelp/dumb-init


 Oh, definitely, and s6 is already used in numerous Docker containers.
Most people who want to do that use the s6-overlay project:
https://github.com/just-containers/s6-overlay

 Some big companies (Badoo, for instance) rely on s6 to power their
containers, so I think it's a good testimony to the fact that it works 
:)


--
 Laurent



Re: tests

2018-01-11 Thread SZÉPE Viktor

 Oh, definitely, and s6 is already used in numerous Docker containers.
Most people who want to do that use the s6-overlay project:
https://github.com/just-containers/s6-overlay


Thank you for the link!


 Some big companies (Badoo, for instance) rely on s6 to power their
containers, so I think it's a good testimony to the fact that it works :)


Do they contribute back?



SZÉPE Viktor, honlap üzemeltetés
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
--
+36-20-4242498  s...@szepe.net  skype: szepe.viktor
Budapest, III. kerület






Re: tests

2018-01-11 Thread Guillaume Perréal

Le 11/01/2018 à 16:44, Laurent Bercot a écrit :

 Oh, definitely, and s6 is already used in numerous Docker containers.
Most people who want to do that use the s6-overlay project:
https://github.com/just-containers/s6-overlay

 Some big companies (Badoo, for instance) rely on s6 to power their
containers, so I think it's a good testimony to the fact that it works :)

I also use it to run my X sessions: it monitors background services and 
applets, as well as some "front-end" applications (browser, mailer, ...) 
that tends to die often.

--
Guillaume.


Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

2018-01-11 Thread Guillermo
2018-01-09 21:35 GMT-03:00 Laurent Bercot:
>
>  What it looks like is the kernel not assigning a major and a minor
> to the device before you manually trigger the "add". I suspect it's
> just that the relevant module is not loaded, but why would that be
> different from any other hardware managing to make mdevd autoload the
> appropriate module?
> [...]
>  Well I certainly don't want people to need to write their own
> trigger-uevents service, so I'll make sure your hardware is properly
> found by mdevd-coldplug. I'd just like to understand what is happening
> and add the proper fix rather than take a big hammer and scan all of
> /sys/devices just to be sure.

It might be worth to look at what systemd [1] and eudev [2] do here.
When 'udevadm trigger --type=devices --action=add' is performed after
the udev daemon starts executing, it looks like what happens is
basically this:

* If /sys/subsystem exists, an 'add' string is written to every
/sys/subsystem/*/devices/*/uevent file.
* If /sys/subsystem does not exist, an 'add' string is written to
every /sys/class/*/*/uevent and /sys/bus/*/devices/*/uevent file.

I have a 4.9-series kernel and no /sys/subsystem, but I do have
/sys/class/*/* and /sys/bus/*/devices/* files indeed, and they are in
all cases symbolic links to subdirectories of /sys/devices with
'uevent' files. So it kind of looks like a big hammer is used, but
with an easy to generate set of pathnames instead of actually
traversing
the /sys/devices hierarchy. Maybe this can be taken to be the
currently agreed sysfs interface for device managers (or else systemd
breaks).

On the other hand it looks like mdevd-coldplug and BusyBox' 'mdev -s'
want to access the /sys/dev/block/${major}:${minor} and
/sys/dev/char/${major}:${minor} symlinks. If it is the case that some
of these won't exist until the relevant kernel modules are loaded, and
if the device manager is expected to load them, it would mean it can't
reliably use /sys/dev.

For testing purposes, with mdevd-netlink running, either this:

#/bin/execlineb -P
elglob syssubsystem /sys/subsystem/*/devices/*/uevent
forx f { $syssubsystem }
importas -u ueventfile f
redirfd -w 1 $ueventfile
echo add

or this:

#/bin/execlineb -P
elglob sysclass /sys/class/*/*/uevent
elglob sysbus /sys/bus/*/devices/*/uevent
forx f { $sysclass $sysbus }
importas -u ueventfile f
redirfd -w 1 $ueventfile
echo add

could be used to see what happens, depending on the case. I don't have
mdevd installed with a suitable /etc/mdev.conf file at the moment, but
I tried executing the script while eudev's udevd was running (as a
replacement for udevadm trigger), and I did get all kernel modules to
load, and did see new /sys/dev/*/* symlinks after that.

G.

[1]
* https://github.com/systemd/systemd/blob/master/src/udev/udevadm-trigger.c
adm_trigger(), exec_list()
* https://github.com/systemd/systemd/blob/master/src/libudev/libudev-enumerate.c
udev_enumerate_scan_devices()
* 
https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-device/device-enumerator.c
device_enumerator_scan_devices(), enumerator_scan_devices_all(),
enumerator_scan_dir(), enumerator_scan_dir_and_add_devices()
* 
https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-device/sd-device.c
sd_device_new_from_syspath()

[2]
* https://github.com/gentoo/eudev/blob/master/src/udev/udevadm-trigger.c
adm_trigger(), exec_list()
* https://github.com/gentoo/eudev/blob/master/src/libudev/libudev-enumerate.c
udev_enumerate_scan_devices(), scan_devices_all(), scan_dir(),
scan_dir_and_add_devices(), syspath_add()