Re: CVS commit: src/sys

2009-11-18 Thread YAMAMOTO Takashi
hi,

> On Wed, Nov 18, 2009 at 03:51:02AM +, YAMAMOTO Takashi wrote:
>> > Log Message:
>> > Add a kernel configuration flag, SPLDEBUG, that activates a per-CPU log
>> > of transitions to IPL_HIGH from lower IPLs.  SPLDEBUG is only available
>> > on i386 and Xen kernels, today.
>> > 
>> > 'options SPLDEBUG' adds instrumentation to spllower() and splraise() as
>> > well as routines to start/stop debugging and to record IPL transitions:
>> > spldebug_start(), spldebug_stop(), spldebug_raise(), spldebug_lower().
>> 
>> this seems too ad-hoc to me.
> 
> If you have suggestions for providing a comparable function that is less
> ad-hoc, let me know.
> 
>> - please don't put MD code like this in kern/.  IPL_ values can't be
>>   compared with >= in MI code.  return_address.9 is in man.i386.
> 
> Thanks for pointing this out.  I am not going to move it from sys/kern/,
> since it is fairly easy to make it MI.  I will compare IPL values with
> == and !=, and write an MI stub for return_address(9) that returns NULL
> on non-i386.
> 
>> - there are other places where the spl value is modified.
>>   eg. interrupt stubs, lock stubs, etc.
> 
> Code references, please?

"grep ILEVEL *.S"
eg. mutex_spin_enter, intr_lapic_ltimer, etc

> 
>> - can you explain "cpu_index(ci) > MAXCPUS" and "cpu_index(ci) >= MAXCPUS" ?
> 
> Typo.

why are these checks necessary in the first place?

YAMAMOTO Takashi

> 
> Dave
> 
> -- 
> David Young OJC Technologies
> dyo...@ojctech.com  Urbana, IL * (217) 278-3933


Re: CVS commit: src

2009-11-18 Thread YAMAMOTO Takashi
hi,

> On Wed, Nov 18, 2009 at 01:29:05AM +, YAMAMOTO Takashi wrote:
>> hi,
>> 
>> > Module Name:   src
>> > Committed By:  dyoung
>> > Date:  Tue Nov 17 18:36:07 UTC 2009
>> > 
>> > Modified Files:
>> >src/distrib/sets/lists/comp: mi
>> >src/share/man/man9: Makefile spl.9
>> > 
>> > Log Message:
>> > Describe spllower(9) and splraise(9).
>> 
>> these are MD implementation details which are not appropriate to be
>> described in this page.  please revert.
>> adding xrefs to splraiseipl and makeiplcookie instead is probably
>> a good idea.
> 
> I see.  I will describe spllower(9) and splraise(9) in an i386 page,
> instead.

imo, for internal functions like them, it's more appropriate to put
comments in the source code than man pages.

YAMAMOTO Takashi

> 
> Dave
> 
> -- 
> David Young OJC Technologies
> dyo...@ojctech.com  Urbana, IL * (217) 278-3933


Re: CVS commit: src

2009-11-18 Thread Thomas E. Spanjaard
Jason Thorpe wrote:
> On Nov 18, 2009, at 12:40 PM, David Young wrote:
> 
>> I see.  I will describe spllower(9) and splraise(9) in an i386 page,
>> instead.
> 
> They should not be documented at all.  They are not interfaces that are meant 
> to be used in any user-serviceable way.

Section 9 isn't about "user-serviceable" interfaces anyway, unless the
user is a kernel developer, in which case it is relevant :).

Cheers,
-- 
Thomas E. Spanjaard
t...@netphreax.net
t...@deepbone.net



signature.asc
Description: OpenPGP digital signature


Re: CVS commit: src

2009-11-18 Thread Jason Thorpe

On Nov 18, 2009, at 12:40 PM, David Young wrote:

> I see.  I will describe spllower(9) and splraise(9) in an i386 page,
> instead.

They should not be documented at all.  They are not interfaces that are meant 
to be used in any user-serviceable way.

-- thorpej



Re: CVS commit: src

2009-11-18 Thread David Young
On Wed, Nov 18, 2009 at 01:29:05AM +, YAMAMOTO Takashi wrote:
> hi,
> 
> > Module Name:src
> > Committed By:   dyoung
> > Date:   Tue Nov 17 18:36:07 UTC 2009
> > 
> > Modified Files:
> > src/distrib/sets/lists/comp: mi
> > src/share/man/man9: Makefile spl.9
> > 
> > Log Message:
> > Describe spllower(9) and splraise(9).
> 
> these are MD implementation details which are not appropriate to be
> described in this page.  please revert.
> adding xrefs to splraiseipl and makeiplcookie instead is probably
> a good idea.

I see.  I will describe spllower(9) and splraise(9) in an i386 page,
instead.

Dave

-- 
David Young OJC Technologies
dyo...@ojctech.com  Urbana, IL * (217) 278-3933


Re: CVS commit: src/sys

2009-11-18 Thread David Young
On Wed, Nov 18, 2009 at 03:51:02AM +, YAMAMOTO Takashi wrote:
> > Log Message:
> > Add a kernel configuration flag, SPLDEBUG, that activates a per-CPU log
> > of transitions to IPL_HIGH from lower IPLs.  SPLDEBUG is only available
> > on i386 and Xen kernels, today.
> > 
> > 'options SPLDEBUG' adds instrumentation to spllower() and splraise() as
> > well as routines to start/stop debugging and to record IPL transitions:
> > spldebug_start(), spldebug_stop(), spldebug_raise(), spldebug_lower().
> 
> this seems too ad-hoc to me.

If you have suggestions for providing a comparable function that is less
ad-hoc, let me know.

> - please don't put MD code like this in kern/.  IPL_ values can't be
>   compared with >= in MI code.  return_address.9 is in man.i386.

Thanks for pointing this out.  I am not going to move it from sys/kern/,
since it is fairly easy to make it MI.  I will compare IPL values with
== and !=, and write an MI stub for return_address(9) that returns NULL
on non-i386.

> - there are other places where the spl value is modified.
>   eg. interrupt stubs, lock stubs, etc.

Code references, please?

> - can you explain "cpu_index(ci) > MAXCPUS" and "cpu_index(ci) >= MAXCPUS" ?

Typo.

Dave

-- 
David Young OJC Technologies
dyo...@ojctech.com  Urbana, IL * (217) 278-3933


Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/mips

2009-11-18 Thread Martin Husemann
[wrong list, redirecting to source-changes-d, sorry...]

On Wed, Nov 18, 2009 at 10:34:54AM +0100, Martin Husemann wrote:
> On Tue, Nov 17, 2009 at 07:56:27AM +, Matt Thomas wrote:
> > (slightly bogus but then we really should kill extent and switch to vmem)
> 
> I keep hearing this mantra.
> 
> Yet I don't see how vmem(9) is up to the task of, say, managing pcmcia io
> port allocations (without bogusly wasting memory).
> 
> Why is the vmem interface preferable? I see how we could improve the extend(9)
> implementation (e.g. kill the use fo malloc()).
> 
> Martin