Re: CVS commit: src/share/man/man9
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
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
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
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
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
- 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
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
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
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
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
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
Date: Mon, 20 Apr 2015 16:14:08 +0200 From: 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. Ah, thanks. I'll apply that when I finish some other reworking of vnode(9).
Re: CVS commit: src/share/man/man9
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
Le 27/12/2014 21:45, Thomas Klausner a écrit : > Module Name: src > Committed By: wiz > Date: Sat Dec 27 20:45:08 UTC 2014 > > Modified Files: > src/share/man/man9: malloc.9 > > Log Message: > New sentence, new line. Bump date for previous. > > > To generate a diff of this commit: > cvs rdiff -u -r1.50 -r1.51 src/share/man/man9/malloc.9 > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > > Ah!
Re: CVS commit: src/share/man/man9
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
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
On Mon, Feb 13, 2012 at 01:01:39PM +, Nicolas Joly wrote: > Modified Files: > src/share/man/man9: vfsops.9 > > Log Message: > Fix copyin/copyout sections in xrefs. Ugh, sorry about that. Should definitely not have let that get through... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/man/man9
Jukka Ruohonen 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
On Sun, Aug 07, 2011 at 12:29:24PM +, Mindaugas Rasiukevicius wrote: > Module Name: src > Committed By: rmind > Date: Sun Aug 7 12:29:24 UTC 2011 > > Modified Files: > src/share/man/man9: pserialize.9 > > 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)? - Jukka.
Re: CVS commit: src/share/man/man9
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
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
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
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
Hello, > Module Name:src > Committed By: jruoho > Date: Fri May 14 18:52:46 UTC 2010 > > Modified Files: > src/share/man/man9: bus_dma.9 kmem.9 pmc.9 sysctl.9 xcall.9 > > Log Message: > Use standard section headers. > > > To generate a diff of this commit: > cvs rdiff -u -r1.52 -r1.53 src/share/man/man9/bus_dma.9 > cvs rdiff -u -r1.8 -r1.9 src/share/man/man9/kmem.9 > cvs rdiff -u -r1.10 -r1.11 src/share/man/man9/pmc.9 > cvs rdiff -u -r1.15 -r1.16 src/share/man/man9/sysctl.9 > cvs rdiff -u -r1.4 -r1.5 src/share/man/man9/xcall.9 Renamed sections in kmem(9), xcall(9) and actually sysctl(9) contain general notes and recommendations for interface callers/users, not the implementation notes (of subsystem), like in bus_dma(9) or pmc(9). -- Mindaugas
Re: CVS commit: src/share/man/man9
> >> 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
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
> > >> -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. >> 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. --- Izumi Tsutsui (who introduced htopci() macro into pcscp(4) in PR#6654 to implement the driver on macppc about 11 years ago)
Re: CVS commit: src/share/man/man9
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
> +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
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
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
> 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
On Thu, 29 Apr 2010 16:31:11 + Jukka Ruohonen 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
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
> Module Name: src > Committed By: dyoung > Date: Fri Jan 22 20:11:16 UTC 2010 > > Added Files: > src/share/man/man9: percpu.9 > > Log Message: > Add a manual page for per-CPU storage. Somebody should read this to > make sure I've described it correctly and intelligibly. looks good to me. thanks. YAMAMOTO Takashi > > TBD: hook this up in the Makefile and in the set lists. > > > To generate a diff of this commit: > cvs rdiff -u -r0 -r1.1 src/share/man/man9/percpu.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
Please revert this. If anything, the various names should result in MLINKS, but they should be kept. Joerg On Tue, Jan 26, 2010 at 09:50:57PM +, Jukka Ruohonen wrote: > Module Name: src > Committed By: jruoho > Date: Tue Jan 26 21:50:57 UTC 2010 > > Modified Files: > src/share/man/man9: pmf.9 > > Log Message: > Give it a single name; it is sufficient to list the functions in the SYNOPSIS. > > > To generate a diff of this commit: > cvs rdiff -u -r1.14 -r1.15 src/share/man/man9/pmf.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
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
On Jan 25, 2010, at 1:33 PM, Jukka Ruohonen wrote: > 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. At least for the "button" drivers above, it is used to interface with the sysmon_power framework (power button events, etc.) -- thorpej
Re: CVS commit: src/share/man/man9
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
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
On Wed, 2 Sep 2009, Thomas Klausner wrote: Date: Wed, 2 Sep 2009 13:32:54 +0200 From: Thomas Klausner 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
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
Re: CVS commit: src/share/man/man9
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/
Re: CVS commit: src/share/man/man9
On Thu, Apr 02, 2009 at 08:55:36PM -0700, Tom Spindler wrote: > > src/share/man/man9: scsipi.9 > > Continue my crusade - queueing -> queuing > > A crusade against British English? That's British English? Well I'll be damned. Anyway, the reason I changed it is because the ATA-7 standard and Intel/Seagate Native Command Queuing paper uses the "queuing" form of the word.
Re: CVS commit: src/share/man/man9
> src/share/man/man9: scsipi.9 > Continue my crusade - queueing -> queuing A crusade against British English?
Re: CVS commit: src/share/man/man9
On Tue, Mar 17, 2009 at 11:57:14AM +0200, Alan Barrett wrote: > On Tue, 17 Mar 2009, Joerg Sonnenberger wrote: > > Knowing in advance the number of columns is important if you want to do > > proper markup for anything not tab-bound. > > I see sense both in what you and Uwe are saying. Could we resolve it > by adding a magic "-fill" argument to mark a final column that should > use up the remainder of the page width? For example, for a three column > table in which the first two columns have fixed width and the last > column fills the remainder of the page, use > > .Bl -column "FIRST" "SECOND" -fill > > If you just teach groff-mdoc to ignore the "-fill" argument, then I > think it will do the right thing. You'd have to tech mdocml to handle > -fill explicitly. > > This also leaves the door open for a future enhancement to allow "-fill" > somewhere other than the last column. I like that idea. Thomas
