1

I have written a daemon in linux for doing dhcp for an embedded system. This platform only has a linux kernel running on it and have no CLI support. What is the best way for me to test my daemon? How do I write a program that will call the main function in this daemon and verify if its working fine?

Appreciate the answers.

Ullas
  • 33
  • 5
  • 1
    @Ignacio It's not entirely unheard of (well, at least, I've done it too) to have an embedded system that's relying on the Linux kernel and glibc or ulibc and other related libraries, but has no shell on it whatsoever. Mine didn't even have a standard init -- we wrote our own. We did, however, use other utilities as needed rather than writing our own. In this situation, for example, we'd have used an existing dhcpcd. – Michael Scott Shappe Jul 28 '10 at 21:26

2 Answers2

4

When I've been in a situation like this, I've written a second daemon (or had a second listener in the existing daemon) to take the place of a CLI, listening at a particular port and responding to a very limited command set of your own choosing.

In this case, all you really care about is triggering the function on demand, so you could even have it trigger when you connect to this second port, and then report results back to the socket.

I strongly recommend, by the way, making sure your embedded system has some more generic mechanism for logging information to persistent storage and retrieving that log. It doesn't have to be syslog or anything so complicated. But you will want that ability in the future to enable forensic analysis of problems in the field.

Michael Scott Shappe
  • 360
  • 1
  • 4
  • 1
    Thanks for that answer. I liked the idea of having a second listener. I will try to have a second listener responding to basic commands from a particular port and then get the results through that. – Ullas Jul 28 '10 at 21:57
  • Amen to the logging! Given that you've already got an IP stack running, implementing the syslog protocol to export log records isn't very complicated. – bstpierre Jul 29 '10 at 02:06
  • Yes, logging is certainly high on my TODO list. I will complete that first and then work on adding the second listener. Thanks for all suggestions – Ullas Jul 29 '10 at 12:50
0

You will want to write and debug your daemon in a full featured environment first, then install it on the embedded system at the end when you are sure it works properly.

If you can build a dhcp server for the embedded system you can surely build a simple shell for it also. Try building BusyBox or ash or dash.

You could also try using GDB remote debugging. I found an article about it.

Zan Lynx
  • 53,022
  • 10
  • 79
  • 131
  • Frankly, I am not really trying to debug my daemon(I know it works on a general platform). I would like to know how it works in this particular platform and thats precisely why it becomes important to have control over this daemon on the system so that I can test other network communications of the hardware. Appreciate the suggestion though. Yes, at some point I will go and write a shell for it but was looking at some easier methods for some quick test. – Ullas Jul 28 '10 at 22:04
  • You hardly need to *write* a shell. There are literally hundreds already written to choose from! – Zan Lynx Jul 28 '10 at 22:25