Hi,
this weekend I followed up on my attempts to enhance "makeaoi" such that it
can package applications even if they need to access device files.
And I succeeeded in that I was now able to prepare a Subsurface AppImage
on an Arch Linux installation that runs on at least CentOS and is able
to download dives from a Suunto D9 there. You can download this
Proof-of-Concept AppImage at:
https://transfer.sh/2tLny/subsurface-4.6.4-2-x86_64.AppImage
(BTW: Tunneling ioctl()s to device files wasn't the largest part of the
necessary enhancements - I also had to write poll() support for
unionfs-fuse, which was a pain since the FUSE documentation on how
to implement poll() is extremely terse/confusing/incomplete.)
Remember you can unpack AppImages with "--appimage-extract", this
allows for faster startup, you can look into the "packlist.txt" and
scripts if you like, and also you can invoke "extractdirectory/dctool"
which I also packed into this image, if you just want to test
dive computer transfers.
Caveats: So far, I could only test accesses to a Suunto D9. It is
reasonable to assume that other DCs conncted to serial (USB) ports
should work as well.
I could not test Bluetooth connected DCs, as I do not have such at
hand. It is not unlikely that connecting to such requires additional
ioctl()s to be tunneled, this would need to be added to the big switch at
https://github.com/lvml/unionfs-fuse/blob/fake_dev/src/fuse_ops.c#L338
Notice that Qt5 (unrelated to packaging) seems to have two interesting habits:
- For unknown reasons Qt5 performs an open() on any executable it can
find in $PATH - this means a "makeaoi trace directory subsurface"
will leave the names of all those executables in "files.txt" -
I of course removed them for the "packlist.txt"
- Qt5 seems to try using all kinds of modern X visuals and direct
rendering mechanisms, before it falls back to using plain old X11,
which is more than enough performance-wise for subsurface.
Thus I did exclude all the fancy GPU-dependent DRI modules from
the AppImage, they are not really needed and would probably bring
a lot of compatibility issues (some even use completely undocumented
ioctls).
Of course, manually prepared AppImages, built on "older operating systems"
might still be the better / smaller / more compatible(?) solution, I just
thought that since it seems to be a tedious and problematic task at the
moment for the Subsurface maintainers to create more recent AppImages,
I should give the "AppImage with everything" idea a try, since it is really
not much work to create or update such images once a working executable
is available on one machine.
Regards,
Lutz Vieweg
On 07/17/2017 12:06 AM, Lutz Vieweg wrote:> On 07/10/2017 09:45 AM, Lutz Vieweg
wrote:
it does not yet support ioctl() stuff like subsurface needs to do
on device files connecting to dive computer hardware.
Ah, that's a bummer.
Yes. So far I see two ideas how to tackle that:
a) extend the "fake devices via regular files" approach by passing along
ioctl() commands.
Seems like a moderate amount of effort, but success is of course unclear
until tried.
I tried this and succeeded to make two exemplary ioctl()s - TCGETS and TCSETS -
work with https://github.com/lvml/makeaoi
When I've got another free time slot I'll find out which ioctl()s
subsurface needs to communicate fine with my own D9, which should
be one of the easier computers to connect to, and see to support
those as well.
If that turns out to work well, I'll see if I can borrow a Bluetooth
connected device for trying.
b) extend unionfs-fuse by CUSE support, trying to pass through the
system devices as user space devices.
I looked up the (not so great) documentation of this, and it won't
work: Only root is allowed to create devices via CUSE.
Regards,
Lutz Vieweg
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
