Re: CVS commit: src

[Mindaugas Rasiukevicius <rmind%NetBSD.org@localhost>]

Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> On Sat, Apr 12, 2008 at 08:03:47PM +0100, Mindaugas Rasiukevicius wrote:
> > Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> > > On Sat, Apr 12, 2008 at 02:14:27PM +0100, Mindaugas Rasiukevicius wrote:
> > > > Thor Lancelot Simon <tls%rek.tjls.com@localhost> wrote:
> > > > > > - Why crypto_mtx is not set to IPL_SOFTNET, but IPL_NET?
> > > > > 
> > > > > It replaced calls to "splcrypto()", which was splnet().  The actual
> > > > > hardware drivers currently in the tree all use splnet() for mutual
> > > > > exclusion and there are a couple of cases where driver done routines
> > > > > can need the crypto_mtx -- so I think it probably has to be at
> > > > > IPL_NET, no?
> > > > 
> > > > The current code uses software interrupt, and IPL_SOFT* levels are
> > > > used to block them. Why blocking of hard interrupts (at IPL_NET) is
> > > > needed?
> > > 
> > > But the hardware drivers take the mutex before calling the done
> > > function, when requests finish at the hardware.  Most of the existing
> > > drivers run at splnet() -- if they might be running at IPL_NET when
> > > they take the mutex, doesn't the mutex have to be initialized with
> > > IPL_NET?
> > 
> > Yes, if code is correct, mutex would use IPL_NET (or IPL_VM, since reduce
> > of the levels). We are not discussing the correct way to convert from spl*
> > () to mutex, though. Question is - why blocking of hard interrupts is
> > needed?
> 
> It's not a question of converting from spl* to mutex, as far as I can see:
> Existing drivers in the tree (hifn, ubsec, etc.) assume that if they splnet
> (), they exclude the code in crypto.c.  For that to be true, the mutex _has
> to_ be IPL_NET, AFAICT.
> 
> Is this wrong?

How other existing drivers are related to my question, and crypto.c ?

-- 
Best regards,
Mindaugas
www.NetBSD.org