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

[Valery Ushakov]

On Wed, Feb 08, 2023 at 12:09:54 -0500, David H. Gutteridge wrote:


> > In postscript output Pq has different spacing than literal () (in
> > other entries around it).
> 
> I wondered if there could be a difference. Which format do you prefer?
> (My inclination would just be to use literal parentheses, being less
> effort.)

The correct markup is to use .Vt for the type and I've grown to like
Pq to give the text inside the parens a bit of breathing space, so I'd
say Pq Vt u_int

But don't waste your time on this.  I'll try to give this man page a
cleanup this weekend when I have more time.

-uwe

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

[David H. Gutteridge]

On Wed, 2023-02-08 at 01:18 +0300, Valery Ushakov wrote:
> On Tue, Feb 07, 2023 at 01:17:41 +, David H. Gutteridge wrote:
> 
> > Module Name:src
> > Committed By:   gutteridge
> > Date:   Tue Feb  7 01:17:41 UTC 2023
> > 
> > Modified Files:
> > src/share/man/man4: bpf.4
> > 
> > Log Message:
> > bpf.4: fix a garbled item heading
> > 
> > Make the BIOCSDIRECTION & BIOCGDIRECTION entry like those around it.
> 
> In postscript output Pq has different spacing than literal () (in
> other entries around it).

I wondered if there could be a difference. Which format do you prefer?
(My inclination would just be to use literal parentheses, being less
effort.)

Regards,

Dave

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

[Valery Ushakov]

On Tue, Feb 07, 2023 at 01:17:41 +, David H. Gutteridge wrote:

> Module Name:  src
> Committed By: gutteridge
> Date: Tue Feb  7 01:17:41 UTC 2023
> 
> Modified Files:
>   src/share/man/man4: bpf.4
> 
> Log Message:
> bpf.4: fix a garbled item heading
> 
> Make the BIOCSDIRECTION & BIOCGDIRECTION entry like those around it.

In postscript output Pq has different spacing than literal () (in other
entries around it).

-uwe

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

[Tetsuya Isaki]

At Fri, 12 Mar 2021 08:03:24 +,
Nia Alarie wrote:
> Committed By: nia
> Date: Fri Mar 12 08:03:24 UTC 2021
> 
> Modified Files:
>   src/share/man/man4: hdaudio.4
> 
> Log Message:
> Clarify problem.
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.18 -r1.19 src/share/man/man4/hdaudio.4

> @@ -133,5 +133,8 @@
:
> +but these will be converted down to 16-bit before output,  because converting
> +to a hardware precision that isn't a power of two is not yet handled.

This looks incorrect.

MI audio layer synthesizes all streams coming from userland in 16bit,
even if the userland stream has precision higher than 16bit.
MI audio layer can and does handle any precision of underlying
hardware.  For example, the hardware of vraiu(4) on hpcmips (probably)
accepts only 10bit, the hardware of mavb(4) on sgimips (probably)
accepts only 24bit.
If the hardware supports 16bit precision and one or more precision
higher than 16bit like hdafg(4), I think that there is no or less
advantage for MD drivers to choice/support the precision higher than
16bit.

Thanks,
---
Tetsuya Isaki 

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

[nia]

On Fri, Mar 12, 2021 at 05:02:00PM +1100, matthew green wrote:
> > Modified Files:
> > src/share/man/man4: hdaudio.4
> >
> > Log Message:
> > Mention that formats with >16-bit precision cannot yet be used
> 
> i'm not near a system to test right now, but when i added
> support for floating point WAVE files to audioplay, i've
> converted from float32 or float64 to signed 32 bit integer,
> and then played the 32 bit values... so this does work, or
> at least, to worked for me with netbsd-9 + audio/play/play.c
> rev 1.59 back in november 2019.
> 
> 
> .mrg.

The MI audio driver converts 32-bit samples back down to 16-bits
before they're output to hdaudio because hdaudio only supports
>16-bit formats that aren't a power of two, and the audio layer
doesn't handle this.

I'll clarify the text.

re: CVS commit: src/share/man/man4

[matthew green]

> Modified Files:
>   src/share/man/man4: hdaudio.4
>
> Log Message:
> Mention that formats with >16-bit precision cannot yet be used

i'm not near a system to test right now, but when i added
support for floating point WAVE files to audioplay, i've
converted from float32 or float64 to signed 32 bit integer,
and then played the 32 bit values... so this does work, or
at least, to worked for me with netbsd-9 + audio/play/play.c
rev 1.59 back in november 2019.


.mrg.

re: CVS commit: src/share/man/man4/man4.i386

[matthew green]

"Nia Alarie" writes:
> Module Name:  src
> Committed By: nia
> Date: Fri Feb 26 10:56:48 UTC 2021
>
> Modified Files:
>   src/share/man/man4/man4.i386: intro.4
>
> Log Message:
> Remove extremely outdated list of supported devices

be nice to have a link to isa(4), eisa(4), and pci(4), and any
other relevant bus-manuals i can't think of right now, since i
now won't find eg, sb(4) via i386/intro(4) and hyper links.

thanks.


.mrg.

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

[Valery Ushakov]

On Tue, Aug 25, 2020 at 10:03:28 +0900, Ryo ONODERA wrote:

> Valery Ushakov  writes:
> 
> > On Mon, Aug 24, 2020 at 19:27:36 +, Ryo ONODERA wrote:
> >
> >> Module Name:   src
> >> Committed By:  ryoon
> >> Date:  Mon Aug 24 19:27:36 UTC 2020
> >> 
> >> Modified Files:
> >>src/share/man/man4: viomb.4
> >> 
> >> Log Message:
> >> Add a missing comma
> >> 
> >> And bump date.
> >
> > I don't think minor edits like this require a date bump.
> >
> > I'd say, the date bump is needed only for significant changes like
> > adding or removing an option, or may be doing a large edit that
> > changes the way the information is presented.
> 
> Sorry.
> It makes sense.
> Should I revert the date changes?

Oh, no need.  It's not like we are running out of dates :)

Thanks.

-uwe

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

[Ryo ONODERA]

Hi,

Valery Ushakov  writes:

> On Mon, Aug 24, 2020 at 19:27:36 +, Ryo ONODERA wrote:
>
>> Module Name: src
>> Committed By:ryoon
>> Date:Mon Aug 24 19:27:36 UTC 2020
>> 
>> Modified Files:
>>  src/share/man/man4: viomb.4
>> 
>> Log Message:
>> Add a missing comma
>> 
>> And bump date.
>
> I don't think minor edits like this require a date bump.
>
> I'd say, the date bump is needed only for significant changes like
> adding or removing an option, or may be doing a large edit that
> changes the way the information is presented.

Sorry.
It makes sense.
Should I revert the date changes?

> -uwe

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

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

[Valery Ushakov]

On Mon, Aug 24, 2020 at 19:27:36 +, Ryo ONODERA wrote:

> Module Name:  src
> Committed By: ryoon
> Date: Mon Aug 24 19:27:36 UTC 2020
> 
> Modified Files:
>   src/share/man/man4: viomb.4
> 
> Log Message:
> Add a missing comma
> 
> And bump date.

I don't think minor edits like this require a date bump.

I'd say, the date bump is needed only for significant changes like
adding or removing an option, or may be doing a large edit that
changes the way the information is presented.

-uwe

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

[maya]

On Fri, Apr 10, 2020 at 07:16:24AM -0700, Jason Thorpe wrote:
> 
> > On Apr 10, 2020, at 4:44 AM, m...@netbsd.org  wrote:
> > 
> > I had to stop using m_defrag because implementation details broke
> > bwfm@pci. It can only handle a chain of length 1, and m_defrag gives
> > a minimum of 2.
> 
> Exactly.  If it can compact the packet into a single cluster mbuf, it should 
> do so.  It makes it slightly more difficult to use correctly, but those would 
> be better semantics.
> 
> -- thorpej
> 

At the time people brought up freebsd m_collapse or pre-allocating and
using m_copydata. I haven't tried either, and bwfm@pci stopped working
entirely for me anyway.

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

[Jason Thorpe]

> On Apr 10, 2020, at 4:44 AM, m...@netbsd.org  wrote:
> 
> I had to stop using m_defrag because implementation details broke
> bwfm@pci. It can only handle a chain of length 1, and m_defrag gives
> a minimum of 2.

Exactly.  If it can compact the packet into a single cluster mbuf, it should do 
so.  It makes it slightly more difficult to use correctly, but those would be 
better semantics.

-- thorpej

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

[maya]

On Fri, Apr 10, 2020 at 11:19:02AM +0900, SAITOH Masanobu wrote:
> On 2020/04/10 2:42, David Young wrote:
> > On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote:
> > > On 2020/04/09 11:08, David Young wrote:
> > > > On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:
> > > > > on I219 I observe about 35% transmit performance drop when tso4 
> > > > > enabled
> > > > 
> > > > This sounds familiar.  There was a bug affecting TCP segmentation
> > > > offload (I think) that we found at CoyotePoint.  ISTR
> > > > bus_dmamap_load_mbuf(9) failed with EFBIG because under some
> > > > circumstances the number of segments in the DMA map was too small
> > > > for the mbuf chain.  The driver would drop the whole mbuf chain
> > > > on the floor.  This showed up as terrible performance under some
> > > > circumstances---possibly when the TCP window grew long?  The solution
> > > > was to increase the number of DMA segments, *I think*.
> > > 
> > > m_defrag() was added to -current in September 2018, and 9.0,
> > > 8.1, post 7.2 have this code.
> > 
> > Thank you, that's just the change I was thinking of.
> 
> You're welcome.
> Some drivers still have no m_defrag() code, so we should add it
> to them().


I had to stop using m_defrag because implementation details broke
bwfm@pci. It can only handle a chain of length 1, and m_defrag gives
a minimum of 2.

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

[Jason Thorpe]

> On Apr 9, 2020, at 7:19 PM, SAITOH Masanobu  wrote:
> 
> You're welcome.
> Some drivers still have no m_defrag() code, so we should add it
> to them().

Others do something different than m_defrag() do essentially the same effect.  
Personally, I am not a huge fan of the m_defrag() API.

-- thorpej

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

[SAITOH Masanobu]

On 2020/04/10 2:42, David Young wrote:

On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote:

On 2020/04/09 11:08, David Young wrote:

On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:

on I219 I observe about 35% transmit performance drop when tso4 enabled


This sounds familiar.  There was a bug affecting TCP segmentation
offload (I think) that we found at CoyotePoint.  ISTR
bus_dmamap_load_mbuf(9) failed with EFBIG because under some
circumstances the number of segments in the DMA map was too small
for the mbuf chain.  The driver would drop the whole mbuf chain
on the floor.  This showed up as terrible performance under some
circumstances---possibly when the TCP window grew long?  The solution
was to increase the number of DMA segments, *I think*.


m_defrag() was added to -current in September 2018, and 9.0,
8.1, post 7.2 have this code.


Thank you, that's just the change I was thinking of.


You're welcome.
Some drivers still have no m_defrag() code, so we should add it
to them().


Dave




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[David Young]

On Thu, Apr 09, 2020 at 03:25:32PM +0900, SAITOH Masanobu wrote:
> On 2020/04/09 11:08, David Young wrote:
> > On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:
> > > on I219 I observe about 35% transmit performance drop when tso4 enabled
> > 
> > This sounds familiar.  There was a bug affecting TCP segmentation
> > offload (I think) that we found at CoyotePoint.  ISTR
> > bus_dmamap_load_mbuf(9) failed with EFBIG because under some
> > circumstances the number of segments in the DMA map was too small
> > for the mbuf chain.  The driver would drop the whole mbuf chain
> > on the floor.  This showed up as terrible performance under some
> > circumstances---possibly when the TCP window grew long?  The solution
> > was to increase the number of DMA segments, *I think*.
> 
> m_defrag() was added to -current in September 2018, and 9.0,
> 8.1, post 7.2 have this code.

Thank you, that's just the change I was thinking of.

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981

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

[SAITOH Masanobu]

Hi.

On 2020/04/09 11:08, David Young wrote:

On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:

Module Name:src
Committed By:   jdolecek
Date:   Wed Apr  8 23:01:52 UTC 2020

Modified Files:
src/share/man/man4: wm.4

Log Message:
add a warning in checksum offload that hardware TCP segmentation might be
slow

on I219 I observe about 35% transmit performance drop when tso4 enabled


This sounds familiar.  There was a bug affecting TCP segmentation
offload (I think) that we found at CoyotePoint.  ISTR
bus_dmamap_load_mbuf(9) failed with EFBIG because under some
circumstances the number of segments in the DMA map was too small
for the mbuf chain.  The driver would drop the whole mbuf chain
on the floor.  This showed up as terrible performance under some
circumstances---possibly when the TCP window grew long?  The solution
was to increase the number of DMA segments, *I think*.

I don't think CoyotePoint ever fed its change back to NetBSD,
unfortunately.  On the other hand, some other NetBSDer may have
independently fixed the bug.

Do any stats increase (vmstat -e, ifconfig -v wm0) when the poor
performance occurs? You may have to enable WM_DEBUG or something to see
all of the relevant stats.


m_defrag() was added to -current in September 2018, and 9.0,
8.1, post 7.2 have this code.


http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_wm.c.diff?r1=1.586=1.587=date=h

The driver has wmX txqYYtoomanyseg event counter, so we can check it
by enabling "options WM_EVENT_COUNTERS". The counter is disabled by
default.


Dave




--
---
SAITOH Masanobu (msai...@execsw.org
 msai...@netbsd.org)

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

[David Young]

On Wed, Apr 08, 2020 at 11:01:52PM +, Jaromir Dolecek wrote:
> Module Name:  src
> Committed By: jdolecek
> Date: Wed Apr  8 23:01:52 UTC 2020
> 
> Modified Files:
>   src/share/man/man4: wm.4
> 
> Log Message:
> add a warning in checksum offload that hardware TCP segmentation might be
> slow
> 
> on I219 I observe about 35% transmit performance drop when tso4 enabled

This sounds familiar.  There was a bug affecting TCP segmentation
offload (I think) that we found at CoyotePoint.  ISTR
bus_dmamap_load_mbuf(9) failed with EFBIG because under some
circumstances the number of segments in the DMA map was too small
for the mbuf chain.  The driver would drop the whole mbuf chain
on the floor.  This showed up as terrible performance under some
circumstances---possibly when the TCP window grew long?  The solution
was to increase the number of DMA segments, *I think*.

I don't think CoyotePoint ever fed its change back to NetBSD,
unfortunately.  On the other hand, some other NetBSDer may have
independently fixed the bug.

Do any stats increase (vmstat -e, ifconfig -v wm0) when the poor
performance occurs? You may have to enable WM_DEBUG or something to see
all of the relevant stats.

Dave

-- 
David Young
dyo...@pobox.comUrbana, IL(217) 721-9981

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

[Tetsuya Isaki]

At Mon, 16 Mar 2020 09:20:01 +,
Nia Alarie wrote:
> Committed By: nia
> Date: Mon Mar 16 09:20:01 UTC 2020
> 
> Modified Files:
>   src/share/man/man4: audio.4
> 
> Log Message:
> audio.4: O_NONBLOCK isn't the actual problem

> @@ -818,6 +818,8 @@
> .Xr mmap 2
> it is currently always mapped for writing (playing) due to VM system 
> weirdness.
> .Sh CAVEATS
>-The audio device cannot be reliably used with O_NONBLOCK or event notification
>-mechanisms. Users are generally expected to only read and write a limited 
>number
>-of samples at a time, limiting the time spent in the system call. 
>+The audio device cannot be reliably used with event notification mechanisms
>+such as
>+.Xr poll 2 .
>+Most users are expected to only read and write a limited number of samples at
>+a time, limiting the time spent in the system call. 

What problem of poll() are you talking about?
---
Tetsuya Isaki 

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

[Tetsuya Isaki]

At Tue, 17 Mar 2020 10:50:59 +,
Nia Alarie wrote:
> Module Name:  src
> Committed By: nia
> Date: Tue Mar 17 10:50:59 UTC 2020
> 
> Modified Files:
>   src/share/man/man4: audio.4
> 
> Log Message:
> audio.4: 1-12 channels are only universally supported for playback.
> 
> When a mono recording device is set to use 1 channel, the kernel will
> correct the number of channels back down to 1. This information can be
> obtained with AUDIO_GETINFO...

Please revert and send a bug report if so.
---
Tetsuya Isaki 

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

[Radoslaw Kujawa]

Sorry about that!

Best regards,
Radoslaw

> On 27 Jul 2018, at 18:12, Andreas Gustafsson  wrote:
> 
> Module Name:  src
> Committed By: gson
> Date: Fri Jul 27 16:12:40 UTC 2018
> 
> Modified Files:
>   src/share/man/man4: Makefile
> 
> Log Message:
> Add missing backslash to unbreak the build
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.659 -r1.660 src/share/man/man4/Makefile
> 
> 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/man4/Makefile
> diff -u src/share/man/man4/Makefile:1.659 src/share/man/man4/Makefile:1.660
> --- src/share/man/man4/Makefile:1.659 Fri Jul 27 12:02:26 2018
> +++ src/share/man/man4/Makefile   Fri Jul 27 16:12:40 2018
> @@ -1,4 +1,4 @@
> -#$NetBSD: Makefile,v 1.659 2018/07/27 12:02:26 rkujawa Exp $
> +#$NetBSD: Makefile,v 1.660 2018/07/27 16:12:40 gson Exp $
> # @(#)Makefile8.1 (Berkeley) 6/18/93
> 
> MAN=  aac.4 ac97.4 acardide.4 aceride.4 acphy.4 \
> @@ -61,7 +61,7 @@ MAN=aac.4 ac97.4 acardide.4 aceride.4 a
>   sm.4 smsh.4 sn.4 sony.4 spc.4 speaker.4 spif.4 sqphy.4 ss.4 \
>   st.4 ste.4 stge.4 sti.4 stpcide.4 sv.4 strip.4 \
>   svwsata.4 swsensor.4 swwdog.4 sysmon.4 \
> - tap.4 tc.4 tcds.4 tcp.4 tcu.4 tdvfb.4 tea5767radio.4 termios.4 tfb.4
> + tap.4 tc.4 tcds.4 tcp.4 tcu.4 tdvfb.4 tea5767radio.4 termios.4 tfb.4 \
>   thinkpad.4 ti.4 tl.4 tlp.4 tlphy.4 tpm.4 tprof.4 tr.4 tra.4 \
>   trm.4 tsllux.4 tty.4 tun.4 tqphy.4 twa.4 twe.4 txp.4 \
>   uark.4 ubsec.4 udp.4 uep.4 ug.4 uha.4 uk.4 ukphy.4 unix.4 userconf.4 \
> 

re: CVS commit: src/share/man/man4/man4.macppc

[matthew green]

Sevan Janiyan writes:
> The address is still valid, in that emails to this address do not bounce.

i don't think we should published other people's email addresses,
even if they are @netbsd.org.

if someone does that themselves it should be kept, but please don't
put (my) email address in such a spam-findable place.


.mrg.

Re: CVS commit: src/share/man/man4/man4.macppc

[Sevan Janiyan]

The address is still valid, in that emails to this address do not bounce.


Sevan

Re: CVS commit: src/share/man/man4/man4.macppc

[Radoslaw Kujawa]

Hi.

> +.An Tsubai Masanari Aq Mt tsu...@netbsd.org

Tsubai is inactive, according to status file his account is suspended. Will 
anyone be able to reach him via this address? If not, then I am not sure if 
retroactively adding his address makes sense.

Best regards,
Radoslaw




signature.asc
Description: Message signed with OpenPGP

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

[Christos Zoulas]

In article <20180217011307.7ca55f...@cvs.netbsd.org>,
Sevan Janiyan  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  sevan
>Date:  Sat Feb 17 01:13:07 UTC 2018
>
>Modified Files:
>   src/share/man/man4: ddb.4
>
>Log Message:
>document dumpstack variable.
>Sort built-in variables alphabetically.

This needs to be documented in sysctl.7 too.

christos

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

[Christos Zoulas]

In article <20180217021101.1123ef...@cvs.netbsd.org>,
Sevan Janiyan  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  sevan
>Date:  Sat Feb 17 02:11:00 UTC 2018
>
>Modified Files:
>   src/share/man/man4: options.4
>
>Log Message:
>Remove mention of DDB_ONPANIC=2, ddb.dumpstack which is enabled by
>default now handles back traces on panic.

This is still true, right? Why remove it?

christos

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

[Kengo NAKAHARA]

Hi,

On 2018/02/07 19:12, m...@netbsd.org wrote:
> Hi!
> 
> Please give credit in the future.
> 
> It can be very important for a new contributor, I used to show my
> friends, "look, I made this change, and it says I did it!" and it was
> very cool.
> 
> Even though they were small contributions, they were my biggest
> contributions.
> 
> (For example:
> Mention jumbo frame support.
> From David H. Gutteridge in PR misc/52890)

Sorry, I update the commit message. And I will be careful in future.


Thanks,

-- 
//
Internet Initiative Japan Inc.

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

Kengo NAKAHARA 

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

[maya]

Hi!

Please give credit in the future.

It can be very important for a new contributor, I used to show my
friends, "look, I made this change, and it says I did it!" and it was
very cool.

Even though they were small contributions, they were my biggest
contributions.

(For example:
Mention jumbo frame support.
>From David H. Gutteridge in PR misc/52890)

Thanks.

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

[Erik Fair]

These features, e.g. VLAN, Jumbo Frames, CRC offload, interrupt coalescing, 
should really be listed in the man page for each network interface device (and 
driver) that supports them (e.g. bge(4), wm(4), tlp(4), le(4)), along with any 
device-specific implementation bugs or caveats, and then the vlan(4) (and 
other) pages that describe these functions should be linked from those device 
driver pages.

Erik Fair


> On May 28, 2017, at 20:41, Ryota Ozaki  wrote:
> 
> Module Name:  src
> Committed By: ozaki-r
> Date: Mon May 29 03:41:54 UTC 2017
> 
> Modified Files:
>   src/share/man/man4: vlan.4
> 
> Log Message:
> Remove unmaintained (and probably unmaintainable) driver list
> 
> ok msaitoh@
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.34 -r1.35 src/share/man/man4/vlan.4
> 
> 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/man4

[Christos Zoulas]

In article ,
Paul Goyette   wrote:
>
>Yeah, this is workable, even if it is a HACK !  :)
>
>The attached patch borrows extensively from fd_free() routine in 
>kern/kern_descrip.c
>
>Let me know if this looks "good enough" and I will commit it.  (I'll 
>also update the BUGS section of the man-page to describe the hack.)
>
>FWIW, I have tested with log-file fd values of 1 and 4, while the 
>/dev/filemon fd is always 3.  In the "1" case the patch correctly 
>returned EINVAL (it would cause a deadlock), while the "4" case 
>succeeded and no deadlock occurred.

As a temporary hack it is probably good enough. Longer term filemon
should be removed/rewritten, and the close ordering problem should
be handled.

christos

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

[Christos Zoulas]

In article ,
Christos Zoulas  wrote:
>
>As a temporary hack it is probably good enough. Longer term filemon
>should be removed/rewritten, and the close ordering problem should
>be handled.

I changed my mind; it does not help because one can always dup2
that file descriptor later to a lower fd and cause trouble. It is
also confusing to the user. So it is really not a worthwhile hack
to put. Perhaps a better hack is to have a filemon_disestablish
hook at process exit that does the preliminary cleanup.

christos

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

[Taylor R Campbell]

   Date: Wed, 6 Jan 2016 12:00:32 +0800 (PHT)
   From: Paul Goyette 

   On Wed, 6 Jan 2016, Paul Goyette wrote:

   > Hmmm.  I'm looking at the filemon_open() code.  It seems to have a "fd" 
   > variable that gets set by fd_allocfile().  The value is later passed to 
   > fd_clone() (NOT fd_clone() - two different routines, apparently!).
  ^^
 should say   fdclone(9)

   Too much confusion in routine names here!

fdclone no longer exists -- it was renamed fd_clone in 2008
(kern_descrip.c rev. 1.173), and the lwp argument was removed.  The
man page should be updated.

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

[Paul Goyette]

On Wed, 6 Jan 2016, Christos Zoulas wrote:


As a temporary hack it is probably good enough. Longer term filemon
should be removed/rewritten, and the close ordering problem should
be handled.


I think that a "better" approach here is probably to remove filemon(4)'s 
SET_FD ioctl (for the log_file fd) completely, and use the fd on which 
/dev/filemon is open to deliver the activity/event records.  But this 
will reduce performance, as each activity would require two transitions 
over the kernel/user-land boundary (one to deliver the data to the 
monitoring application, and another one to store the data somewhere).



I changed my mind; it does not help because one can always dup2
that file descriptor later to a lower fd and cause trouble. It is
also confusing to the user. So it is really not a worthwhile hack
to put. Perhaps a better hack is to have a filemon_disestablish
hook at process exit that does the preliminary cleanup.


Yep, the user could always shoot himself (and the system) in the foot!

Let me see if I can come up with a exit_cleanup() implementation that is 
sufficiently clean as to be acceptable.



+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++

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

[Paul Goyette]

On Tue, 5 Jan 2016, Christos Zoulas wrote:


| Unless I can reliably determine which fd the program is using for its
| access to /dev/filemon I don't have anything to which I can compare the
| requested activity_log fd.

You could scan the whole fd array and look for DT_MISC with fops ==
filemon ops and if you find one that would cause a deadlock, deny.
Again this is a hack... But at least it should prevent the deadlock.


Yeah, this is workable, even if it is a HACK !  :)

The attached patch borrows extensively from fd_free() routine in 
kern/kern_descrip.c


Let me know if this looks "good enough" and I will commit it.  (I'll 
also update the BUGS section of the man-page to describe the hack.)


FWIW, I have tested with log-file fd values of 1 and 4, while the 
/dev/filemon fd is always 3.  In the "1" case the patch correctly 
returned EINVAL (it would cause a deadlock), while the "4" case 
succeeded and no deadlock occurred.




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+--+--++Index: filemon.c
===
RCS file: /cvsroot/src/sys/dev/filemon/filemon.c,v
retrieving revision 1.24
diff -u -p -r1.24 filemon.c
--- filemon.c   5 Jan 2016 22:08:54 -   1.24
+++ filemon.c   6 Jan 2016 05:05:04 -
@@ -279,8 +279,12 @@ static int
 filemon_ioctl(struct file * fp, u_long cmd, void *data)
 {
int error = 0;
+   int i, nf, fd;
struct filemon *filemon;
struct proc *tp;
+   fdfile_t *ff;
+   filedesc_t *fdp;
+   fdtab_t *dt;
 
 #ifdef DEBUG
log(logLevel, "filemon_ioctl(%lu)", cmd);;
@@ -303,8 +307,41 @@ filemon_ioctl(struct file * fp, u_long c
if (filemon->fm_fp)
fd_putfile(filemon->fm_fd);
 
+   /*
+* XXX HACK XXX
+*
+* Due to our taking an extra reference on the
+* descriptor's struct file, we need to ensure that
+* the descriptor number is at least as large as
+* the one used to access /dev/filemon.  Otherwise,
+* we get a deadlock during process exit, waiting
+* for the output file's reference count.
+*/
+   fd = *((int *) data);
+   fdp = curproc->p_fd;
+   dt = curlwp->l_fd->fd_dt;
+   nf = dt->dt_nfiles;
+   error = EINVAL;
+   for (i = 0; i < nf; i++) {
+   if (i >= fd)
+   break;
+   ff = dt->dt_ff[i];
+   KASSERT(fd >= NDFDFILE ||
+   ff == (fdfile_t *)fdp->fd_dfdfile[i]);
+   if (ff == NULL)
+   continue;
+
+   if (ff->ff_file->f_type == DTYPE_MISC &&
+   ff->ff_file->f_ops == _fileops) {
+   error = 0;
+   break;
+   }
+   }
+   if (error)
+   break;
+
/* Now set up the new one */
-   filemon->fm_fd = *((int *) data);
+   filemon->fm_fd = fd;
if ((filemon->fm_fp = fd_getfile(filemon->fm_fd)) == NULL) {
error = EBADF;
break;

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

[Christos Zoulas]

On Jan 6, 11:58am, p...@vps1.whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/share/man/man4

| Hmmm.  I'm looking at the filemon_open() code.  It seems to have a "fd" 
| variable that gets set by fd_allocfile().  The value is later passed to 
| fd_clone() (NOT fd_clone() - two different routines, apparently!).
| 
| The value inside filemon_open() is 4, but when the application program 
| prints its returned value from open() it has fd #3.
| 
| Unless I can reliably determine which fd the program is using for its 
| access to /dev/filemon I don't have anything to which I can compare the 
| requested activity_log fd.

You could scan the whole fd array and look for DT_MISC with fops ==
filemon ops and if you find one that would cause a deadlock, deny.
Again this is a hack... But at least it should prevent the deadlock.

christos

Re: CVS commit: src/share/man/man4/man4.amiga

[Radoslaw Kujawa]

On 9 Aug 2013, at 5:35 PM, Paul Goyette pgoye...@netbsd.org wrote:

 Module Name:  src
 Committed By: pgoyette
 Date: Fri Aug  9 15:35:54 UTC 2013
 
 Modified Files:
   src/share/man/man4/man4.amiga: Makefile
 
 Log Message:
 Make the xsh man pages to unbreak the build (sets lists were updated to
 expect these man pages, but they were not being built)

Thanks, I've actually modified the Makefile but forgot to commit it…

-- 
Best regards,
Radoslaw Kujawa





signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[David Holland]

On Sat, Jun 23, 2012 at 07:14:35PM +, David Brownlee wrote:
  Modified Files:
   src/share/man/man4: cd.4
  
  Log Message:
  Document DIOCTUR (test unit ready)

So, if your CD's unwell, what do you do? Call the DIOCTUR!

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

Re: CVS commit: src/share/man/man4/man4.x86

[Jukka Ruohonen]

On Tue, Oct 18, 2011 at 02:25:06PM +, Thomas Klausner wrote:
 Module Name:  src
 Committed By: wiz
 Date: Tue Oct 18 14:25:06 UTC 2011
 
 Modified Files:
   src/share/man/man4/man4.x86: vmt.4
 
 Log Message:
 Fix xref; comment out cpu(4) reference, does not exist.

We could write one though... If nothing else, to list the things that
attach to CPUs via autoconf(9).

- Jukka.

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

[David Holland]

On Tue, Aug 30, 2011 at 07:44:17PM +0300, Jukka Ruohonen wrote:
   And why should GENERIC *not* support hardware that is available, works,
   and is of use to someone?  If GENERIC is to support only the idea of
   what an OS should look for some developers, why do we ship GENERIC at
   all and not tell folks to create their own kernels?
  
  I don't disagree on principle.[1] But sooner or later you end up with
  tremendous amount legacy stuff and things that 0.001 % of people use.
  And then people go and compile their own kernels because of that.

The purpose of GENERIC is (and has been since before Linux was
invented) to include all drivers and features that can reasonably be
expected to work. Drivers and other code that are commented out in
GENERIC (or not present at all) will be assumed to not work. Users and
sysadmins know this. Trying to retrain them all is futile.

There are all sorts of possible ways to address the problem you're
concerned about that don't involve changing around longstanding
conventions.

  Do you think Linux distributions ship kernels with all their drivers
  compiled into one monolithic unit? And why not?

The fact that Linux has always done this wrong is not a reason to go
chasing after them and reinventing their mistakes.

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

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

[Jukka Ruohonen]

On Wed, Sep 07, 2011 at 09:24:22AM +, David Holland wrote:
 The purpose of GENERIC is (and has been since before Linux was
 invented) to include all drivers and features that can reasonably be
 expected to work. Drivers and other code that are commented out in
 GENERIC (or not present at all) will be assumed to not work. Users and
 sysadmins know this. Trying to retrain them all is futile.

Maybe instead of philosophical argumentation, you could actually look at
the GENERIC configuration files. Most of the things that are commented out
are not because of brokenness but either because these have a limited value
or because there is no plug'n'play or other type of autoconfiguration.

 The fact that Linux has always done this wrong is not a reason to go
 chasing after them and reinventing their mistakes.

As usual, you managed to marvellously miss the point. The reason Linux does
this (right) is the amount of device drivers and other components that
exceed the ones in NetBSD by several factors.

- Jukka.

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

[Joerg Sonnenberger]

On Wed, Sep 07, 2011 at 01:05:18PM +0300, Jukka Ruohonen wrote:
  The fact that Linux has always done this wrong is not a reason to go
  chasing after them and reinventing their mistakes.
 
 As usual, you managed to marvellously miss the point. The reason Linux does
 this (right) is the amount of device drivers and other components that
 exceed the ones in NetBSD by several factors.

I found that a surprisingly large part of that is a result of badly
designed drivers and resulting duplication of code. As such, it is more
a lazy excuse than a good justification for behvaior.

Joerg

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

[Martin Husemann]

On Sat, Sep 03, 2011 at 11:07:36AM +0300, Jukka Ruohonen wrote:
 So if everything is clear and rational, care to explain why for instance
 GATEWAY and IPSEC are commented out?

GATEWAY is not realy needed (add something like net.inet.ip.forwarding=1 to
/etc/sysctl.conf), IPSEC supposedly has a serious performance impact, even
if not used (which I'd consider a bug).

Martin

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

[John Nemeth]

On Jan 20,  1:58pm, Jukka Ruohonen wrote:
} On Tue, Aug 30, 2011 at 10:10:05AM -0500, David Young wrote:
}  
}  The driver should be converted, however, I don't think that there is
}  a case for bluntly removing bktr(4), 
} 
} Yes, I was corrected already (the conversion should go towards video(4)).
} 
} But as always, it is about picking the good defaults for GENERIC.

 In NetBSD, GENERIC kernels generally contain everything that could
possibly be useful and doesn't cause problems (some newer drivers are
buggy, some interfere with other devices, and some have caused damage
to hardware).  This means the question is very simple:  is the driver
brand new, or does it cause problems in some way?  If the answer is no
to both questions, then the driver is included; there are no other
factors to the decision.  Note that cause problems in some way does
not include consuming resources such as wired kernel memory.

}-- End of excerpt from Jukka Ruohonen

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

[Jukka Ruohonen]

On Fri, Sep 02, 2011 at 11:23:08PM -0700, John Nemeth wrote:
  In NetBSD, GENERIC kernels generally contain everything that could
 possibly be useful and doesn't cause problems (some newer drivers are
 buggy, some interfere with other devices, and some have caused damage
 to hardware).  This means the question is very simple:  is the driver
 brand new, or does it cause problems in some way?  If the answer is no
 to both questions, then the driver is included; there are no other
 factors to the decision.  Note that cause problems in some way does
 not include consuming resources such as wired kernel memory.

So if everything is clear and rational, care to explain why for instance
GATEWAY and IPSEC are commented out? And as said, my drivers will be an
exception.

- Jukka.

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

[David Sainty]

Martin Husemann mar...@duskware.de wrote:

On Tue, Aug 30, 2011 at 01:31:50PM +0100, Matthias Scheler wrote:
 It is supported by pkgsrc/multimedia/fxtv which the last time I had
 an analog TV feed worked well enough to watch TV.

Just curious: are there analog TV feeds out there, anywhere, still?


New Zealand, for not much longer.

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

[Matthias Scheler]

On Tue, Aug 30, 2011 at 05:58:02AM +, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Tue Aug 30 05:58:02 UTC 2011
 
 Modified Files:
   src/share/man/man4: bktr.4
 
 Log Message:
 Note that bktr(4) is not part of the dtv(4) infrastructure.
 
 XXX: This driver should be converted (or even bluntly removed, given the
  lack of general third-party software support).

It is supported by pkgsrc/multimedia/fxtv which the last time I had
an analog TV feed worked well enough to watch TV.

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/

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

[Jukka Ruohonen]

On Tue, Aug 30, 2011 at 03:42:34PM +0300, Jukka Ruohonen wrote:
 mplayer, MythTV, VDR, Kaffeine, VLC, Totem, you name it -- won't work.

Correction: mplayer may work.

I have couple of these cards and if time permits, I might consider a dtv(4)
rewrite.

- Jukka.

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

[David Young]

On Tue, Aug 30, 2011 at 05:58:02AM +, Jukka Ruohonen wrote:
 Module Name:  src
 Committed By: jruoho
 Date: Tue Aug 30 05:58:02 UTC 2011
 
 Modified Files:
   src/share/man/man4: bktr.4
 
 Log Message:
 Note that bktr(4) is not part of the dtv(4) infrastructure.
 
 XXX: This driver should be converted (or even bluntly removed, given the
  lack of general third-party software support).

Jukka,

The driver should be converted, however, I don't think that there is
a case for bluntly removing bktr(4), yet: the Brooktree devices are
still manufactured, they are still used for CCTV, and they were until
very recently (I reckon, still) supported by programs such as ffmpeg.
A client of mine even shipped a product that relies on the legacy
bktr(4) interface.  So you could say that it is not quite dead yet.

Dave

-- 
David Young OJC Technologies
dyo...@ojctech.com  Urbana, IL * (217) 344-0444 x24

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

[Jukka Ruohonen]

On Tue, Aug 30, 2011 at 10:10:05AM -0500, David Young wrote:
 
 The driver should be converted, however, I don't think that there is
 a case for bluntly removing bktr(4), 

Yes, I was corrected already (the conversion should go towards video(4)).

But as always, it is about picking the good defaults for GENERIC.

- Jukka.

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

[Marc Balmer]

Am 30.08.11 18:22, schrieb Jukka Ruohonen:
 On Tue, Aug 30, 2011 at 10:10:05AM -0500, David Young wrote:

 The driver should be converted, however, I don't think that there is
 a case for bluntly removing bktr(4), 
 
 Yes, I was corrected already (the conversion should go towards video(4)).
 
 But as always, it is about picking the good defaults for GENERIC.

And why should GENERIC *not* support hardware that is available, works,
and is of use to someone?  If GENERIC is to support only the idea of
what an OS should look for some developers, why do we ship GENERIC at
all and not tell folks to create their own kernels?

I find this this-does-not-belong-in-GENERIC attitude of some folks
here quite unreasonable.  We have match and attach in autoconfiguration,
if the hardware is not present, no harm is done.  Oh don't tell me it's
the build time.  I rather think it is just because some folks *think*
that this and that should not be in GENERIC just because *they* don't
use it...

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

[Matthias Scheler]

On Tue, Aug 30, 2011 at 03:42:18PM +0200, Martin Husemann wrote:
 On Tue, Aug 30, 2011 at 01:31:50PM +0100, Matthias Scheler wrote:
  It is supported by pkgsrc/multimedia/fxtv which the last time I had
  an analog TV feed worked well enough to watch TV.
 
 Just curious: are there analog TV feeds out there, anywhere, still?

I thought you can still get (or rather keep) analog Cable TV in Germany.
And you might be able to feed the output of a digital set-top box into
one of these cards as well.

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/

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

[Matthias Scheler]

On Tue, Aug 30, 2011 at 03:42:34PM +0300, Jukka Ruohonen wrote:
   XXX: This driver should be converted (or even bluntly removed, given the
lack of general third-party software support).
  
  It is supported by pkgsrc/multimedia/fxtv which the last time I had
  an analog TV feed worked well enough to watch TV.
 
 Yes, I know there may be few, largely irrelevant (old, non-maintained?),
 programs that may work with it. But the major ones in this field -- be it
 mplayer, MythTV, VDR, Kaffeine, VLC, Totem, you name it -- won't work.
 
 The open source scene in this field has made some big leaps. That's why we
 have dtv(4) and FreeBSD has Cuse4BSD. Old BSD-specific solutions have no
 future.

I'm not argueing with any of that. I actually think it is great that
NetBSD now provides video capture drivers that work with a lot of
third party software.

This is however not related to my comment. The bktr(4) driver allows
users to watch TV with the fxtv package. As long as the driver can
still support that use case and doesn't get in the way of a major
other feature it should be left alone.

The best solution would of course to replace it with a driver for
the new framework. But that might be a lot of work for hardware
which might become obsolete in the near future.

Kind regards

-- 
Matthias Scheler  http://zhadum.org.uk/

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

[Jukka Ruohonen]

On Tue, Aug 30, 2011 at 06:33:18PM +0200, Marc Balmer wrote:
 Am 30.08.11 18:22, schrieb Jukka Ruohonen:
 And why should GENERIC *not* support hardware that is available, works,
 and is of use to someone?  If GENERIC is to support only the idea of
 what an OS should look for some developers, why do we ship GENERIC at
 all and not tell folks to create their own kernels?

I don't disagree on principle.[1] But sooner or later you end up with
tremendous amount legacy stuff and things that 0.001 % of people use.
And then people go and compile their own kernels because of that.

Do you think Linux distributions ship kernels with all their drivers
compiled into one monolithic unit? And why not?

- Jukka.

[1] For years, it was more than annoying that even the installation kernel
lacked e.g. cgd(4). Even today, many *important* things are commented
out, while many inane things from the early 1990s are compiled in.

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

[Marc Balmer]

Am 30.08.11 18:44, schrieb Jukka Ruohonen:
 On Tue, Aug 30, 2011 at 06:33:18PM +0200, Marc Balmer wrote:
 Am 30.08.11 18:22, schrieb Jukka Ruohonen:
 And why should GENERIC *not* support hardware that is available, works,
 and is of use to someone?  If GENERIC is to support only the idea of
 what an OS should look for some developers, why do we ship GENERIC at
 all and not tell folks to create their own kernels?
 
 I don't disagree on principle.[1] But sooner or later you end up with
 tremendous amount legacy stuff and things that 0.001 % of people use.
 And then people go and compile their own kernels because of that.

To address this issue, I think we are slowly moving towards modularized
kernels.  So what I said is about drivers and kernel subsystem, that are
not yet available as modules.  But modules are still WIP, and I think
there are still a few problems left to be solved before we can say we
are an OS with a modular kernel.

 Do you think Linux distributions ship kernels with all their drivers
 compiled into one monolithic unit? And why not?

I don't care what Linux does.  This is BSD.  Memory does not matter.
There is no reason to not include stuff in a kernel.

 
 - Jukka.
 
 [1] For years, it was more than annoying that even the installation kernel
 lacked e.g. cgd(4). Even today, many *important* things are commented
 out, while many inane things from the early 1990s are compiled in.

And when uncomment sth you need, you get yelled at, USE YOUR OWN KERNEL
CONFIG

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

[Jukka Ruohonen]

On Tue, Aug 30, 2011 at 06:51:09PM +0200, Marc Balmer wrote:
 To address this issue, I think we are slowly moving towards modularized
 kernels.  So what I said is about drivers and kernel subsystem, that are
 not yet available as modules.  But modules are still WIP, and I think
 there are still a few problems left to be solved before we can say we
 are an OS with a modular kernel.

Yes, but the problem with legacy drivers and other old subsystems is that
presumably in many cases no one any longer possesses the hardware, and thus
the modularization can not be done safely.

 And when uncomment sth you need, you get yelled at, USE YOUR OWN KERNEL
 CONFIG

Heh, indeed I still need to compile custom kernels to use things like IPSec
or altq(4), whereas all those numerous people with MPU 401 UARTs enjoy their
GENERIC.

- Jukka.

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

[Simon Burge]

Martin Husemann wrote:

 Just curious: are there analog TV feeds out there, anywhere, still?

Some parts of Australia until the end of next year...

Cheers,
Simon.

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

[Jared McNeill]

I have ~70 analog channels coming in along with my digital cable service. 
Canada's digital OTA transition deadline is tomorrow but there are still a 
few markets where analog broadcasting will continue, my hometown being one 
of those places. Somewhere in storage I have a VCR with an RF output. I also 
have a bunch of game consoles, cameras, DVD players, etc with baseband video 
outputs (composite and S-Video).


-Original Message- 
From: Simon Burge
Sent: Tuesday, August 30, 2011 7:06 PM Newsgroups: 
gmane.os.netbsd.devel.cvs.discuss

To: Martin Husemann
Cc: source-changes-d@NetBSD.org
Subject: Re: CVS commit: src/share/man/man4

Martin Husemann wrote:


Just curious: are there analog TV feeds out there, anywhere, still?


Some parts of Australia until the end of next year...

Cheers,
Simon. 

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

[Matt Thomas]

On Aug 30, 2011, at 4:06 PM, Simon Burge wrote:

 Martin Husemann wrote:
 
 Just curious: are there analog TV feeds out there, anywhere, still?
 
 Some parts of Australia until the end of next year...

Quite a few according to 

http://en.wikipedia.org/wiki/List_of_digital_television_deployments_by_country

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

[Jukka Ruohonen]

On Mon, Aug 29, 2011 at 07:19:04AM -0400, Jared McNeill wrote:
 Can you put the driver xrefs back in 'SEE ALSO'? I find it useful.

I prefer personally a clear list instead (particularly if we have more than
10 of these drivers some day).  But sure.

- Jukka.

 -Original Message- 
 From: Jukka Ruohonen
 Sent: Monday, August 29, 2011 6:41 AM Newsgroups: 
 gmane.os.netbsd.devel.cvs.full
 To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org
 Subject: CVS commit: src/share/man/man4
 
 Module Name: src
 Committed By: jruoho
 Date: Mon Aug 29 10:41:10 UTC 2011
 
 Modified Files:
 src/share/man/man4: dtv.4
 
 Log Message:
 Various improvements; e.g. primarily speak about DTV (i.e. DVB is just a
 standard), split out SUPPORTED DEVICES from SEE ALSO, improve grammar, fix
 references, speak about interface instead of device, fix AUTHORS, etc.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/share/man/man4/dtv.4
 
 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/man4/dtv.4
 diff -u src/share/man/man4/dtv.4:1.2 src/share/man/man4/dtv.4:1.3
 --- src/share/man/man4/dtv.4:1.2 Sun Aug 14 20:42:09 2011
 +++ src/share/man/man4/dtv.4 Mon Aug 29 10:41:10 2011
 @@ -1,4 +1,4 @@
 -.\ $NetBSD: dtv.4,v 1.2 2011/08/14 20:42:09 wiz Exp $
 +.\ $NetBSD: dtv.4,v 1.3 2011/08/29 10:41:10 jruoho Exp $
 .\
 .\ Copyright (c) 2011 The NetBSD Foundation, Inc.
 .\ All rights reserved.
 @@ -32,7 +32,7 @@
 .Os
 .Sh NAME
 .Nm dtv
 -.Nd DVB (digital video broadcasting) programming interface
 +.Nd interface for digital television
 .Sh SYNOPSIS
 .Cd dtv* at dtvbus?
 .Pp
 @@ -40,38 +40,63 @@
 .In dev/dtv/dtvio_demux.h
 .In dev/dtv/dtvio_frontend.h
 .Sh DESCRIPTION
 -The
 +The machine-independent
 +.Nm
 +interface provides support for digital television
 +.Pq Dv DTV .
 +A subset of the Linux Digital Video Broadcasting
 +.Pq Dv DVB
 +.Dv APIs
 +is supported.
 +In particular,
 .Nm
 -driver provides support for a subset of the Linux DVB (digital
 -video broadcasting) APIs; in particular,
 +provides the DVB frontend and demodulator
 +.Dv APIs .
 +.Sh SUPPORTED DEVICES
 +The following machine-independent devices are supported:
 +.Bl -tag -width auvitek(4)  -offset indent
 +.It Xr auvitek 4
 +Auvitek AU0828-based video capture cards
 +.It Xr coram 4
 +Hauppauge WinTV-HVR-1250
 +.It Xr xdtv 4
 +Conexant CX2388X-based DTV cards
 +.It Xr emdtv 4
 +EM28XX-based DTV cards
 +.El
 +.Pp
 +Note that the
 .Nm
 -provides the DVB Frontend API and the DVB Demux Device.
 +device drivers are generally only available as kernel modules; see
 +.Xr module 7
 +and
 +.Xr modload 8
 +for additional details.
 .Sh FILES
 .Bl -tag -width 28n
 .It Pa /dev/dvb/adapterN/frontend0
 The frontend device, for controlling the tuner and demodulator hardware.
 .It Pa /dev/dvb/adapterN/demux0
 -The demux device, for controlling the DVB hardware's filters.
 +The demux device, for controlling the hardware filters.
 .It Pa /dev/dvb/adapterN/dvr0
 -Digital video recording device
 +Digital video recording device.
 .El
 .Sh SEE ALSO
 -.Xr auvitek 4 ,
 -.Xr coram 4 ,
 -.Xr cxdtv 4 ,
 -.Xr emdtv 4 ,
 +.Xr video 9
 +.Pp
 .Pa pkgsrc/multimedia/dvb-apps ,
 .Pa pkgsrc/multimedia/mplayer ,
 -.Pa http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html
 +.Rs
 +.%T Linux Media Infrastructure API.
 +.%T Part II. Linux DVB API
 +.%D 2011
 +.%U http://linuxtv.org/downloads/v4l-dvb-apis/dvbapi.html
 +.Re
 .Sh HISTORY
 The
 .Nm
 -device driver first appeared in
 +interface first appeared in
 .Nx 6.0 .
 .Sh AUTHORS
 -.An -nosplit
 -The
 -.Nm
 -driver was written by
 .An Jared D. McNeill
 -.Aq jmcneill-qavaossjccednm+yrof...@public.gmane.org .
 +.Aq jmcneill-m2zzwtmgr3hafepfgvp...@public.gmane.org
 

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

[Jean-Yves Migeon]

On Mon, 29 Aug 2011 11:46:06 +0200, Manuel Bouyer wrote:

On Mon, Aug 29, 2011 at 09:01:47AM +0200, Jean-Yves Migeon wrote:

What kind of console is attaching for you in dom0? I can't see how
'+' would get wired in by default. At least when either started 
from

bare metal, or QEMU.


'+' is used for serial console (or, to be more precise, xencons
which is what is used by dom0 when the hypervisor is configured to 
use serial
console), where break won't work because the hypervisor doesn't 
forward

it to the dom0.


Hmm, I'll have to cross-check that one this afternoon. IIRC, I am also 
using the the default break command when I am running the dom0 inside 
QEMU, and '+' is only used when I want to break in the domU (through 
xencons(4)).


In that case, I'll have to make adjustments. Having the same key 
sequence for both dom0 and domU is... problematic.


--
Jean-Yves Migeon
jeanyves.mig...@free.fr

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

[Manuel Bouyer]

On Mon, Aug 29, 2011 at 03:17:16PM +0100, Jean-Yves Migeon wrote:
 Both; usually I am using the VGA-emulated display, but sometimes
 (like I did lately) I switch to console, so I can keep a reasonable
 amount of history of the dom0 output in my terminal.

The the dom0 kernel is using xencons, and the ddb sequence is '+'.
See the cn_set_magic() call in xencons.c

-- 
Manuel Bouyer bou...@antioche.eu.org
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

[Christoph Egger]

On 29.08.11 06:26, Christoph Egger wrote:
 On 29.08.11 00:09, Jean-Yves Migeon wrote:
 Module Name: src
 Committed By:jym
 Date:Sun Aug 28 22:09:37 UTC 2011

 Modified Files:
  src/share/man/man4: ddb.4

 Log Message:
 Be more precise for Xen: + is only valid for Xen domUs. dom0 uses
 the same key sequences as i386/amd64.
 
 + also works for me in a dom0.

I think I have to mention I am using serial console regularly.

Christoph

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

[John Nemeth]

On Dec 25, 10:16am, Matt Thomas wrote:
} 
} Module Name:  src
} Committed By: matt
} Date: Thu Aug  4 15:40:20 UTC 2011
} 
} Modified Files:
}   src/share/man/man4: wd.4
} 
} Log Message:
} wd includes SATA as well.

 Not that I object to the addition, but I'll just point out that
SATA is a subset of IDE, so technically it was already there.
Although, I suppose there are a lot of people that think of them as
being different things, so the addition is probably good.

}-- End of excerpt from Matt Thomas

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

[Thomas Klausner]

On Tue, Feb 09, 2010 at 02:28:03AM -0500, Constantine A. Murenin wrote:
 Is there a policy for the mandatory use of the Oxford commas?  They
 were omitted on purpose, of course.
 
 http://en.wikipedia.org/wiki/Serial_comma#Style_guides_opposing_mandatory_use

We have no explicit policy. I've been adding them in NetBSD man pages
over the years when I touched man pages and they were missing, so I
added them in this man page for consistency with the other man pages...
 Thomas

P.S.: Don't send mail to source-changes-full, that's what -d is for.

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

[Tom Spindler]

IMHO, especially for formats that end up in plain text more often
than not, it's better to use oxford commas to explicitly delineate
what conditions are; in this particular case, I think one could easily
parse the text with (critover or invalid) as a single value.

IMVHO, the title should be changed to voltage, temperature, and fan
sensor to be consistent in the use of commas.

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

[Thomas Klausner]

On Tue, Feb 09, 2010 at 10:27:33AM -0800, Tom Spindler wrote:
 IMVHO, the title should be changed to voltage, temperature, and fan
 sensor to be consistent in the use of commas.

Done.
 Thomas

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

[Christoph Egger]

 Module Name:  src
 Committed By: jruoho
 Date: Mon Jan 25 09:33:29 UTC 2010
 
 Modified Files:
   src/share/man/man4: acpidalb.4
 

Log message ?

Christoph
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/share/man/man4/acpidalb.4
 
 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/man4

[Marc Balmer]

Jukka,

Am 25.01.10 11:12, schrieb Jukka Ruohonen:
 Module Name:  src
 Committed By: jruoho
 Date: Mon Jan 25 10:12:41 UTC 2010
 
 Modified Files:
   src/share/man/man4: acpidalb.4
 
 Log Message:
 Recommit:
   * add verbosity to the PNP0C32 reference
   * use more markup
   * improve wording
 

You know that you quite easily change a commit message after commit?  So
in this case you could have just changed the commit message instead of
leaving us with an empty commit message.

I think you should still fix the empty commit message, it confuses
people that look at the cvs log.

- Marc

 
 To generate a diff of this commit:
 cvs rdiff -u -r1.4 -r1.5 src/share/man/man4/acpidalb.4
 
 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/man4/acpidalb.4
 diff -u src/share/man/man4/acpidalb.4:1.4 src/share/man/man4/acpidalb.4:1.5
 --- src/share/man/man4/acpidalb.4:1.4 Mon Jan 25 10:05:14 2010
 +++ src/share/man/man4/acpidalb.4 Mon Jan 25 10:12:41 2010
 @@ -1,4 +1,4 @@
 -.\ $NetBSD: acpidalb.4,v 1.4 2010/01/25 10:05:14 jruoho Exp $
 +.\ $NetBSD: acpidalb.4,v 1.5 2010/01/25 10:12:41 jruoho Exp $
  .\
  .\ Copyright (c) 2008 Christoph Egger ceg...@netbsd.org
  .\ All rights reserved.
 @@ -31,23 +31,33 @@
  .Nm acpidalb
  .Nd Direct Application Launch Buttons
  .Sh SYNOPSIS
 -.Cd acpidalb*at acpi?
 +.Cd acpidalb* at acpi?
  .Sh DESCRIPTION
 -This driver provides support for PNP0C32 ACPI hotkeys aka
 +This driver provides support for
 +.Tn PNP0C32
 +.Tn ACPI
 +hotkeys a.k.a.
  .Dq The Direct Application Launch Buttons .
  .Pp
  These are recognized on startup from system-wake or at runtime.
  Behaviour may differ from the standard specification in relation
  to the ACPI implementation.
  .Pp
 -The hotkeys are reported to the power daemon as
 +The hotkeys are reported to the power management daemon as
  .Dv hotkey_button .
  .Sh SEE ALSO
  .Xr acpi 4 ,
  .Xr powerd 8
 -.Sh STANDARDS
 -This drivers conforms to the PNP0C32 specification provided at
 -.Lk http://www.microsoft.com/whdc/system/vista/DirAppLaunch.mspx
 +.Pp
 +The
 +.Tn PNP0C32
 +specification is described in:
 +.Rs
 +.%A Microsoft Corporation
 +.%D October 26, 2006
 +.%T Direct Application Launch from System Startup on Windows Vista
 +.%U http://www.microsoft.com/whdc/system/vista/DirAppLaunch.mspx
 +.Re
  .Sh HISTORY
  The
  .Nm
 

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

[Marc Balmer]

Module Name:src
Committed By:   wiz
Date:   Sat Jul 25 21:16:35 UTC 2009

Modified Files:
src/share/man/man4: gpio.4

Log Message:
Reword for better HTML output.


we should fix our tools, instead.


To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/share/man/man4/gpio.4

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/man4/gpio.4
diff -u src/share/man/man4/gpio.4:1.9 src/share/man/man4/gpio.4:1.10
--- src/share/man/man4/gpio.4:1.9   Sat Jul 25 16:20:11 2009
+++ src/share/man/man4/gpio.4   Sat Jul 25 21:16:35 2009
@@ -1,4 +1,4 @@
-.\ $NetBSD: gpio.4,v 1.9 2009/07/25 16:20:11 mbalmer Exp $
+.\ $NetBSD: gpio.4,v 1.10 2009/07/25 21:16:35 wiz Exp $
.\$OpenBSD: gpio.4,v 1.5 2004/11/23 09:39:29 reyk Exp $
.\
.\ Copyright (c) 2004 Alexander Yurchenko gra...@openbsd.org
@@ -51,12 +51,12 @@
.Xr ioctl 2
calls on these devices.
.Pp
-The layout of the GPIO device is defined at a securelevel  1, i.e.  
typically

-during system boot, and cannot be changed later.
+The layout of the GPIO device is defined at a securelevel less than
+1, i.e. typically during system boot, and cannot be changed later.
GPIO pins can be configured and given a symbolic name and device  
drivers

that use GPIO pins can be attached to the
.Nm
-device at a securelevel  1.
+device at a securelevel less than 1.
All other pins will not be accessible once the runlevel has been  
raised.

.Sh IOCTL INTERFACE
The following structures and constants are defined in the

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

[Zafer Aydoğan]

On Thu, Jun 25, 2009 at 12:25 PM, Alan Barretta...@cequrux.com wrote:
 On Wed, 24 Jun 2009, Zafer Aydogan wrote:
 Log Message:
 catch spelling error.

 -accept all sorts of unforseen consequences.
 +accept all sorts of unforeseen consequences.

 Changing from British to American spelling is OK, I suppose, but
 please don't use log messages that imply that the British spelling was
 incorrect.  (Similarly for supercede/supersede.)

 --apb (Alan Barrett)


It has nothing whatsoever to do with American English.

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

[Martin Husemann]

On Mon, May 11, 2009 at 03:22:29PM +1000, matthew green wrote:
 what about systems that don't have AGP?

Or even PCI...

Martin

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

[Joerg Sonnenberger]

On Mon, May 11, 2009 at 03:22:29PM +1000, matthew green wrote:
 
On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote:
 So really should simply document the option DRM_NO_AGP rather than
 telling folks to include unnecessary drivers!

Just because it compiles doesn't mean it works properly. For most
drivers at least, you really need the AGP support for the GART.
 
 
 what about systems that don't have AGP?

That is part of most drivers. Some do provide a device-specific
mechanism to implement GART, e.g. Radeons do. In some other cases, the
system might already provide gart functionality on bridges anyway. But
documenting this in any sane way is difficult at best. So the easiest
way is likely to just list agp and add a comment that it is possible to
skip it with DRM_NO_AGP in some cases.

Joerg

re: CVS commit: src/share/man/man4

[matthew green]

   On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote:
So really should simply document the option DRM_NO_AGP rather than
telling folks to include unnecessary drivers!
   
   Just because it compiles doesn't mean it works properly. For most
   drivers at least, you really need the AGP support for the GART.


what about systems that don't have AGP?


.mrg.

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

[Joerg Sonnenberger]

On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote:
 So really should simply document the option DRM_NO_AGP rather than
 telling folks to include unnecessary drivers!

Just because it compiles doesn't mean it works properly. For most
drivers at least, you really need the AGP support for the GART.

Joerg

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

[David Holland]

On Sat, May 09, 2009 at 07:51:41AM -0700, Paul Goyette wrote:
 Document that drm(4) needs agp(4). Bump date.
 (joerg said so, and compilation fails without.)

 I really hate to contradict joerg, but...

 I think this is incorrect.  You can compile drm with DRM_NO_AGP and it  
 will compile just fine.  I'm running 5 machines like that!  (I thought  
 that I'd posted something relevant on current-users recently (a couple  
 weeks or so ago), but can't find it right now.)

 So really should simply document the option DRM_NO_AGP rather than
 telling folks to include unnecessary drivers!

Shouldn't it compile without AGP based on whether AGP is configured
rather than having its own additional option?

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