On some laptops, this doesn't work (ie; IBM 75x series), so force it
to power on.
With this modification, I am able to read the tuples off 4 different
PCMCIA cards on my ThinkPad.
Reviewed by: phk@FreeBSD.org
Obtained from: if_zp.c
most devsw referenced functions are now static, as they are
in the same file as their devsw structure. I've also added DEVFS
support for nearly every device in the system, however
many of the devices have 'incorrect' names under DEVFS
because I couldn't quickly work out the correct naming conventions.
(but devfs won't be coming on line for a month or so anyhow so that doesn't
matter)
If you "OWN" a device which would normally have an entry in /dev
then search for the devfs_add_devsw() entries and munge to make them right..
check out similar devices to see what I might have done in them in you
can't see what's going on..
for a laugh compare conf.c conf.h defore and after... :)
I have not doen DEVFS entries for any DISKSLICE devices yet as that will be
a much more complicated job.. (pass 5 :)
pass 4 will be to make the devsw tables of type (cdevsw * )
rather than (cdevsw)
seems to work here..
complaints to the usual places.. :)
That's EVERY SINGLE driver that has an entry in conf.c..
my next trick will be to define cdevsw[] and bdevsw[]
as empty arrays and remove all those DAMNED defines as well..
Each of these drivers has a SYSINIT linker set entry
that comes in very early.. and asks teh driver to add it's own
entry to the two devsw[] tables.
some slight reworking of the commits from yesterday (added the SYSINIT
stuff and some usually wrong but token DEVFS entries to all these
devices.
BTW does anyone know where the 'ata' entries in conf.c actually reside?
seems we don't actually have a 'ataopen() etc...
If you want to add a new device in conf.c
please make sure I know
so I can keep it up to date too..
as before, this is all dependent on #if defined(JREMOD)
(and #ifdef DEVFS in parts)
from a string to an identifier so that it can be used to generate
declarations and strings. It's much easier to stringize an identifier
than to identifize a string. A uniform naming scheme must be used
for the automatically generated things to apply. This is a feature.
Used the module identifer to generate prototypes for the module load,
unload and stat functions. Removed the few prototypes for these that
already existed.
Used the module identifier to generate a unique struct tag in MOD_DEV().
This should probably be done for all the MOD_*() macros.
Moved the trailing semicolon from the MOD_*() macro definitions to the
macro invocations that didn't already (bogusly) have it.
Staticized the module load and unload functions.
Added function return types for the module load, unload and stat functions.
lkm/ibcs2/ibcs2.c:
Included <sys/sysproto.h> to get everything prototyped.
Cleaned up #includes.
lkm/ibcs2/ipfw.c:
Cleaned up #includes.
lkm/linux/linux.c:
The module name had to change from "linux_emulator" to "linux_mod" to
be automatically generated.
Cleaned up #includes.
lkm/syscons/*/*_saver.c:
Completed delcarations of function pointers.
sys/i386/isa/atapi.c:
The module name had to change from "atapi" to "atapi_mod" to be
automatically generated.
sys/i386/isa/wcd.c:
Used the fixed MOD_DEV(). This module has two devices and expanded the
macro in the source instead of fixing it.
The module names had to change from "wcd" and "rwcd" to "wcd_mod" and
"rwcd_mod" to be automatically generated.
sys/pccard/pcic.c:
The module name had to change from "pcic" to "pcic_mod" to be
automatically generated.
to <machine/conf.h>. conf.h was mechanically generated by
`grep ^d_ conf.c >conf.h'. This accounts for part of its ugliness. The
prototypes should be moved back to the driver sources when the functions
are staticalized.
This is still very green, but I have managed to get my modem working.
Lots of work still to do, but now at least we can commit it. /phk
Reviewed by: phk
Submitted by: Andrew McRae <andrew@mega.com.au>
