[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Rumpification (was Re: CVS commit: src/usr.sbin/envstat)
On Tue Dec 14 2010 at 20:27:53 +0200, Jukka Ruohonen wrote:
> On Tue, Dec 14, 2010 at 08:07:27PM +0200, Antti Kantee wrote:
> > I'd love to. To establish some common ground, can you familiarize
> > yourself with the material I've written, starting from
> > http://www.netbsd.org/docs/rump/
> This is all dandy. But how does this all fit together from a perspective of
> normal userland programming?
> For instance, if I have to modify a program X in /sbin, what system calls
> should go through rump? All those in <rump/rump_syscall.h>? If not all,
> how do I make the distinction? Why 'ping.c' now contains prog_setsockopt()
> but not prog_gettimeofday()?
Ping is a network program, and even more extremely it's a network program
used for icmp echo, not e.g. dns queries. The logic pretty much falls
out of that.
> Will I now break something if I accidentally
> use normal system calls instead?
This was already answered in the thread.
> If I want to write a new program, should I
> always use these prog_*() wrappers?
It depends on the program. If you're writing e.g. "echo" or "sleep"
there's no sense but if you're writing a counterpart for a kernel driver,
you might be more inclined. It also might make sense to develop the
kernel driver in conjunction/with the help of the userland util.
> What practices should I follow with the
> prog_ops structure? Should prog_init() be always called? What should I put
> in Makefiles?
Usual best practices are to copypaste.
> I know very well how to write normal UNIX programs and I've done something
> with rump(3) too, but breaking decades old practices always induces a
> whole lot of practical questions.
Sure. However, if you compare a really old util and one freshly written,
you'll see a lot of evolution and old practises are not necessarily
desirable anymore, cf. what Thor said about ifconfig.
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Main Index |
Thread Index |