I suppose you've checked inside Documentation/PCI/ inside the kernel source code?

My understanding of them is far from perfect, mostly limited to editing in extra PCI ID's when manufacturers do shell games me. I don't perfectly understand the internal details, and if I ever did my knowledge would go obsolete in weeks. ;p But I've done a lot of programming making/using/fixing plugin libraries, which makes a lot of what I see in device drivers look familiar.

Imagine a plugin for a media player -- maybe a software visualizer of some sort. The plugin would look like this:

Code:

// these names don't get exported in the library.  They're local-only.
static int visualizer_open(void) { return(0); }
static int visualizer_close(void) { return(0); }
static int visualizer_handledata(void *data, int len)
{
        fprintf(stderr, "%d bytes at %p\n", len, data);
        show_music_on_screen_in_amusing_manner(data, len);
        return(0);
}

struct function
{
        char *formats_supported[4];
        int (*open)(void);
        int (*close)(void);
        int (*handledata)(void *data, int len);
} functions={
       { "wav", "mp3", "ogg", NULL },
       visualizer_open, visualizer_close, visualizer_handledata
};

// This function IS exported.
struct function *get_callbacks(void)  {        return(&functions); }

To use it, the media player opens the library, looks up get_callbacks and calls it.

Code:

struct function
{
        char *formats_supported[4];
        int (*open)(void);
        int (*close)(void);
        int (*handledata)(void *data, int len);
} *functions;

void *lib=dlopen("crazylinesvisualizer.so", RTLD_NOW);
void *(*getcallback)=dlsym(lib, "get_callbacks");
dlclose(lib);

functions=getcallback();

if(strcmp(functions->formats_supported[0], "wav") != 0)
{
        fprintf(stderr, "visualizer doesn't support wav");
        exit(1);
}

functions->open();
whle(music) functions->handledata(data, len);
functions->close();

Bundling them in a structure like that makes it more efficient -- one load operation instead of one for each function -- and more organized.

Kernel device drivers work just like this. Look in a device driver for a character device and you'll find a big structure containing pointers the driver's own personal open(), close(), read(), write(), ioctl(), mmap(), kitchen_sink(), and other such functions which get called whenever a user calls open, read, write, ioctl, mmap, etc. on that device file in userspace. Even when you build drivers in, they're still in a great big table. That's how the kernel finds them, how the kernel decides what order to initialize them, and how it decides which to use for what PCI id. I don't think the driver "announces" it, it just keeps a list in that big structure. The kernel checks if it matches any present devices and, if not, doesn't bother initializing it.

Non-PNP things might have to do manual probing to see if a device exists.