<sys/ioctl_compat.h> and sometimes <sys/filio.h> instead of
<sys/ioctl.h> in tty-related files. <sys/ttycom.h> is still
usually imported bogusly via <sys/termios.h>.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
for work regardless of whether there was an interrupt. This needs more
work, it should be able to run better when there are more than 3 host
cards present, ie: all cards in polling-only mode with no IRQ. (The
host cards have a choice of 3 irq's, 11, 12, or 15, or just polling)
blocked in a write() while waiting for the output to drain, sleep only
for tp->t_timeout, not forever. This only seems to happen when there is
either a modem lockup holding the hardware flow control down, or due to
some problem in the driver with processes attempting to write after the
modem has hung up (eg: elm, tf).
things tend to work better if you write the settings to the correct
register.. (*blush*). This subtle bug has been haunting me for ages, and
will solve a few problems that have been reported to me.
Also, take a shot at fixing the serial BREAK processing, what was there
before never really worked. (There is a PR on this I think)
on the baud rate, dont get upset if it's been hung up by setting B0.
Instead, sleep for a short time, as the host controller takes a while
to go through the state changes.
it empties all of the 256 byte incoming fifo, as it can spend more time
processing one port than intended, especially if data is streaming in
at 115.2K. The port fifo will be emptied and dumped into the tty system
and left until next time. I've been running this for quite some time on
one of my systems here.
Also, if the tty layer is blocked or full it lets the hardware assert the
flow control rather than loosing the data.
enough nodes for the number of ports on the last module, not the number
of ports _total_ that the driver is managing...
Submitted by: Robert Sanders <rsanders@mindspring.com>
device must be configured. It's hard to tell whether a reset function
should be noreset or nullreset since reset functions are never called.
Most drivers use nullreset but noreset has the advantage of complaining
if somehow gets called).
Removed old aliases d_rdwr_t and d_ttycv_t for d_read_t/d_write_t and
d_devtotty_t.
Sorted declarations of switch functions into switch order.
Removed duplicated comments and declarations of nonexistent switch
functions.
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)
totally dynamic.
this is only the devices in i386/isa
I'll do more tomorrow.
they're completely masked by #ifdef JREMOD at this stage...
the eventual aim is that every driver will do a SYSINIT
at startup BEFORE the probes, which will effectively
link it into the devsw tables etc.
If I'd thought about it more I'd have put that in in this set (damn)
The ioconf lines generated by config will also end up in the
device's own scope as well, so ioconf.c will eventually be gutted
the SYSINIT call to the driver will include a phase where the
driver links it's ioconf line into a chain of such. when this phase is done
then the user can modify them with the boot: -c
config menu if he wants, just like now..
config will put the config lines out in the .h file
(e.g. in aha.h will be the addresses for the aha driver to look.)
as I said this is a very small first step..
the aim of THIS set of edits is to not have to edit conf.c at all when
adding a new device.. the tabe will be a simple skeleton..
when this is done, it will allow other changes to be made,
all teh time still having a fully working kernel tree,
but the logical outcome is the complete REMOVAL of the devsw tables.
By the end of this, linked in drivers will be exactly the same as
run-time loaded drivers, except they JUST HAPPEN to already be linked
and present at startup..
the SYSINIT calls will be the equivalent of the "init" call
made to a newly loaded driver in every respect.
For this edit,
each of the files has the following code inserted into it:
obviously, tailored to suit..
----------------------somewhere at the top:
#ifdef JREMOD
#include <sys/conf.h>
#define CDEV_MAJOR 13
#define BDEV_MAJOR 4
static void sd_devsw_install();
#endif /*JREMOD */
---------------------somewhere that's run during bootup: EVENTUALLY a SYSINIT
#ifdef JREMOD
sd_devsw_install();
#endif /*JREMOD*/
-----------------------at the bottom:
#ifdef JREMOD
struct bdevsw sd_bdevsw =
{ sdopen, sdclose, sdstrategy, sdioctl, /*4*/
sddump, sdsize, 0 };
struct cdevsw sd_cdevsw =
{ sdopen, sdclose, rawread, rawwrite, /*13*/
sdioctl, nostop, nullreset, nodevtotty,/* sd */
seltrue, nommap, sdstrategy };
static sd_devsw_installed = 0;
static void sd_devsw_install()
{
dev_t descript;
if( ! sd_devsw_installed ) {
descript = makedev(CDEV_MAJOR,0);
cdevsw_add(&descript,&sd_cdevsw,NULL);
#if defined(BDEV_MAJOR)
descript = makedev(BDEV_MAJOR,0);
bdevsw_add(&descript,&sd_bdevsw,NULL);
#endif /*BDEV_MAJOR*/
sd_devsw_installed = 1;
}
}
#endif /* JREMOD */
Most of this is cleaning up, but there are some functional changes,
doc/comment improvements, error checking, gcc -Wall cleanups. Input buffer
flushing is enabled now, although I'm still not quite certain it's right.
misplaced extern declarations (mostly prototypes of interrupt handlers)
that this exposed. The prototypes should be moved back to the driver
sources when the functions are staticalized.
Added idempotency guards to <machine/conf.h>. "ioconf.h" can't be
included when building LKMs so define a wart in bsd.kmod.mk to help
guard against including it.
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.
with the driver's stability now. I've not had a single problem with it for
weeks.. All that remains is a bit of performance tuning, and finishing
the manpages.
