🚀 go-pugleaf

Pieter <pierreviGEENSPAM@yucom.be> wrote:
> Philip Paeps wrote:
> > Pieter <pierreviGEENSPAM@yucom.be> wrote:
> > > Het probleem is dat alles wel lukt maar eigenlijk niet goed, zo
> > > moet je bv wachten tot alle LED's 5 maal geknipperd hebben voor je
> > > een nieuw commando kan uitvoeren.
> > 
> > (nb: ik heb je code nog niet gelezen)
> > Kan het dat je i/o blockt?  Misschien O_NONBLOCK eens onderzoeken,
> > of dat je probleem niet oplost.
> 
> Nee dat is het niet, ik, de lichtjes knipperen wel enz. maar vanaf dat
> ik terug een commando naar de server zou zenden moeten deze direct
> stoppen

Makkelijkst - imho - zou zijn om de led-handel gewoon in de kernel te
implementeren met een queue en een timer.  In userspace hang je dan een
daemon non-blocking aan een cdev (of je gebruikt een /proc node).  De
daemon luistert naar commands over het netwerk en stuurt ze op een kalme
manier naar de driver, die volledige controle heeft over de hardware.

In de daemon kan je dan een beetje magie implementeren zodat een write
van '0' de leds onmiddellijk het zwijgen oplegt, en een write van '1' ze
onmiddellijk aansteekt, en al wat ertussen zit 'speciallekes' doet.

> > > Ik denk dat ik dat moet oplossen door gebruik te maken van
> > > pthread.h maar ik vind niet echt de nederlandstalige info die ik
> > > zoek.
> > 
> > Threading is ��n optie.  Je kunt ook children forken, dat is vaak
> > een stuk eenvoudiger.  Met threads wordt alles heel snel heel
> > complex :-)
> 
> Naar ik dacht moet je een daemon van bij het begin al forken maar hoe
> zorg ik ervoor dat er nog eens geforked wordt en dat men lichtjes dan
> beginnen knipperen? en dat ze ook weer kunnen stoppen vanaf dat er een
> commando van de client komt

Je mag forken wanneer je wil.

Ik zou forken als er een connectie binnenkomt, en de connectie door een
child laten behandelen.  De commands queue je dan in de parent en verder
door naar de hardware.

> > > En ik zou ook graag hebben dat mijn server alleen maar luistert
> > > naar localhost of naar de server van mijn webspace.
> > 
> > Vermoedelijk bind(2) je op INADDR_ANY.  Veranderen naar localhost is
> > geen probleem (s_addr aanpassen), het tweede adres moet je op ��n of
> > andere reden aan je programma wijsmaken.  Afhankelijk van hoe je dat
> > wil doen, kan het makkelijk of eenvoudig :-)
> 
> En hoe is de gemakkelijk weg?

Op BSD systemen heb je een getifaddrs(3) call die je een linked list
geeft van alle interfaces in je machines en hun adressen.  Die lijst kan
je afwandelen tot je een *ifa_name tegenkomt die overeenkomt met de
interface waarop je wilt luisteren.  De ifa_addr van die member is een
struct sockaddr die je aan bind(2) kunt geven.

Ik ben niet zeker of Linux die functie ondertussen kent, if not, ga je
er een beetje rond moeten hacken door bijvoorbeeld een udp socket te
openen en er in een lusje SIOCGIFCONF over te ioctl'en.  Maar er moet
een makkelijkere manier zijn :-)

 - Philip

-- 
Philip Paeps                              Please don't email any replies
                                              I follow the newsgroup.

   I have not lost my mind, it is backed up on tape somewhere.