I am looking at trying to update an import (zaptel-netbsd) from FreeBSD, and
I am not understanding some of the code in it.  Looking around, I find that
I am completely stumped on a significant aspect of how drivers are supposed
to work.

In general, looking through the system, I find a number of drivers with
functions with names like foo_open, foo_read, and foo_close.  In some
cases, foo_read takes a 'struct file *' as its first argument; in some,
it takes the device's softc.  I don't know why!

For instance, rnd.c's rndread is:

int rndread(dev_t dev, struct uio *uio, int ioflag);

The only example I see in /dev/*/*.c of the other form is dmover_io, which
seems a bit odd.

Looking at the code in an older port of zaptel-bsd to NetBSD, I see:

	dev_type_open(ztopen);
	const struct cdevsw zaptel_cdevsw = {
		ztopen, noclose, noread, nowrite, noioctl, nostop, notty,
		nopoll, nommap, nokqfilter, 0
	};

Then, moments later:

	static struct fileops zt_fileops = {
		.fo_close = zt_close,
		.fo_ioctl = zt_ioctl,
	#ifdef __NetBSD__
		.fo_fcntl = zt_fcntl,
	#endif
		.fo_read = zt_read,
		.fo_write = zt_write,
		.fo_poll =  zt_poll,
		.fo_stat = zt_stat,
	#ifndef __NetBSD__
		.fo_kqfilter = zt_kqfilter
	#endif
	};

I don't think I understand this.  What are the circumstances under which one
would fill in 'file *' objects with fileops structures, instead of a cdevsw?

I'm sorry to bug the list with what I'm pretty sure is a newbie question, but
a bit of poking about in man pages has not suggested anything to me.
There's some talk of creating a cdevsw interface (which looks right).

My vague theory is that, if functions matching the cdevsw prototypes were
created and put into the cdevsw structure, it would not be necessary to
allocate a file and fill it with file ops, because the device would somehow
magically know to use its cdevsw operations.  But someone who has done this
successfully (and therefore, who presumably understands it better than I do)
thought it was better to do it the other way...

-s