davem@eastcoast.co.za wrote:
> Summary:
> I'm trying to write a trivial pseudo device driver for learning 
> purposes. I'll progress to something more serious at a later stage.
> My driver is called mypseudo.
> 
> Do I need a mypseudo_softc or don't I? Some drivers seem to have 
> them and others dont. Is it lake taking sugar in your 
> coffee?:-) or is there a deeper reason that some do and some dont?

Basically, if you have more than 1 instance of the device, you're going to
need a softc structure.  Even if you're not going to have one, it might
still be a good idea.
 
> Also, my (limited) understanding is that it should look like:
> 
> struct pseudo_softc {
>     struct device sc_dev;
>     /*Other stuff here*/
> }

This is correct.

> and yet (for e.g.), I see in arch/x68k/dev/kbd.c
> 
> struct kbd_softc {
> 	int k_event_mode; /* if true, collect events, else pass to ite */
> 	struct evvar k_events; /* event queue state */
> } kbd_softc;
> 
> i.e. the first field is not a "struct device".

I'd assume that in this case, they only have 1 instance of the device, and
they're not actually using the softc the way you should use it.  Also,
they probably have a copy of a struct device floating around somewhere
else, since you have to have a struct device in order to go through the
autoconfiguration process.

> At this stage, I'm quite happy for there to be only one instance of 
> the driver (no. of drivers seem to have something to do with it). If I 
> could just get it compiled into the Kernel and be able to enter it 
> appropriately, I'd be a happy man! (well for a day or so anyway:-)

basically, a softc structure is a data structure that is stored in a known
location in the device tree and contains the state your driver needs to
function.  i guess you could just use global variables (or even static
ones inside a single file), but if you ever needed more than 1 instance of
the device, then 2 or more of them could stomp on each other's internal
state.  rather nasty :-)

so, figure out what kind of state your device is going to need, put it in
a softc structure, and put that structure and any constants it needs in a
header file (usually <device>var.h).  if you're attaching to a bus
(instead of being a psuedo-device), you might also need some kind of
attach_args structure to carry match/probe data around, but you can worry
about that later.

anyway, you also need to remember to create a cfattach structure which has
enough room for your softc and pointers to your match/probe and attach
functions.  of course, a psuedo-device might not need a cfattach struture.

i'd suggest looking at some other drivers, specifically ones that are
meant to handle multiple instances.  most people recommend looking at the
driver that handles /dev/mem and /dev/kmem (i think it's the
machine-dependent mem driver), although it doesn't appear to actually
carry around any state.  take a look at sys/conf/files for a mapping
between devices and the actual files which implement them.

i hope this helps a little.

later.

colin