Thread: [lcd4linux] exec() question

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Does anyone know if you can get the exec() to execute
once only instead of doing repeated executions?

R
/LarS

Hi Lars,

> Does anyone know if you can get the exec() to execute
> once only instead of doing repeated executions?

I'm afraid this is *not* possible at the moment. But this could be
easily implemented by using a 'update' value (or whatever the attribute
is called today :-) of 0 (zero).

But why the heck would one want to execute things only once???

bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

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
> I'm afraid this is *not* possible at the moment. But this could be
> easily implemented by using a 'update' value (or whatever the attribute
> is called today :-) of 0 (zero).
>=20
> But why the heck would one want to execute things only once???

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).

I'm new to lcd4linux since a couple of days back, and I just
have to say: great piece of software, well done! Just bought
myself a CF635 display, and with lcd4linux I got it up and
running in no time.

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.
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.

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.

Thank you for your comments.

R
/LarS

Hi Lars,

>>> Does anyone know if you can get the exec() to execute
>>> once only instead of doing repeated executions?

>> But why the heck would one want to execute things only once???

> 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).

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 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 :-)

> 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.

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).

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 negative
update parameter (while a update value of zero would mean a "one shot" ex=
ec.

> 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?)

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.

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

bye, Michael

--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

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

On Mon, Mar 20, 2006 at 08:35:31PM +0100, Michael Reinelt waxed:
> > 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?)

I submitted a couple recently into CVS, and I've still got
commit privileges so I will be submitting more.  Watch out :)

One was the keypad button handling code on the CF635.

Another was the file reading application which will display
text file contents from a specified line number, updating
at the chosen interval.  This line number can be a variable,
and you could use the buttons on the keypad to change it's
value.

Both patches are documented on the wiki.

--Chris

Thread: [lcd4linux] exec() question

lcd4linux-users