Subject: Re: Changing the semantics of splsoftclock()
To: Peter Wemm <peter@netplex.com.au>
From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
List: tech-kern
Date: 06/27/1999 13:24:44 
* Peter Wemm (peter@netplex.com.au) [990627 09:02]:
> Bruce Evans wrote:
> > >>Why have splr semantics? That is, it raises to splsoftclock if current
> > >>priority is lower, else doesn't fiddle with it.
> > 
> > splsoftclock() has always had spllower() semantics, and its main users
> > (kern_clock.c and kern_time.c) depend on this.
> > 
> > FreeBSD has a precedent of not changing poor spl names because the change
> > would be confusing: splnet() should be named splsoftnet() and splimp()
> > should be named splnet() as in NetBSD.
> 
> I would like to correct this, it is a source of problems when dealing with
> NetBSD code.  It would be a relatively harmless change for us since it's
> failure mode is fairly benign.  Old code calling splnet() that gets missed
> will still work, just it will block more than is strictly required.
> splimp() callers will get found quickly since they'll be an undefined
> reference.

I would say "go for it", but then again, I am merely a third rank BSD 
developer, not even a commiter on one BSD ;)

However in the perspective of API cleanliness, it would be preffered from
my point of view just for the consistency across the BSD's.

> However, it would make backporting drivers from -current to 3.x a bit of a
> problem..

Guess the STABLE-branch is off limits for these kind of changes without
direct consent from core?

Just my 0.02 euro's,

-- 
Jeroen Ruigrok van der Werven                asmodai(at)wxs.nl
        The *BSD Programmer's Documentation Project 
Network/Security Specialist      <http://home.wxs.nl/~asmodai>
*BSD: We are back and will not accept no...
idea in principle, but we'll reserve > the right to veto anything that is too radical." True, that's the best approach, but like I pointed out in another mail, we need to be careful not to bring out old things. Let the past just be the past and concentrate on the future in which this, the API cleanup/ synchronisation, will play an important role. > Since I'm not a member of either core group, I'm not sure what the > best way to proceed here would be. The only comparable `projects' I can name in this aspect Warner, is the Linux Standard Base, POSIX, and the Single Un*x Specification. http://www.linuxbase.org http://www.opengroup.org/austin > Comments? You got my support Warner, actually you took my ideas a little further, I was merely documenting the differences, and you want to get them straightened out as much as possible. I don't think any core-team can deny the importance of a somewhat consistent base API (on multiple areas) in order to keep porting from FreeBSD to NetBSD, or from OpenBSD to FreeBSD to a minimum fuzz. This could also allow us to try to create a driver system that would make exchanging device drivers a breeze. And that would benefit us all... -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist <http://home.wxs.nl/~asmodai> *BSD: We are back and will not accept no...