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)
briefly over it, and see some serious architectural issues in this stuff.
On the other hand, I doubt that we will have any solution to these issues
before 2.1, so we might as well leave this in.
Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much
in the normal case.
Reviewed by: phk
Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
the APM-bios.
This stabilizes a couple of APM bioses quite a bit.
They all make the mistake of going into 16-bit mode, without clearing the
top half of the 32bit registers.
Later they do a
| movw %si,$0x7331
| movw %ax,0x6(%si)
or something along those lines and crash and burn, because their segment
is already relocated, so adding 0xf0171ce9 to the base of it is bad news.
At least SystemSoft is guilty of this bummer.
