Re: [DNG] netman GIT project
Pushed libpqxx++ to GitLab: https://gitlab.com/aitor_czr/libpqxx/tree/master It uses command line parameters :) Aitor. El 04/09/15 a las 20:44, Edward Bartolo escribió: I will use command line parameters for the GUI frontend so that it may be started to automatically scan for available wifis and connections and to automatically select the best connection if that is configured. So, there is no need of using /etc for further configuration. netman auto-connect Will connect automatically on startup using the algorithm described above. Edward On 02/09/2015, Edward Bartolo wrote: >Hi, > >This is a link to a post by keithpeter on forums.debian.net which >looks encouraging notwithstanding the hard-to-workaround bugs that I >am facing now. > >http://forums.debian.net/viewtopic.php?f=3&t=124343&p=591309#p591124 > > >Thanks, keithpeter and all who boost my motivation to finish this project. > > > >Edward. > > >On 01/09/2015, aitor_czr wrote: >>Ok. >> >>On 01/09/15 12:33, Edward Bartolo wrote: >>>Hi Aitor, >>> >>>As soon as I have time I will have a look at the code. >>> >>>Regarding learning to use git, I learnt to push my commits and do git >>>pulls to synchronize my sources with those of the repository. >>> >>>I took note of all the git commands used together with the sequence in >>>which they were issued. >>> >>> >>>Edward >>> >>>On 01/09/2015, aitor_czr wrote: Hi Edward, Here is the code of my libpqxx++ project: http://gnuinos.org/libpqxx++/ (Now i can't access to any git repository in my gitlab account; apparently it's in maintenance). It is a small project, and you can analyze the debian branch (debian/rules, etc...). The separation: libpqxx libpqxx-dev is not done yet. On the other hand, if you are interested in git, i recommend you Pro Git Book: https://git-scm.com/book/en/v1 Cheers, Aitor. On 31/08/15 14:00, Edward Bartolo wrote: >On 31/08/15 09:43, Edward Bartolo wrote: >>>I am attaching my updated code to this email as I couldn't commit my >>>changes. GIT is blocking me. >>> >>> >>>Edward >> ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] xf86-input-evdev
On arch linux xf86-input-evdev is reported to have a dependency on systemd. I thought the dependency is on udev and that is usually reported on arch like systemd(udev). I downloaded xf86-input-evdev for recompilation but could not find any switches to compile without systemd though some evidence pointing at a udev dependency was there. Does anyone know? best regards Scooby ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
Good afternoon, On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: > On arch linux xf86-input-evdev is reported to have a dependency on systemd. > > I thought the dependency is on udev and that is usually reported on arch > like > systemd(udev). > > I downloaded xf86-input-evdev for recompilation but could not find any > switches > to compile without systemd though some evidence pointing at a udev > dependency was there. > > > Does anyone know? > > > best regards > > Scooby It's difficult to answer. evdev depends on udev, but systemd fagocitated udev. If you have udev or eudev functional without any init blob of sorts, evdev will compile against it though. -- Teodoro Santoni Something went wrong. I don't wanna compile 20 KB of Go code to list files. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
On Sat, Sep 05, 2015 at 03:39:17PM +0200, Teodoro Santoni wrote: > Good afternoon, > > On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: > > On arch linux xf86-input-evdev is reported to have a dependency on systemd. > > > > I thought the dependency is on udev and that is usually reported on arch > > like > > systemd(udev). > > > > I downloaded xf86-input-evdev for recompilation but could not find any > > switches > > to compile without systemd though some evidence pointing at a udev > > dependency was there. > > > > > > Does anyone know? > > > > > > best regards > > > > Scooby > > It's difficult to answer. evdev depends on udev, but systemd fagocitated udev. > If you have udev or eudev functional without any init blob of sorts, evdev > will compile against it though. You might try against vdev, as well. There's no systemd dependency in vdev, which is being written by our own Jude Nelson. It may not be ready for production, but I'm sure Jude would appreciate the feedback. -- hendrik > > -- > Teodoro Santoni > > Something went wrong. I don't wanna compile 20 KB of Go code to list files. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Edward Bartolo writes:
> I am not putting in doubt what you are telling me.
You are. And you are - pardon my frankness - very much confused
regarding how 'processes and process relationships' work on UNIX(*)/
Linux. I'll try to clear this up but you might want to consider getting
yourself a good book on the topic.
> In my implementation, the backend is run from within the code of the
> frontend, so its ppid is the pid of the frontend.
This is correct.
> Occurrences of execl, create another child process which is owned by
> the backend, but the latter, dies as soon as the child process is
> created.
This isn't: execl doesn't create a child process associated with the
process invoking it but it makes this process execute a new program. You
can see this for yourself. Save the following two C source code files to
some directory as a.c and b.c.
a.c -
#include
#include
int main(void)
{
printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(),
getppid());
execl("./program-2", "p2", (void *)0);
return 0;
}
--
b.c
#include
#include
int main(void)
{
printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(),
getppid());
return 0;
}
-
compile them into exectuables named program-1 and program-2 via
gcc -o program-1 a.c
gcc -o program-2 b.c
and run program-1. The output should be (with different actual pids, of
course)
[rw@doppelsaurus]/tmp#./program-1
I'm program-1, my pid is 8935 and my parent is 3395
I'm program-2, my pid is 8935 and my parent is 3395
> The orphaned child is related to the frontend, but its direct parent
> being dead, is assigned the pid of the frontend as its parent.
Orphaned child processes don't become children of the parent of their
original parent, they become children of init/
the-process-with-pid-1. init mostly just executes a wait-loop in order
to collect (and ignore) the exit status of any process assigned to it in
this way to prevent them from turning into zombies.
> The complications arise considering the fact, that the backend runs with root
> privileges,
[...]
> It seems, the fact that child processes created by instances of the
> backend, are thus owned by root, and the frontend is not permitted to
> wait() and reap them.
As the example program from my last mail should have demonstrated:
This is also wrong. A process can collect the status of one if its
children even if the child is executing under a different euid and if
this different euid happens to be 0.
BTW: Despite I don't have a WiFi-capable computer here, I cloned the
edbarx/netman.git repository to see if I could perhaps fix
this. However, the code available via
https://git.devuan.org/edbarx/netman.git
doesn't compile. The backend_src/bin and backend_src/obj directories are
missing. This is likely due to a misfeature (IMO) of all SCMs I've been
using so far, namely, they drop empty directories. You can avoid this by
creating a dummy file in both, eg,
touch backend_src/obj/.keep
touch backend_src/bin/.keep
and check them into git like this
git add backend_src/obj/.keep backend_src/bin/.keep
git commit -a -m 'directories needed by the build system'
After doing this, the build aborts with
backend.pas(96,13) Error: Identifier not found "RunCommand"
(occurs a couple of times). I could fix this but since this seems like a
minor oversight to me, I suggest that you put the missing stuff into the
public repository instead.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
vdev is currently not providing its own pkg-config file, so if you want to try building evdev against it, you should take the .pc file from either systemd or eudev. On Sat, Sep 05, 2015 at 09:50:13AM -0400, Hendrik Boom wrote: > On Sat, Sep 05, 2015 at 03:39:17PM +0200, Teodoro Santoni wrote: > > Good afternoon, > > > > On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: > > > On arch linux xf86-input-evdev is reported to have a dependency on > > > systemd. > > > > > > I thought the dependency is on udev and that is usually reported on arch > > > like > > > systemd(udev). > > > > > > I downloaded xf86-input-evdev for recompilation but could not find any > > > switches > > > to compile without systemd though some evidence pointing at a udev > > > dependency was there. > > > > > > > > > Does anyone know? > > > > > > > > > best regards > > > > > > Scooby > > > > It's difficult to answer. evdev depends on udev, but systemd fagocitated > > udev. > > If you have udev or eudev functional without any init blob of sorts, evdev > > will compile against it though. > > You might try against vdev, as well. There's no systemd dependency in > vdev, which is being written by our own Jude Nelson. > It may not be ready for production, but I'm sure Jude would appreciate > the feedback. > > -- hendrik > > > > > -- > > Teodoro Santoni > > > > Something went wrong. I don't wanna compile 20 KB of Go code to list files. > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Edward, A rather thorough reference is "The Linux Programming Interface" available from: http://www.man7.org/tlpi/ and other retailers. HTH, - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: > On arch linux xf86-input-evdev is reported to have a dependency on systemd. > > I thought the dependency is on udev and that is usually reported on arch > like > systemd(udev). > > I downloaded xf86-input-evdev for recompilation but could not find any > switches > to compile without systemd though some evidence pointing at a udev > dependency was there. > > Does anyone know? Long explanation here. xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's hotplug support, which depends on libudev (or an API-compatible replacement such as libudev-compat or libeudev...); at least in theory, you can also use it as a pre-configured device driver. The hotplug path will load evdev for *all* input devices that are hotplugged--power buttons included. So, evdev needs to check if a device is "virtual". This is a simple matter of checking that the canonical path in sysfs contains the string "LNXSYSTM". Getting that canonical path is the hard part, since you receive a device path instead of anything pointing into sysfs. This can be done more-or-less by getting the device major and minor via stat(), checking that it's a char device, then identifying the corresponding link in /sys/dev/ - this would be the string returned by: sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor) and then use readlink() to check where it points; the result is the canonical path. However, most people prefer to avoid depending on the sysfs layout even where its behavior is documented; libudev provides a thin veneer to hide it. So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do this. There is no dependency on udev being running. I've redone that function without udev but using my own library libsysdev, which I mentioned earlier this summer. Repositories that you'd need to build that: -https://github.com/idunham/libsysdev -https://github.com/idunham/xf86-input-evdev (branch sysdev) But that does require something that has no Debian packaging yet. There are also two other options: - comment out that function and disable device hotplug in Xorg.conf or xorg.conf.d - replace the function with one that does all the work itself. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
On Sat, Sep 05, 2015 at 06:38:27PM +0300, Jack L. Frost wrote: > vdev is currently not providing its own pkg-config file, so if you want to try > building evdev against it, you should take the .pc file from either systemd or > eudev. > Or hacking the... whatever the eff evdev uses to build in order to say to it where vdev's header files and libs are. .pc files are a useful helper but aren't mandatory to compile things. -- Teodoro Santoni Something went wrong. I don't wanna compile 20 KB of Go code to list files. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
First of all, thanks for taking the time to write to me.
Using "ps xao pid,ppid,comm", I found what I described to you:
precisely, that orphaned processes were adopted by the GUI frontend.
The frontend's pid was listed as the zombies' ppid. Now, this issue
has little effect on the code as I am using the WaitOnExit for any
behind the scenes processes. Using a second thread to call the
backend, enabled me to use WaitOnExit without affecting the frontend.
The pasted listing is a listing by ps. You can see that ifup, ifdown
and backend have actually inherited their grandfather's pid.
$ ps xao pid,ppid,comm
PID PPID COMMAND
1 0 init
2 0 kthreadd
3 2 ksoftirqd/0
5 2 kworker/0:0H
7 2 rcu_sched
8 2 rcu_bh
9 2 migration/0
10 2 watchdog/0
11 2 watchdog/1
12 2 migration/1
13 2 ksoftirqd/1
15 2 kworker/1:0H
16 2 khelper
17 2 kdevtmpfs
18 2 netns
19 2 khungtaskd
20 2 writeback
21 2 ksmd
22 2 khugepaged
23 2 crypto
24 2 kintegrityd
25 2 bioset
26 2 kblockd
27 2 kworker/0:1
28 2 kworker/1:1
29 2 kswapd0
30 2 fsnotify_mark
36 2 kthrotld
37 2 ipv6_addrconf
38 2 kworker/0:2
39 2 deferwq
73 2 khubd
76 2 acpi_thermal_pm
77 2 ata_sff
78 2 scsi_eh_0
79 2 scsi_tmf_0
80 2 scsi_eh_1
81 2 scsi_tmf_1
82 2 kworker/u8:2
83 2 kworker/u8:3
84 2 scsi_eh_2
85 2 scsi_tmf_2
86 2 scsi_eh_3
87 2 scsi_tmf_3
92 2 kworker/1:2
94 2 kworker/1:1H
95 2 kworker/0:1H
117 2 jbd2/sda9-8
118 2 ext4-rsv-conver
308 1 udevd
365 2 hd-audio0
372 2 kpsmoused
379 2 cfg80211
1276 1 rpcbind
1304 1 rpc.statd
1309 2 rpciod
1311 2 nfsiod
1318 1 rpc.idmapd
1555 1 privoxy
1563 1 rsyslogd
1601 1 atd
1631 1 acpid
1669 1 cron
1727 1 dbus-daemon
1969 1 exim4
1989 1 slim
2015 1989 Xorg
2016 1 getty
2017 1 getty
2018 1 getty
2019 1 getty
2020 1 getty
2021 1 getty
2034 2 kauditd
2036 1 console-kit-dae
2103 1 polkitd
2114 1989 sh
2166 2114 ssh-agent
2169 1 dbus-launch
2170 1 dbus-daemon
2180 2114 xfce4-session
2182 1 xfconfd
2186 1 gpg-agent
2187 2180 xfwm4
2189 2180 xfce4-panel
2191 1 xfsettingsd
2193 1 syndaemon
2195 2180 xfdesktop
2199 1 xfce4-power-man
2203 1 xscreensaver
2206 1 xfce4-power-man
2209 1 xfce4-volumed
2212 1 upowerd
2223 2189 panel-6-systray
2239 2189 panel-2-actions
2377 2189 iceweasel
2398 1 at-spi-bus-laun
2407 2189 xchat
2571 2 kworker/0:0
2572 2 kworker/1:0
2607 1 Thunar
2611 1 tumblerd
2616 1 netman
2633 2616 backend
2643 2616 ifdown
2663 2 kworker/0:3
2664 2 kworker/0:4
2698 1 xfce4-terminal
2702 2698 gnome-pty-helpe
2703 2698 bash
2791 2616 ifup
2801 1 wpa_supplicant
2823 2 kworker/u8:0
2843 1 dhclient
3044 2703 ps
As you can see, the listed zombies have inherited their grandfather's
pid as their ppid.
On 05/09/2015, Rainer Weikusat wrote:
> Edward Bartolo writes:
>> I am not putting in doubt what you are telling me.
>
> You are. And you are - pardon my frankness - very much confused
> regarding how 'processes and process relationships' work on UNIX(*)/
> Linux. I'll try to clear this up but you might want to consider getting
> yourself a good book on the topic.
>
>> In my implementation, the backend is run from within the code of the
>> frontend, so its ppid is the pid of the frontend.
>
> This is correct.
>
>> Occurrences of execl, create another child process which is owned by
>> the backend, but the latter, dies as soon as the child process is
>> created.
>
> This isn't: execl doesn't create a child process associated with the
> process invoking it but it makes this process execute a new program. You
> can see this for yourself. Save the following two C source code files to
> some directory as a.c and b.c.
>
> a.c -
> #include
> #include
>
> int main(void)
> {
> printf("I'm program-1, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> execl("./program-2", "p2", (void *)0);
> return 0;
> }
> --
>
> b.c
> #include
> #include
>
> int main(void)
> {
> printf("I'm program-2, my pid is %lu and my parent is %lu\n", getpid(),
> getppid());
> return 0;
> }
> -
>
> compile them into exectuables named program-1 and program-2 via
>
> gcc -o program-1 a.c
> gcc -o program-2 b.c
>
> and run program-1. The output should be (with different actual pids, of
> course)
>
> [rw@doppelsaurus]/tmp#./program-1
> I'm program-1, my pid is 8935 and my parent is 3395
> I'm program-2, my pid is 8935 and my parent is 3395
>
>> The orphaned child is related to the f
Re: [DNG] Doing away with multi-threading in my project (netman)
Edward Bartolo writes: [...] > Using "ps xao pid,ppid,comm", I found what I described to you: > precisely, that orphaned processes were adopted by the GUI frontend. There are no 'orphaned processes' in this case because execl does not create a new process. It runs a new program in the same process and since the parent of this process was the frontend process before the execl, it's still the parent of this process afterwards. An 'orphaned process' is one whose parent has exited after creating a process (that's done via fork and not via execve) and it's not adopted by the grand parent but by init. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
Just to be clear my system before upgrade was using vdev in conjunction with xf86-input-evdev and working fine. I did not recompile that version of evdev and it just worked with libudev-compat. When I upgraded to new version of both( and new kernel) keyboard stopped working( though could be brought to life with static conf in xorg.conf.d). I thought maybe arch had done something to break functionality here. It could also be some regression in vdev and I will speak to jude about that after September 12 when he's got more time. @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. Isaac I know about your package and have checked it out before but didn't fully understand it. What is triggering evdev in your case? a file in xorg.conf.d? I am gonna try your solution with libsysdev and sysdev branch of xf86-input-evdev. Although it would easier( for me that is) if the arch version just worked with vdev. I love that you give full explanation, thanks best regards Scooby On 2015-09-05 20:36, Isaac Dunham wrote: On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: On arch linux xf86-input-evdev is reported to have a dependency on systemd. I thought the dependency is on udev and that is usually reported on arch like systemd(udev). I downloaded xf86-input-evdev for recompilation but could not find any switches to compile without systemd though some evidence pointing at a udev dependency was there. Does anyone know? Long explanation here. xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's hotplug support, which depends on libudev (or an API-compatible replacement such as libudev-compat or libeudev...); at least in theory, you can also use it as a pre-configured device driver. The hotplug path will load evdev for *all* input devices that are hotplugged--power buttons included. So, evdev needs to check if a device is "virtual". This is a simple matter of checking that the canonical path in sysfs contains the string "LNXSYSTM". Getting that canonical path is the hard part, since you receive a device path instead of anything pointing into sysfs. This can be done more-or-less by getting the device major and minor via stat(), checking that it's a char device, then identifying the corresponding link in /sys/dev/ - this would be the string returned by: sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor) and then use readlink() to check where it points; the result is the canonical path. However, most people prefer to avoid depending on the sysfs layout even where its behavior is documented; libudev provides a thin veneer to hide it. So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do this. There is no dependency on udev being running. I've redone that function without udev but using my own library libsysdev, which I mentioned earlier this summer. Repositories that you'd need to build that: -https://github.com/idunham/libsysdev -https://github.com/idunham/xf86-input-evdev (branch sysdev) But that does require something that has no Debian packaging yet. There are also two other options: - comment out that function and disable device hotplug in Xorg.conf or xorg.conf.d - replace the function with one that does all the work itself. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
I also forgot to say that on my upgraded system with vdev and arch version of xf86-input-evdev touchpad gets detected and loaded that I believe is fascilitated by evdev and libudev-compat?? best regards Scooby On 2015-09-05 21:40, shraptor wrote: Just to be clear my system before upgrade was using vdev in conjunction with xf86-input-evdev and working fine. I did not recompile that version of evdev and it just worked with libudev-compat. When I upgraded to new version of both( and new kernel) keyboard stopped working( though could be brought to life with static conf in xorg.conf.d). I thought maybe arch had done something to break functionality here. It could also be some regression in vdev and I will speak to jude about that after September 12 when he's got more time. @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. Isaac I know about your package and have checked it out before but didn't fully understand it. What is triggering evdev in your case? a file in xorg.conf.d? I am gonna try your solution with libsysdev and sysdev branch of xf86-input-evdev. Although it would easier( for me that is) if the arch version just worked with vdev. I love that you give full explanation, thanks best regards Scooby On 2015-09-05 20:36, Isaac Dunham wrote: On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: On arch linux xf86-input-evdev is reported to have a dependency on systemd. I thought the dependency is on udev and that is usually reported on arch like systemd(udev). I downloaded xf86-input-evdev for recompilation but could not find any switches to compile without systemd though some evidence pointing at a udev dependency was there. Does anyone know? Long explanation here. xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's hotplug support, which depends on libudev (or an API-compatible replacement such as libudev-compat or libeudev...); at least in theory, you can also use it as a pre-configured device driver. The hotplug path will load evdev for *all* input devices that are hotplugged--power buttons included. So, evdev needs to check if a device is "virtual". This is a simple matter of checking that the canonical path in sysfs contains the string "LNXSYSTM". Getting that canonical path is the hard part, since you receive a device path instead of anything pointing into sysfs. This can be done more-or-less by getting the device major and minor via stat(), checking that it's a char device, then identifying the corresponding link in /sys/dev/ - this would be the string returned by: sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor) and then use readlink() to check where it points; the result is the canonical path. However, most people prefer to avoid depending on the sysfs layout even where its behavior is documented; libudev provides a thin veneer to hide it. So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do this. There is no dependency on udev being running. I've redone that function without udev but using my own library libsysdev, which I mentioned earlier this summer. Repositories that you'd need to build that: -https://github.com/idunham/libsysdev -https://github.com/idunham/xf86-input-evdev (branch sysdev) But that does require something that has no Debian packaging yet. There are also two other options: - comment out that function and disable device hotplug in Xorg.conf or xorg.conf.d - replace the function with one that does all the work itself. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Quote: <> So what is the difference between an "orphaned process", i.e. a process whose parent has exited after giving birth to a child process and one which replaces the original process effectively giving its parent a death sentence? Sorry, but it looks there is only a very subtle difference between the two. The only difference I see, is that, since in the case of execl, the parent effectively is replaced, i.e. dies, it is also awarded its parent PID. This is not the case when a parent process creates a child process and exits immediately, as the child will have a different PID. On 05/09/2015, Rainer Weikusat wrote: > Edward Bartolo writes: > > [...] > >> Using "ps xao pid,ppid,comm", I found what I described to you: >> precisely, that orphaned processes were adopted by the GUI frontend. > > There are no 'orphaned processes' in this case because execl does not > create a new process. It runs a new program in the same process and > since the parent of this process was the frontend process before the > execl, it's still the parent of this process afterwards. > > An 'orphaned process' is one whose parent has exited after creating a > process (that's done via fork and not via execve) and it's not adopted > by the grand parent but by init. > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
Correction: Sorry, but it looks there is only a very subtle difference between the two. The only difference I see, is that, since in the case of execl, the parent effectively is replaced, i.e. dies, the child process is awarded its parent PID. This is not the case when a parent process creates a child process and exits immediately, as the child will have a different PID. On 05/09/2015, Edward Bartolo wrote: > Quote: < a > process (that's done via fork and not via execve) and it's not adopted > by the grand parent but by init.>> > > So what is the difference between an "orphaned process", i.e. a > process whose parent has exited after giving birth to a child process > and one which replaces the original process effectively giving its > parent a death sentence? > > Sorry, but it looks there is only a very subtle difference between the > two. The only difference I see, is that, since in the case of execl, > the parent effectively is replaced, i.e. dies, it is also awarded its > parent PID. This is not the case when a parent process creates a child > process and exits immediately, as the child will have a different PID. > > On 05/09/2015, Rainer Weikusat wrote: >> Edward Bartolo writes: >> >> [...] >> >>> Using "ps xao pid,ppid,comm", I found what I described to you: >>> precisely, that orphaned processes were adopted by the GUI frontend. >> >> There are no 'orphaned processes' in this case because execl does not >> create a new process. It runs a new program in the same process and >> since the parent of this process was the frontend process before the >> execl, it's still the parent of this process afterwards. >> >> An 'orphaned process' is one whose parent has exited after creating a >> process (that's done via fork and not via execve) and it's not adopted >> by the grand parent but by init. >> ___ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [kato...@freaknet.org: Re: Doing away with multi-threading in my project (netman)]
On Sat, Sep 05, 2015 at 08:54:25PM +0100, Edward Bartolo wrote: > Correction: > > Sorry, but it looks there is only a very subtle difference between the > two. The only difference I see, is that, since in the case of execl, > the parent effectively is replaced, i.e. dies, the child process is awarded > its > parent PID. This is not the case when a parent process creates a child > process and exits immediately, as the child will have a different PID. > > > Maybe I am stating the obvious again, but the only way to create a child process is by calling "fork()". Such a call will effectively clone the current process into a child process. This means that the child inherits (almost) *everything* from the parent, including its progam pages (the code). This is why, usually, the first thing a child process does is to call to one of the functions in the exec?* family (execv, execl, or one of the many existing variants), which effectively loads *another* program in the program page of the current process (in this case, the child process), and starts executing it. When a process dies, it becomes a "zombie" and a SIGCHLD signal is delivered to its parent. The correct way of managing this *normal* behaviour is for the parent to set a signal handler for SIGCHLD which calls waitpid (I sent a reference about this in a previous email). This is what is meant by "reaping" children. If this is not done, the zombie process will hang around forever (almost, see below). If the parent of a process dies before the process itself, the "orphaned" process is assigned a new parent, which is the process with PID 1 (init). This means that init will then take care of all the orphaned children of the dead process, becoming their parent, and, as any good parent, will receive the SIGCHLD from any of those processes when they die. On top of that, init will also receive a SIGCHLD for any of those orphaned process which were zombie before "adoption", and will take care of those signals properly (i.e., by calling waitpid in the handler of SIGCHLD it had set beforehand). To the best of my knowledge, the scenario you where suggesting in a previous email (children processes which are adopted by their grandfather) is not feasible, with the only incidental exception in which their grandparent is PID 1 itself (init). My2Cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Doing away with multi-threading in my project (netman)
On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote: > Quote: < process (that's done via fork and not via execve) and it's not adopted > by the grand parent but by init.>> > > So what is the difference between an "orphaned process", i.e. a > process whose parent has exited after giving birth to a child process > and one which replaces the original process effectively giving its > parent a death sentence? ??? I think there is here some confusion about process creation. Upon a fork() the process calling it (the parent) is effectively *copyed* into a new process (the child). The child is an (almost, up to few details) *exact* copy of the parent, including the program page (the code). Hence, by calling execve in the child you are not "giving its parent a death sentence" but you are simply replacing the progam page (the code) of the child process. The parent is unaffected by such a call, because it does not occur in its process space. I warmly suggest you to have a look to something like "The Linux Programming Interface": http://man7.org/tlpi/ Incidentally, the pdf of the chapter related to process creation is available for download: http://man7.org/tlpi/download/TLPI-24-Process_Creation.pdf My2cents KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
When I read jude's documentation it states "It also ships with a "libudev-compat" library that is ABI-compatible with libudev 219." My system is libudev 224, does this mean it isn't ABI-compatible anymore? if so how to handle? On 2015-09-05 21:49, shraptor wrote: I also forgot to say that on my upgraded system with vdev and arch version of xf86-input-evdev touchpad gets detected and loaded that I believe is fascilitated by evdev and libudev-compat?? best regards Scooby On 2015-09-05 21:40, shraptor wrote: Just to be clear my system before upgrade was using vdev in conjunction with xf86-input-evdev and working fine. I did not recompile that version of evdev and it just worked with libudev-compat. When I upgraded to new version of both( and new kernel) keyboard stopped working( though could be brought to life with static conf in xorg.conf.d). I thought maybe arch had done something to break functionality here. It could also be some regression in vdev and I will speak to jude about that after September 12 when he's got more time. @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. Isaac I know about your package and have checked it out before but didn't fully understand it. What is triggering evdev in your case? a file in xorg.conf.d? I am gonna try your solution with libsysdev and sysdev branch of xf86-input-evdev. Although it would easier( for me that is) if the arch version just worked with vdev. I love that you give full explanation, thanks best regards Scooby On 2015-09-05 20:36, Isaac Dunham wrote: On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: On arch linux xf86-input-evdev is reported to have a dependency on systemd. I thought the dependency is on udev and that is usually reported on arch like systemd(udev). I downloaded xf86-input-evdev for recompilation but could not find any switches to compile without systemd though some evidence pointing at a udev dependency was there. Does anyone know? Long explanation here. xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's hotplug support, which depends on libudev (or an API-compatible replacement such as libudev-compat or libeudev...); at least in theory, you can also use it as a pre-configured device driver. The hotplug path will load evdev for *all* input devices that are hotplugged--power buttons included. So, evdev needs to check if a device is "virtual". This is a simple matter of checking that the canonical path in sysfs contains the string "LNXSYSTM". Getting that canonical path is the hard part, since you receive a device path instead of anything pointing into sysfs. This can be done more-or-less by getting the device major and minor via stat(), checking that it's a char device, then identifying the corresponding link in /sys/dev/ - this would be the string returned by: sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor) and then use readlink() to check where it points; the result is the canonical path. However, most people prefer to avoid depending on the sysfs layout even where its behavior is documented; libudev provides a thin veneer to hide it. So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do this. There is no dependency on udev being running. I've redone that function without udev but using my own library libsysdev, which I mentioned earlier this summer. Repositories that you'd need to build that: -https://github.com/idunham/libsysdev -https://github.com/idunham/xf86-input-evdev (branch sysdev) But that does require something that has no Debian packaging yet. There are also two other options: - comment out that function and disable device hotplug in Xorg.conf or xorg.conf.d - replace the function with one that does all the work itself. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Dng Digest, Vol 12, Issue 17
.pc files are quilt patches applied. Aaitor. El 05/09/15 a las 21:52, dng-requ...@lists.dyne.org escribió: @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Subject: Re: xf86-input-evdev
Hi shraptor, .pc file includes theapplied quilt patches. Aitor. El 05/09/15 a las 21:52, shraptor escribió: @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xf86-input-evdev
Problem solved when I changed so names from libudev.so libudev.so.1 -> libudev.so.1.0.1 libudev.so.1.0.1 -> libudev.so.1.5.1 libudev.so.1.5.1 -> libudev.so.1.6.0 libudev.so.1.6.0 -> libudev.so.1.6.4 libudev.so.1.6.4 -> libudev.so to libudev.so libudev.so.1 -> libudev.so.1.0.1 libudev.so.1.0.1 -> libudev.so.1.5.1 libudev.so.1.5.1 -> libudev.so.1.5.2 libudev.so.1.5.2 -> libudev.so.1.6.0 libudev.so.1.6.0 -> libudev.so.1.6.4 libudev.so.1.6.4 -> libudev.so though for original libudev from arch has libudev.so -> libudev.so.1.6.4 libudev.so.1 -> libudev.so.1.6.4 libudev.so.1.6.4 and that doesn't work for me Anyone can clear up naming conventions of so-names? Maybe correct should be libudev.so -> libudev.so.1 libudev.so.1 -> libudev.so.1.0.1 libudev.so.1.0.1 -> libudev.so.1.5.1 libudev.so.1.5.1 -> libudev.so.1.5.2 libudev.so.1.5.2 -> libudev.so.1.6.0 libudev.so.1.6.0 -> libudev.so.1.6.4 libudev.so.1.6.4 will try if that works now best regards Scooby On 2015-09-05 22:57, shraptor wrote: When I read jude's documentation it states "It also ships with a "libudev-compat" library that is ABI-compatible with libudev 219." My system is libudev 224, does this mean it isn't ABI-compatible anymore? if so how to handle? On 2015-09-05 21:49, shraptor wrote: I also forgot to say that on my upgraded system with vdev and arch version of xf86-input-evdev touchpad gets detected and loaded that I believe is fascilitated by evdev and libudev-compat?? best regards Scooby On 2015-09-05 21:40, shraptor wrote: Just to be clear my system before upgrade was using vdev in conjunction with xf86-input-evdev and working fine. I did not recompile that version of evdev and it just worked with libudev-compat. When I upgraded to new version of both( and new kernel) keyboard stopped working( though could be brought to life with static conf in xorg.conf.d). I thought maybe arch had done something to break functionality here. It could also be some regression in vdev and I will speak to jude about that after September 12 when he's got more time. @Jack Frost I do not understand the use of .pc files although I have seen them around. I am using your systemd-dummy package though to avoid pulling in real systemd, Thanks for that. Isaac I know about your package and have checked it out before but didn't fully understand it. What is triggering evdev in your case? a file in xorg.conf.d? I am gonna try your solution with libsysdev and sysdev branch of xf86-input-evdev. Although it would easier( for me that is) if the arch version just worked with vdev. I love that you give full explanation, thanks best regards Scooby On 2015-09-05 20:36, Isaac Dunham wrote: On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote: On arch linux xf86-input-evdev is reported to have a dependency on systemd. I thought the dependency is on udev and that is usually reported on arch like systemd(udev). I downloaded xf86-input-evdev for recompilation but could not find any switches to compile without systemd though some evidence pointing at a udev dependency was there. Does anyone know? Long explanation here. xf86-input-evdev, as shipped by upstream, is intended to be loaded by Xorg's hotplug support, which depends on libudev (or an API-compatible replacement such as libudev-compat or libeudev...); at least in theory, you can also use it as a pre-configured device driver. The hotplug path will load evdev for *all* input devices that are hotplugged--power buttons included. So, evdev needs to check if a device is "virtual". This is a simple matter of checking that the canonical path in sysfs contains the string "LNXSYSTM". Getting that canonical path is the hard part, since you receive a device path instead of anything pointing into sysfs. This can be done more-or-less by getting the device major and minor via stat(), checking that it's a char device, then identifying the corresponding link in /sys/dev/ - this would be the string returned by: sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor) and then use readlink() to check where it points; the result is the canonical path. However, most people prefer to avoid depending on the sysfs layout even where its behavior is documented; libudev provides a thin veneer to hide it. So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to do this. There is no dependency on udev being running. I've redone that function without udev but using my own library libsysdev, which I mentioned earlier this summer. Repositories that you'd need to build that: -https://github.com/idunham/libsysdev -https://github.com/idunham/xf86-input-evdev (branch sysdev) But that does require something that has no Debian packaging yet. There are also two other options: - comment out that function and disable device hotplug in Xorg.conf or xorg.conf.d - replace the function with one that does all the work itself. HTH, Isaac Dunham ___
Re: [DNG] Doing away with multi-threading in my project (netman)
On Sat, Sep 05, 2015 at 08:52:39PM +0100, Edward Bartolo wrote: > Quote: < process (that's done via fork and not via execve) and it's not adopted > by the grand parent but by init.>> > > So what is the difference between an "orphaned process", i.e. a > process whose parent has exited after giving birth to a child process > and one which replaces the original process effectively giving its > parent a death sentence? > > Sorry, but it looks there is only a very subtle difference between the > two. The only difference I see, is that, since in the case of execl, > the parent effectively is replaced, i.e. dies, it is also awarded its > parent PID. This is not the case when a parent process creates a child > process and exits immediately, as the child will have a different PID. A program that runs via execlp()--or any of the exec*() functions-- *is* the process that called execlp(). It does not kill the *process*, though it effectively ends the *program*. As a result, it has the same parent as the previous program. (This is why you can run "exec killall forkbomb" to kill a forkbomb, at the expense of one shell.) To create a *new* process, you use fork(), vfork(), posix_spawn(), popen(), or system(). In C, system() is the recommended, portable way to run programs; it forks, execs "sh -c COMMAND", waits, and returns the exit status. popen() is the recommended approach if you want to use a stream. It creates a pipe, forks, and runs "sh -c COMMAND" in the child. The parent then returns a FILE pointer to the stream. Once you have done the desired IO on the stream, you can call pclose(), which will take care of closing the pipe, waiting for the child, and finally return the child status. If you want to avoid zombies simply, just use popen() and pclose(). HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
