Re: Rumpification (was Re: CVS commit: src/usr.sbin/envstat)

[Antti Kantee <pooka%netbsd.org@localhost>]

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