Re: CVS commit: src/share/man/man9

[Tetsuya Isaki]

At Sun, 7 Feb 2021 09:22:39 +,
nia wrote:
> > > -It is called at any time.
> > > +It can be called at any time.
> > 
> > The later sounds to me "You(developer of MD driver) can call
> > it at any time".  If so, it's incorrect.
> 
> Maybe "it can be called by the MI layer at any time" is clearer
> here, then? I can change it to that.

That's true, but sounds a bit redundant.
Because these all are callback functions called by the MI layer.

Is there any better text?
The MI layer can(will?) call this in the Opened phase or in the
Closed phase, or even in the Attach phase.  This means, for example,
that you (MD driver) cannot assume that you can prepare(initialize)
something in open() before this (since this can be called in the
Closed phase), and you cannot assume that it has returned from MI
attach (since this can be called in the Attach phase).

> > Is "only" a typo?  or is it better to remove it in English?
> 
> I think it's clear that conversion of other formats is not
> supported by the rest of the paragraph, so it doesn't need to
> be mentioned here, where the primary purpose of the sentence
> is to explain why you don't need to handle conversion in that
> case yourself.

If it's clear for readers, no problem to me.

Thanks,
---
Tetsuya Isaki 

Re: CVS commit: src/share/man/man9

[nia]

On Sun, Feb 07, 2021 at 12:43:40PM +0900, Tetsuya Isaki wrote:
> > @@ -175,9 +175,9 @@
> >  .Vt audio_format_t
> >  structure according to given number
> >  .Va afp->index .
> > -If there is no format with given number, return
> > +If there is no format with the given number, return
> >  .Er EINVAL .
> > -It is called at any time.
> > +It can be called at any time.
> 
> The later sounds to me "You(developer of MD driver) can call
> it at any time".  If so, it's incorrect.

Maybe "it can be called by the MI layer at any time" is clearer
here, then? I can change it to that.

> 
> >  Similarly, if the driver supports
> >  .Dv SLINEAR_OE:16
> >  and the upper layer chooses it,
> > -the driver does not need to provide a conversion function.
> > -Because the upper layer only supports conversion between
> > +the driver does not need to provide a conversion function,
> > +because the upper layer supports conversion between
> 
> Is "only" a typo?  or is it better to remove it in English?
> 
> Thanks,
> ---
> Tetsuya Isaki 

I think it's clear that conversion of other formats is not
supported by the rest of the paragraph, so it doesn't need to
be mentioned here, where the primary purpose of the sentence
is to explain why you don't need to handle conversion in that
case yourself.

That's just my opinion, though - I'm not an English expert, there's
lots of rules I know but cannot explain.

Thanks,

Nia

Re: CVS commit: src/share/man/man9

[Tetsuya Isaki]

Hello,

At Sat, 6 Feb 2021 13:55:40 +,
Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Sat Feb  6 13:55:40 UTC 2021
> 
> Modified Files:
>   src/share/man/man9: audio.9
> 
> Log Message:
> Fix various typos, etc
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.59 -r1.60 src/share/man/man9/audio.9

> @@ -175,9 +175,9 @@
>  .Vt audio_format_t
>  structure according to given number
>  .Va afp->index .
> -If there is no format with given number, return
> +If there is no format with the given number, return
>  .Er EINVAL .
> -It is called at any time.
> +It can be called at any time.

The later sounds to me "You(developer of MD driver) can call
it at any time".  If so, it's incorrect.

>  Similarly, if the driver supports
>  .Dv SLINEAR_OE:16
>  and the upper layer chooses it,
> -the driver does not need to provide a conversion function.
> -Because the upper layer only supports conversion between
> +the driver does not need to provide a conversion function,
> +because the upper layer supports conversion between

Is "only" a typo?  or is it better to remove it in English?

Thanks,
---
Tetsuya Isaki 

Re: CVS commit: src/share/man/man9

[Andrew Doran]

On Sun, Feb 23, 2020 at 08:57:44AM +, matthew green wrote:
> Module Name:  src
> Committed By: mrg
> Date: Sun Feb 23 08:57:44 UTC 2020
> 
> Modified Files:
>   src/share/man/man9: Makefile
> 
> Log Message:
> install rw_lock_op link too.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.447 -r1.448 src/share/man/man9/Makefile
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.

Oops, forgot to commit the Makefile.  Thank you.

Andrew

Re: CVS commit: src/share/man/man9

[Valery Ushakov]

On Sat, Dec 07, 2019 at 12:22:19 +, Thomas Klausner wrote:

> Modified Files:
>   src/share/man/man9: atomic_loadstore.9
> 
> Log Message:
> Simplify macro usage.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.3 -r1.4 src/share/man/man9/atomic_loadstore.9

This breaks formatting, adding spaces between function names and the
opening parens - though, please, don't fix that, the original markup
is way overcomplicated anyway, I'll work with riastradh@ on
improvments.

-uwe

Re: CVS commit: src/share/man/man9

[Rin Okuyama]

- pci_intr_setattr() is in pci_intr(9)


Sorry it should be pci_intr_disestablish(), not pci_intr_setattr()...

rin

On 2018/09/20 16:08, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Thu Sep 20 07:08:00 UTC 2018

Modified Files:
src/share/man/man9: pci.9

Log Message:
- pci_intr_setattr() is in pci_intr(9)
- pci_intr_type() is in pci_msi(9)


To generate a diff of this commit:
cvs rdiff -u -r1.47 -r1.48 src/share/man/man9/pci.9

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Modified files:

Index: src/share/man/man9/pci.9
diff -u src/share/man/man9/pci.9:1.47 src/share/man/man9/pci.9:1.48
--- src/share/man/man9/pci.9:1.47   Wed Sep 12 09:45:59 2018
+++ src/share/man/man9/pci.9Thu Sep 20 07:08:00 2018
@@ -1,4 +1,4 @@
-.\" $NetBSD: pci.9,v 1.47 2018/09/12 09:45:59 mrg Exp $
+.\" $NetBSD: pci.9,v 1.48 2018/09/20 07:08:00 rin Exp $
  .\"
  .\" Copyright (c) 2001, 2003 The NetBSD Foundation, Inc.
  .\" All rights reserved.
@@ -27,7 +27,7 @@
  .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  .\" POSSIBILITY OF SUCH DAMAGE.
  .\"
-.Dd September 12, 2018
+.Dd September 20, 2018
  .Dt PCI 9
  .Os
  .Sh NAME
@@ -689,10 +689,10 @@ See
  .Xr pci_intr 9 .
  .It Fn pci_intr_disestablish "pc" "ih"
  See
-.Xr pci_msi 9 .
+.Xr pci_intr 9 .
  .It Fn pci_intr_type "pc" "ih"
  See
-.Xr pci_intr 9 .
+.Xr pci_msi 9 .
  .It Fn pci_intr_setattr "pc" "ih" "attr" "data"
  See
  .Xr pci_intr 9 .

Re: CVS commit: src/share/man/man9

[David Holland]

On Fri, Dec 08, 2017 at 03:52:01PM +, Taylor R Campbell wrote:
 > Modified Files:
 >  src/share/man/man9: mutex.9
 > 
 > Log Message:
 > Specify memory ordering implied by mutex_(spin_)enter/exit.
 > 
 > I'm hesitant to just say `implies membar_enter/exit' -- that may be a
 > little stronger than we intend, since we don't really mean to
 > guarantee anything about loads and stores before the mutex_enter or
 > after the mutex_exit.  But we probably end up implementing the
 > semantics that we imply membar_enter/exit on all CPUs.

The definition of membar_enter and membar_exit is the way it is to
make the stores involved in *doing* the enter and exit work. This
should not really be exposed outside the mutex code... on some
processors it's possible to order those stores with the ones "inside"
without affecting anyone else.

So I would say that the problem here is in the way membar_enter/exit
are defined; or rather, that they're called that (which is confusing
anyway) rather than e.g. membar_store_any() and membar_any_store().

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[Valery Ushakov]

On Mon, Oct 16, 2017 at 18:40:19 +, co...@sdf.org wrote:

> On Mon, Oct 16, 2017 at 04:53:17PM +0300, Valery Ushakov wrote:
> > On Mon, Oct 16, 2017 at 11:53:00 +, Maya Rashish wrote:
> > > Modified Files:
> > >   src/share/man/man9: byteorder.9
> > > 
> > > Log Message:
> > > Suggest to include the POSIX  rather than BSD 
> > 
> > Section 9 is kernel internals, so  is the correct header.
> > Please revert.
> 
> It's also in the wrong section.

It's not.  Userland functions have their own man page in section 3.

-uwe

Re: CVS commit: src/share/man/man9

[coypu]

On Mon, Oct 16, 2017 at 04:53:17PM +0300, Valery Ushakov wrote:
> On Mon, Oct 16, 2017 at 11:53:00 +, Maya Rashish wrote:
> > Modified Files:
> > src/share/man/man9: byteorder.9
> > 
> > Log Message:
> > Suggest to include the POSIX  rather than BSD 
> 
> Section 9 is kernel internals, so  is the correct header.
> Please revert.

It's also in the wrong section.

Re: CVS commit: src/share/man/man9

[Valery Ushakov]

On Mon, Oct 16, 2017 at 11:53:00 +, Maya Rashish wrote:
> Modified Files:
>   src/share/man/man9: byteorder.9
> 
> Log Message:
> Suggest to include the POSIX  rather than BSD 

Section 9 is kernel internals, so  is the correct header.
Please revert.

-uwe

Re: CVS commit: src/share/man/man9

[Kengo NAKAHARA]

Hi,

On 2016/07/06 18:20, Abhinav Upadhyay wrote:
> Module Name:  src
> Committed By: abhinav
> Date: Wed Jul  6 09:20:42 UTC 2016
> 
> Modified Files:
>   src/share/man/man9: interrupt_distribute.9
> 
> Log Message:
> Add missing .Nd
> 
> ok wiz@, knakaraha@
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.1 -r1.2 src/share/man/man9/interrupt_distribute.9

Thank you for your fixes.


Thanks,

-- 
//
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA 

Re: CVS commit: src/share/man/man9

[Taylor R Campbell]

   Date: Mon, 20 Apr 2015 16:14:08 +0200
   From: Thomas Klausner w...@netbsd.org

   On Mon, Apr 20, 2015 at 02:09:14PM +, Taylor R Campbell wrote:
Module Name:   src
Committed By:  riastradh
Date:  Mon Apr 20 14:09:14 UTC 2015

Modified Files:
   src/share/man/man9: vnode.9

Log Message:
Use Dv, not Li, for EBUSY/ENOENT.

   Actually, there even is a separate 'Er' macro for error codes.

Ah, thanks.  I'll apply that when I finish some other reworking of
vnode(9).

Re: CVS commit: src/share/man/man9

[Thomas Klausner]

On Mon, Apr 20, 2015 at 02:09:14PM +, Taylor R Campbell wrote:
 Module Name:  src
 Committed By: riastradh
 Date: Mon Apr 20 14:09:14 UTC 2015
 
 Modified Files:
   src/share/man/man9: vnode.9
 
 Log Message:
 Use Dv, not Li, for EBUSY/ENOENT.

Actually, there even is a separate 'Er' macro for error codes.
 Thomas

Re: CVS commit: src/share/man/man9

[David Holland]

On Fri, Jul 25, 2014 at 08:38:29AM +, Thomas Klausner wrote:
  Modified Files:
   src/share/man/man9: vnodeops.9
  
  Log Message:
  New sentence, new line. Punctuation formatting nits.

Woops, sorry about that.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[David Holland]

On Mon, Oct 01, 2012 at 06:16:36PM +, Nicolas Joly wrote:
  Modified Files:
   src/share/man/man9: vnodeops.9
  
  Log Message:
  Update _PC_NO_TRUNC description to add the returned value, and
  replace non-existant KERN_NAME_MAX with {NAME_MAX}.

It is not nonexistent, it's KERNEL_NAME_MAX.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[Mindaugas Rasiukevicius]

Jukka Ruohonen jruoho...@iki.fi wrote:
  
  Log Message:
  Fix .Xr to membar_ops(3), not membar(9).  Spotted by wiz@.
 
 Can you brief on what is the difference between membar_ops(3) and mb(9)?
 

mb(9) predates membar_ops(3).  I do not know why it was left when the
later interface was added.  It seems to me that mb(9) should be removed.
Some good notes from mb(9) man page can be moved to membar_ops(9) though.

-- 
Mindaugas

Re: CVS commit: src/share/man/man9

[Masao Uebayashi]

How about ABI?  KASSERT(9) should preserve ABI IMO.

On Tue, Jan 25, 2011 at 11:46:48PM +, YAMAMOTO Takashi wrote:
 Module Name:  src
 Committed By: yamt
 Date: Tue Jan 25 23:46:48 UTC 2011
 
 Modified Files:
   src/share/man/man9: KASSERT.9
 
 Log Message:
 - add some random notes
 
  Basically, KASSERT() should be used for light-weight checks and
  KDASSERT() should be used for heavier ones.
 
  Callers should not rely on the side effects of expression because,
  depending on the kernel compile options mentioned above, expression might
  not be evaluated at all.
 
 - Xr options(4)
 - bump date
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/share/man/man9/KASSERT.9
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.
 

 Modified files:
 
 Index: src/share/man/man9/KASSERT.9
 diff -u src/share/man/man9/KASSERT.9:1.9 src/share/man/man9/KASSERT.9:1.10
 --- src/share/man/man9/KASSERT.9:1.9  Fri Oct 29 09:34:03 2010
 +++ src/share/man/man9/KASSERT.9  Tue Jan 25 23:46:48 2011
 @@ -1,4 +1,4 @@
 -.\ $NetBSD: KASSERT.9,v 1.9 2010/10/29 09:34:03 wiz Exp $
 +.\ $NetBSD: KASSERT.9,v 1.10 2011/01/25 23:46:48 yamt Exp $
  .\
  .\ Copyright (c) 2006 Igor Sobrado
  .\ All rights reserved.
 @@ -24,7 +24,7 @@
  .\ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
 THE
  .\ POSSIBILITY OF SUCH DAMAGE.
  .\
 -.Dd October 28, 2010
 +.Dd Janurary 26, 2011
  .Dt KASSERT 9
  .Os
  .Sh NAME
 @@ -63,11 +63,24 @@
  vs
  .Dv DIAGNOSTIC ) .
  .Pp
 +Basically,
 +.Fn KASSERT
 +should be used for light-weight checks and
 +.Fn KDASSERT
 +should be used for heavier ones.
 +.Pp
 +Callers should not rely on the side effects of
 +.Ar expression
 +because, depending on the kernel compile options mentioned above,
 +.Ar expression
 +might not be evaluated at all.
 +.Pp
  The panic message will display the style of assertion (debugging
  vs. diagnostic), the expression that failed and the filename, and line
  number the failure happened on.
  .Sh SEE ALSO
  .Xr config 1 ,
 +.Xr options 4 ,
  .Xr CTASSERT 9 ,
  .Xr panic 9 ,
  .Xr printf 9
 

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

Re: CVS commit: src/share/man/man9

[YAMAMOTO Takashi]

hi,

 How about ABI?  KASSERT(9) should preserve ABI IMO.

sorry, i'm not sure what you mean.  can you explain?

YAMAMOTO Takashi

Re: CVS commit: src/share/man/man9

[Masao Uebayashi]

Sorry, I was confused KASSERT(9) with DIAGNOSTICS.

(Don't send email before having coffee...)

On Wed, Jan 26, 2011 at 02:30:18AM +, YAMAMOTO Takashi wrote:
 hi,
 
  How about ABI?  KASSERT(9) should preserve ABI IMO.
 
 sorry, i'm not sure what you mean.  can you explain?
 
 YAMAMOTO Takashi

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

Re: CVS commit: src/share/man/man9

[Jukka Ruohonen]

On Tue, Jan 25, 2011 at 11:46:48PM +, YAMAMOTO Takashi wrote:
 - add some random notes
 
  Basically, KASSERT() should be used for light-weight checks and
  KDASSERT() should be used for heavier ones.
 
  Callers should not rely on the side effects of expression because,
  depending on the kernel compile options mentioned above, expression might
  not be evaluated at all.

I guess the newly added KDASSERTMSG() should be documented too.

- Jukka.

Re: CVS commit: src/share/man/man9

[David Holland]

On Fri, May 14, 2010 at 08:51:46PM +0900, Izumi Tsutsui wrote:
   A transfer of little-endian data? I guess that's not entirely clear,
   especially for anyone who doesn't automatically interpret DMA as a
   form of memcpy.
   
   Anyway, I just fixed it up again, please take a look.
  
   to handle PCI bus master devices that (via DMA) transfer little endian
   data even on big endian systems.
  
  Hmm. I'm still afraid transfer little endian data might be ambiguous.
  hto*()/*toh() functions are required only for data passed between
  the target busmaster itself to control it. Any other little endian data
  transferred to/from actual devices never require those byteswap ops.
  
  How about this one?
  
   to handle PCI bus master devices that (via DMA) transfer word parameters
   in little endian even on big endian systems.

Still sounds pretty awkward.

What about little endian control data instead of juts little endian
data?

It doesn't have to be perfect anyway; it's a historical note.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[Izumi Tsutsui]

to handle PCI bus master devices that (via DMA) transfer word parameters
in little endian even on big endian systems.
 
 Still sounds pretty awkward.

Well, the definition of endianness itself is always awkward.

 What about little endian control data instead of juts little endian
 data?

IMO, data itself doesn't have any property of endianness at all,
so little endian (control) data sounds weird for me.

Endianness is defined only if data is interpreted in a smaller unit
(byte access against word data, bit access against byte data etc).
If the first unit (smallest byte address or first bit in stream)
is the least significant byte/bit, such enconding method is called
little endian (or just literally LSB first), and vice versa.
If the data is read/written in its own size, endianness/byteorder
is not visible at all.

 It doesn't have to be perfect anyway; it's a historical note.

But there were several developers who asked why such APIs were needed,
and busmaster drivers are still major users of these functions
(and most x86 driver writers in the world won't consider about it).
That was the reason why I added the sentence.
---
Izumi Tsutsui

Re: CVS commit: src/share/man/man9

[David Holland]

On Thu, May 06, 2010 at 08:27:05PM +0900, Izumi Tsutsui wrote:
   -bus master devices which assumed little endian byte order in
   +bus master devices that do little endian
.Tn DMA
   -transfers, even on big endian systems.
   +transfers on big endian systems.
  
  What's little endian transfer?

A transfer of little-endian data? I guess that's not entirely clear,
especially for anyone who doesn't automatically interpret DMA as a
form of memcpy.

Anyway, I just fixed it up again, please take a look.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[David Holland]

On Tue, May 04, 2010 at 05:16:58AM -0700, Paul Goyette wrote:
 +The functions were originally introduced to handle
 +.Tn PCI
 +bus master devices, which assumed little endian byte order in
 +.Tn DMA
 +transfers, even on big endian systems.

 There are a few PCI bus master devices that are big endian aware
 (epic(4) for example), so I don't think it's appropriate to add
 commas around the which clause.

 I agree that the first comma should go, but the second one (before  
 even) should remain.

No it shouldn't. Anyway, I just rearranged it to hopefully avoid such
problems entirely.

-- 
David A. Holland
dholl...@netbsd.org

Re: CVS commit: src/share/man/man9

[Izumi Tsutsui]

  +The functions were originally introduced to handle
  +.Tn PCI
  +bus master devices, which assumed little endian byte order in
  +.Tn DMA
  +transfers, even on big endian systems.
 
  There are a few PCI bus master devices that are big endian aware
  (epic(4) for example), so I don't think it's appropriate to add
  commas around the which clause.
 
  I agree that the first comma should go, but the second one (before  
  even) should remain.
 
 No it shouldn't. Anyway, I just rearranged it to hopefully avoid such
 problems entirely.

cvs rdiff -u -r1.6 -r1.7 src/share/man/man9/byteorder.9
 -bus master devices which assumed little endian byte order in
 +bus master devices that do little endian
  .Tn DMA
 -transfers, even on big endian systems.
 +transfers on big endian systems.

What's little endian transfer?

IMO, DMA transfers are always stream (no byte reordering) and
hto*()/*toh() functions are used to encode/decode values
larger than a byte into/from the stream before/after transfers
per byte order the target bus master device assumes.

That was what a dumb sentence in rev 1.1 meant.
---
Izumi Tsutsui

Re: CVS commit: src/share/man/man9

[Izumi Tsutsui]

 Modified Files:
   src/share/man/man9: byteorder.9
 
 Log Message:
 Reference bswap(3). Improvements in the HISTORY section.
 :
 cvs rdiff -u -r1.4 -r1.5 src/share/man/man9/byteorder.9

 -These functions were introduced to handle PCI bus master devices which 
 assumed
 -host's memory used to pass integer parameters via DMA transfer was
 -always little endian even on big endian systems.
 :
 +The functions were originally introduced to handle
 +.Tn PCI
 +bus master devices, which assumed little endian byte order in
 +.Tn DMA
 +transfers, even on big endian systems.

There are a few PCI bus master devices that are big endian aware
(epic(4) for example), so I don't think it's appropriate to add
commas around the which clause.

---
Izumi Tsutsui (who put a dumb sentence in the initial revision)

Re: CVS commit: src/share/man/man9

[Paul Goyette]

On Tue, 4 May 2010, Izumi Tsutsui wrote:


Modified Files:
src/share/man/man9: byteorder.9

Log Message:
Reference bswap(3). Improvements in the HISTORY section.

:

cvs rdiff -u -r1.4 -r1.5 src/share/man/man9/byteorder.9



-These functions were introduced to handle PCI bus master devices which assumed
-host's memory used to pass integer parameters via DMA transfer was
-always little endian even on big endian systems.

:

+The functions were originally introduced to handle
+.Tn PCI
+bus master devices, which assumed little endian byte order in
+.Tn DMA
+transfers, even on big endian systems.


There are a few PCI bus master devices that are big endian aware
(epic(4) for example), so I don't think it's appropriate to add
commas around the which clause.


I agree that the first comma should go, but the second one (before 
even) should remain.



-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/share/man/man9

[Adam Hoka]

On Thu, 29 Apr 2010 16:31:11 +
Jukka Ruohonen jru...@netbsd.org wrote:

 Module Name:  src
 Committed By: jruoho
 Date: Thu Apr 29 16:31:11 UTC 2010
 
 Modified Files:
   src/share/man/man9: signal.9
 
 Log Message:
 Update this, mechanically, to match the new functions and their prototypes.
 
 XXX: Someone more familiar with the code should proofread the page and
  evaluate how well it reflects the reality in 2010.

Thanks for working on the docs!

-- 
NetBSD - Simplicity is prerequisite for reliability

Re: CVS commit: src/share/man/man9

[Joerg Sonnenberger]

War die Diskussion nicht, dass das Teil eigentlich gar nicht
dokumentiert sein sollte? Insofern halte ich dies fuer falsch...

Joerg

On Sun, Feb 07, 2010 at 10:49:36AM +, Thomas Klausner wrote:
 Module Name:  src
 Committed By: wiz
 Date: Sun Feb  7 10:49:36 UTC 2010
 
 Modified Files:
   src/share/man/man9: spl.9
 
 Log Message:
 Xref i386/splraise.9 and bump date for previous.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.37 -r1.38 src/share/man/man9/spl.9
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

RE: CVS commit: src/share/man/man9

[Paul Goyette]

On Mon, 25 Jan 2010, Paul Goyette wrote:


Module Name:src
Committed By:   jruoho
Date:   Mon Jan 25 16:16:34 UTC 2010

Modified Files:
src/share/man/man9: Makefile
Added Files:
src/share/man/man9: sysmon_taskq.9

Log Message:
Add a simple manual page for the simple sysmon task queue.

ok wiz@


This routine is really targetted specifically for use by the sysmon_envsys(8) 
facility.  This man page seems to imply that it's available for 
general-purpose use.


If we're going to treat it as a general-purpose routine, we should rename and 
move the files (kern/kern_taskq.[ch] maybe?).  Otherwise, I'd prefer to make 
this man page more specific to sysmon, and perhaps

add an example of where it is currently used.

Also, there is some semantics in the current implementation where all the 
tasks in the queue are run before checking the condvar;  this might not 
necessarily be appropriate for a general-purpose taskq.


/*
 * Run through all the tasks before we check for the exit
 * condition; it's probably more important to actually run
 * all the tasks before we exit.
 */



-
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:  |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/share/man/man9

[Jukka Ruohonen]

On Mon, Jan 25, 2010 at 12:54:45PM -0800, Paul Goyette wrote:
 This routine is really targetted specifically for use by the 
 sysmon_envsys(8) facility.  This man page seems to imply that it's 
 available for general-purpose use.

Well, the sysmon-part is in the name so... :)

While it is targeted for sysmon_envsys(8), the most important task for it on
x86 is to schedule all ACPI notifys, including interrupts, via the
AcpiOsExecute (see sys/dev/acpi/acpica/OsdSchedule.c). I would presume that
this was also the reason why it was originally written.

The other places where it is currently used:

* sys/arch/arm/xscale/becc_button.c
* sys/arch/evbarm/hdl_g/btn_obio.c
* sys/arch/evbarm/nslu2/nslu2_buttons.c
* sys/arch/hp700/dev/power.c
* sys/arch/landisk/dev/btn_obio.c
* sys/arch/landisk/dev/pwrsw_obio.c
* sys/arch/mips/atheros/dev/argpio.c
* sys/arch/sgimips/hpc/panel.c
* sys/arch/sparc/dev/tctrl.c
* sys/arch/sparc64/dev/psycho.c
* sys/arch/x68k/dev/pow.c
* sys/dev/adb/adb_kbd.c
* sys/arch/arm/xscale/becc_button.c

... and probably others.

This makes it pretty general to me.

 If we're going to treat it as a general-purpose routine, we should rename 
 and move the files (kern/kern_taskq.[ch] maybe?).  Otherwise, I'd prefer to 
 make this man page more specific to sysmon, and perhaps
 add an example of where it is currently used.

Due to the wide usage listed above, I don't think renaming is worth the
cause. A word or two about the context (sysmon, power, something) wouldn't
do harm though.

 Also, there is some semantics in the current implementation where all the 
 tasks in the queue are run before checking the condvar;  this might not 
 necessarily be appropriate for a general-purpose taskq.
 
   /*
* Run through all the tasks before we check for the exit
* condition; it's probably more important to actually run
* all the tasks before we exit.
*/

This could be mentioned sure.

- Jukka.

Re: CVS commit: src/share/man/man9

[Paul Goyette]

Wow - I didn't realize it was so widely used!  (Next time, before I 
comment, I'll learn to use grep!)


As already pointed out, a large percentage of those references are part 
of the various buttons' integration with sysmon/powerd.  I think that a 
simple mention of this intended usage would be appropriate for the man 
page.  I also think that the run all tasks before checking for exit 
semantics should be mentioned.


But we can forget about relocating it.  :)

BTW, thanks for documenting it!


On Mon, 25 Jan 2010, Jukka Ruohonen wrote:


On Mon, Jan 25, 2010 at 12:54:45PM -0800, Paul Goyette wrote:

This routine is really targetted specifically for use by the
sysmon_envsys(8) facility.  This man page seems to imply that it's
available for general-purpose use.


Well, the sysmon-part is in the name so... :)

While it is targeted for sysmon_envsys(8), the most important task for it on
x86 is to schedule all ACPI notifys, including interrupts, via the
AcpiOsExecute (see sys/dev/acpi/acpica/OsdSchedule.c). I would presume that
this was also the reason why it was originally written.

The other places where it is currently used:

* sys/arch/arm/xscale/becc_button.c
* sys/arch/evbarm/hdl_g/btn_obio.c
* sys/arch/evbarm/nslu2/nslu2_buttons.c
* sys/arch/hp700/dev/power.c
* sys/arch/landisk/dev/btn_obio.c
* sys/arch/landisk/dev/pwrsw_obio.c
* sys/arch/mips/atheros/dev/argpio.c
* sys/arch/sgimips/hpc/panel.c
* sys/arch/sparc/dev/tctrl.c
* sys/arch/sparc64/dev/psycho.c
* sys/arch/x68k/dev/pow.c
* sys/dev/adb/adb_kbd.c
* sys/arch/arm/xscale/becc_button.c

... and probably others.

This makes it pretty general to me.


If we're going to treat it as a general-purpose routine, we should rename
and move the files (kern/kern_taskq.[ch] maybe?).  Otherwise, I'd prefer to
make this man page more specific to sysmon, and perhaps
add an example of where it is currently used.


Due to the wide usage listed above, I don't think renaming is worth the
cause. A word or two about the context (sysmon, power, something) wouldn't
do harm though.


Also, there is some semantics in the current implementation where all the
tasks in the queue are run before checking the condvar;  this might not
necessarily be appropriate for a general-purpose taskq.

/*
 * Run through all the tasks before we check for the exit
 * condition; it's probably more important to actually run
 * all the tasks before we exit.
 */


This could be mentioned sure.

- Jukka.



-
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:  |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |  | pgoyette at netbsd.org  |
-

Re: CVS commit: src/share/man/man9

[Adam Hoka]

On Wed, 2 Sep 2009, Thomas Klausner wrote:


Date: Wed, 2 Sep 2009 13:32:54 +0200
From: Thomas Klausner w...@netbsd.org
Reply-To: source-changes-d@netbsd.org
To: source-changes-d@netbsd.org
Subject: Re: CVS commit: src/share/man/man9

On Wed, Sep 02, 2009 at 10:54:20AM +, Adam Hoka wrote:

Module Name:src
Committed By:   ahoka
Date:   Wed Sep  2 10:54:20 UTC 2009

Modified Files:
src/share/man/man9: csf.9

Log Message:
Mention sched_m4.


# man sched_m2
man: no entry for sched_m2 in the manual.
# man sched_m4
man: no entry for sched_m4 in the manual.

Thomas



I meant m2, of course. I will put together something for sched_m2
manpage to give the users at least a little clue.
Well don't expect any verbose documentation. :-)

Re: CVS commit: src/share/man/man9

[Julian Coleman]

Hi,

 A crusade against British English?

Yes, for example, colour versus color in the curses manual pages.  As
a US-based project, we standardiszed on US English, even though both the
authors naturally use the British English spelling ;-)

Thanks,

J

-- 
  My other computer also runs NetBSD/Sailing at Newbiggin
http://www.netbsd.org//   http://www.newbigginsailingclub.org/