Re: [lcd4linux] exec() question

[Lars S. <st...@te...>]

Michael Reinelt wrote:
> Hi Lars,
>=20
>>>>Does anyone know if you can get the exec() to execute
>>>>once only instead of doing repeated executions?
>=20
>>>But why the heck would one want to execute things only once???
>=20
>>I'm working on a software RAID-1 solution with three S-ATA disks.
>>One of these disks will be used as backup, i.e push the button
>>(CF635), take out the disk, put another disk in, push another
>>button, and voil=E1, you have a complete (and bootable) backup
>>of your system on a separate disk, whilest the new disk is now
>>being resynced. All with a running system (hotswap, no reboot).
>=20
> Hey, this sounds cool! I will get a new server for my company this week
> (a dual-core, so some of the SMP questions with lcd4linux will be
> answered :-), and I'm planning to do something similar, but with two
> harddisks only. So I'm a bit curious: how do you boot from and swap to
> such a mirrored disk?

I set up the partitions as follows:

/dev/md0 /boot 100 MB
/dev/md1 /       1 GB
/dev/md2 swap  900 MB
/dev/md3 LVM   the rest

Then I use LILO with the raid-extra-boot option to get all
three disks bootable, i.e. even if one or even two disks
fail, the system can boot on the remainding disk. This,
of course, works just fine with two disks as well.

I've done this on SuSE Linux Pro 9.3 and Fedora Core 4
using the installation and partitioning tools available
on each platform. In all honesty, I tend to use the automatic
network installation feature of each distro (autoyast for
SuSE and kickstart for fedora). This is due to the fact
that I do a lot of testing, and need to "reset" the machines
to a well known state now and again.

Let me know if you need more specifics.

>>I checked the mailinglist and couldn't find any plugin for
>>/proc/mdstat, which I need in order to monitor the RAID.
>>So I guess I'll have to write a plugin for /proc/mdstat.
> This would be very very welcome :-) especially because I've got some
> raid arrays up and running here (almost 1 TB for VDR :-)
>=20
>>However, for prototyping I find the exec() function splendid.
>>With the help of the exec() function and a simple shell-script,
>>I have a running system where the CF635 display shows the
>>RAID status. I even took care of stopping the underlying processes
>>using a modified init.d script for start/stop of lcd4unix.
>>So, in all fairness, it works well for me at least.
>=20
> I've been thinking a bit about your issue. The problem with the exec()
> plugin is that for timing reasons it's async by default. As a side
> effect, the first call to exec() will never return a senseful result
> (because the exec thread just forked off).
>=20
> I see two solutions: modify the exec() plugin so it's thread terminates
> after the first execution, but in this case you won't get a return
> value. another way would be to force the exec() to be synchronous,
> meaning not to fork. Maybe this could be implemented by using a negativ=
e
> update parameter (while a update value of zero would mean a "one shot" =
exec.

I haven't read all the code, but I tried the first idea (I think)
by modifying exec_thread() a tad bit at the end of the "while (1)"
forever loop:

   if (Thread->delay =3D=3D -1)
     return;
   else
     usleep(Thread->delay);

And that worked fine, but only once, i.e. second time I pressed
the key, there was no exec() happening. I could see that the CF
driver noted the keys being pressed, but the exec() didn't show up.
I obviously need to get rid of the thread being executed in order
to allow for the next one to be created (or something like that).
I have a feeling that I should terminate the thread properly
as opposed to the above experiment. I guess I could do a
destroy_exec_thread() instead of the empty return, but at that
place in the code, I don't have the index that destroy_exec_thread()
requires. But if I put the following in there:

static void terminate_this_exec_thread(void *data)
{
   EXEC_THREAD *Thread =3D (EXEC_THREAD *) data;

   if (Thread->mutex !=3D 0)
     mutex_destroy(Thread->mutex);
   if (Thread->cmd)
     free(Thread->cmd);
   if (Thread->key)
     free(Thread->key);
   if (Thread->ret)
     shm_destroy(Thread->shmid, Thread->ret);

   Thread->delay =3D 0;
   Thread->mutex =3D 0;
   Thread->pid =3D 0;
   Thread->shmid =3D 0;
   Thread->cmd =3D NULL;
   Thread->key =3D NULL;
   Thread->ret =3D NULL;
}

And then call terminate_this_exec_thread() if (Thread->delay =3D=3D -1)
at the end of the forever loop.

What do you think?

>>I also got the CF635 keypad working allright, thanks to
>>Chris's patch for this the other week. However, I'm not
>>sure how to execute a command (once!) using the keypad.
>>Maybe there is another way that I don't know of?
>>If not, I guess I'll have to look in to the code.
> just curious again: What's chris's patch? (you are using CVS code, ain'=
t
> you?)

Well, I just ment that I saw on the mailing lists that a guy called
Chris (I think) had done some work on the CF635 code.

And yes, I'm using the CVS code (the released code does not contain
the CF635 driver).

> As I'm very very very busy with my real-life job at the moment, and my
> son (who is six months old now! funny how time flies....) eats up the
> rest of my spare time, I'm afraid I can't be of much help, especially
> with coding.

That's OK, I can do the coding, as long as you just give me some
advice (see above).

> If you feel familiar enough with coding for lcd4linux and patching the
> repository, I could give you CVS developer access.

Well, why not, I really need the keypad functionality for the RAID
setup. Also, I guess I'll write a plugin for /proc/mdstat as well
at some point.

Thanks
/LarS