Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jan 1999 02:46:13 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        "Justin T. Gibbs" <gibbs@plutotech.com>
Cc:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Eivind Eklund <eivind@FreeBSD.ORG>, Nicolas Souchu <nsouch@teaser.fr>, Bruce Evans <bde@zeta.org.au>, mike@smith.net.au, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/dev/ppbus if_plip.c 
Message-ID:  <199901121846.CAA67261@spinner.netplex.com.au>
In-Reply-To: Your message of "Tue, 12 Jan 1999 09:18:01 MST." <199901121626.JAA07694@pluto.plutotech.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" wrote:
> ><<On Tue, 12 Jan 1999 00:29:39 +0100, Eivind Eklund <eivind@FreeBSD.ORG> sai
    d:
> >
> >> I don't know how the new bus framework will like this kind of
> >> behaviour, though.
> >
> >Easy -- you just declare your device as being of type `TTY|NET' and
> >the magic just comes naturally.  (Except, of course, that this part
> >isn't implemented yet, but it should be fairly trivial to do once the
> >interrupt code is debogotified.)
> 
> Can't we have a more dynamic mechanism than that?  You don't want 
> potentially shared interrupts in extra masks unless its absolutely
> necessary (e.g. PPP is compiled into the kernel, but the net mask
> is only modified when that line discipline is (de)activated and
> only for the device interrupts that are engaged in PPP activity).


IMHO, the real problem is the blurring and crossing of domains..  eg: the
tty interrupt executes into the line discipline code and that executes
through into code that's in the network domain, etc.  I don't remember the
specifics, but it's something like that.

In cases where we run from software interrupt context, things can be a 
little easier to deal with since there's a natural priority and 
sequencing, at least on the i386.

In the PPP case, thinking about it again, part of the reason behind the
problem is that code called from the tty interrupt can call MGETHDR() which
is meant to be splimp protected.  Another user of MGETHDR() will only have
network hardware interrupts masked, but that won't stop tty interrupts
happening and calling these routines, possibly while the kernel is alread
half way through a previous MGETHDR().  For PPP, perhaps the "solution" is
to use a preallocated cluster pool or some sort of mutex so it can abort an
allocation attempt (and drop characters) if another has been preempted.

Protecting the mbuf allocator higher than splimp would also help, but 
perhaps is a little on the extreme side.

Cheers,
-Peter



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901121846.CAA67261>