Re: CVS commit: src/share/man/man4
On Thu, May 16, 2024 at 05:48:05PM +0300, Valery Ushakov wrote: > On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote: > > > Modified Files: > > src/share/man/man4: eap.4 > > > > Log Message: > > Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page. > > Please, can you restore the part that explains what this option > is/does? It might be on its way out, but since we document it's > there, it's a good idea to actually document it, IMHO. > > I don't know much about audio, but the kernel mixer is software, isn't > it. I would imagine the type of systems that might have this device > may actually benefit from the hardware acceleration that this option > seems to imply. > > I.e. if anything, I'd rather this option is documented even better > than it was. Let me know if the new version of the text leaves any doubts.
Re: CVS commit: src/share/man/man4
On Thu, May 16, 2024 at 11:54:20 +, Nia Alarie wrote: > Modified Files: > src/share/man/man4: eap.4 > > Log Message: > Note that EAP_USE_BOTH_DACS is deprecated in the eap(4) manual page. Please, can you restore the part that explains what this option is/does? It might be on its way out, but since we document it's there, it's a good idea to actually document it, IMHO. I don't know much about audio, but the kernel mixer is software, isn't it. I would imagine the type of systems that might have this device may actually benefit from the hardware acceleration that this option seems to imply. I.e. if anything, I'd rather this option is documented even better than it was. -uwe
Re: CVS commit: src/share/man/man4
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
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
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
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
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
> 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
"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
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
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
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
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
> 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
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
> 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
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
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
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&r2=1.587&sortby=date&f=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
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
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
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
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
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
The address is still valid, in that emails to this address do not bounce. Sevan
Re: CVS commit: src/share/man/man4/man4.macppc
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
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
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
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
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
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
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
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
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
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
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 == &filemon_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
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
On Wed, 6 Jan 2016, Paul Goyette wrote: On Wed, 6 Jan 2016, Christos Zoulas wrote: In article <20160106015453.6f0f8f...@cvs.netbsd.org>, Paul Goyette wrote: -=-=-=-=-=- Module Name:src Committed By: pgoyette Date: Wed Jan 6 01:54:53 UTC 2016 Modified Files: src/share/man/man4: filemon.4 Log Message: Add a BUGS section... Until this is fixed properly, you should prevent the ioctl from succeeding by returning EPERM or EINVAL, instead of succeeding and deadlocking later. 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! 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. +--+--++ | 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 | +--+--++ !DSPAM:568c90e0240441760212287! +--+--++ | 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
On Wed, 6 Jan 2016, Christos Zoulas wrote: In article <20160106015453.6f0f8f...@cvs.netbsd.org>, Paul Goyette wrote: -=-=-=-=-=- Module Name:src Committed By: pgoyette Date: Wed Jan 6 01:54:53 UTC 2016 Modified Files: src/share/man/man4: filemon.4 Log Message: Add a BUGS section... Until this is fixed properly, you should prevent the ioctl from succeeding by returning EPERM or EINVAL, instead of succeeding and deadlocking later. 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. +--+--++ | 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
In article <20160106015453.6f0f8f...@cvs.netbsd.org>, Paul Goyette wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: pgoyette >Date: Wed Jan 6 01:54:53 UTC 2016 > >Modified Files: > src/share/man/man4: filemon.4 > >Log Message: >Add a BUGS section... Until this is fixed properly, you should prevent the ioctl from succeeding by returning EPERM or EINVAL, instead of succeeding and deadlocking later. christos
Re: CVS commit: src/share/man/man4
Hey, On 10/26/15 00:00, Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Sun Oct 25 23:00:00 UTC 2015 > > Modified Files: > src/share/man/man4: wsdisplay.4 > > Log Message: > Remove description of SPLASHSCREEN_PROGRESS and WSDISPLAY_SPROGRESS. Thanks :) > The last remnants of the former were just removed from src by > pronchery. > > Bump date. > > XXX: probably WSDISPLAY_SPROGRESS needs removal too -- back to you, > pronchery! I suppose this involves the compatibility layer in a way or another? Shall we keep the ioctl available but return ENOTSUP/ENOSYS or something like that? This way the day we restore support for this we can simply return 0 again. I am definitely interested in this sort of boot-time eye candy, and still using SPLASHSCREEN on my desktop (Radeon HD). It doesn't seem to work on my laptop though (Intel). >From a quick glance at the current code I believe we currently return EINVAL, but I did not find the exact right place yet (where EPASSTHROUGH goes to die). Hints or mentoring welcome :) Cheers, -- khorben
Re: CVS commit: src/share/man/man4/man4.amiga
On 9 Aug 2013, at 5:35 PM, Paul Goyette 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
On Sat, Mar 30, 2013 at 06:07:55PM +0900, Izumi Tsutsui wrote: > > Modified Files: > > src/share/man/man4: athn.4 > > > > Log Message: > > Fix Dd. Remove fw_update reference, the firmware is installed by default. > > XXX: Fix ".Xr hostname.if 5", which doesn't exist on NetBSD. > > ifconfig.if(5) for NetBSD? Thanks, I've changed it to use that. Thomas
Re: CVS commit: src/share/man/man4
> Modified Files: > src/share/man/man4: athn.4 > > Log Message: > Fix Dd. Remove fw_update reference, the firmware is installed by default. > XXX: Fix ".Xr hostname.if 5", which doesn't exist on NetBSD. ifconfig.if(5) for NetBSD? --- Izumi Tsutsui
Re: CVS commit: src/share/man/man4
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
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
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
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
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
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
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
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
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? > New Zealand, for not much longer.
Re: CVS commit: src/share/man/man4
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
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
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
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
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
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
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
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
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
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
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
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? Martin
Re: CVS commit: src/share/man/man4
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
On Tue, Aug 30, 2011 at 01:31:50PM +0100, Matthias Scheler wrote: > 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. 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. - Jukka.
Re: CVS commit: src/share/man/man4
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
On 29.08.2011 22:27, Manuel Bouyer wrote: > 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 Yes, I can confirm now. I'll update ddb(4) to reflect this. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/share/man/man4
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 NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/share/man/man4
On Mon, 29 Aug 2011 15:25:03 +0200, Manuel Bouyer wrote: On Mon, Aug 29, 2011 at 12:45:27PM +0100, Jean-Yves Migeon wrote: 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)). But when running inside qemu, you're using qemu's VGA display, not its serial port, right ? 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. in this case I guess the dom0 is using wscons, not the xencons. xencons is (should) be used by dom0 only on serial console. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/share/man/man4
On Mon, Aug 29, 2011 at 12:45:27PM +0100, Jean-Yves Migeon wrote: > 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)). But when running inside qemu, you're using qemu's VGA display, not its serial port, right ? in this case I guess the dom0 is using wscons, not the xencons. xencons is (should) be used by dom0 only on serial console. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/share/man/man4
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
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
Can you put the driver xrefs back in 'SEE ALSO'? I find it useful. -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
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. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: CVS commit: src/share/man/man4
On 29.08.2011 06:30, Christoph Egger wrote: > 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. 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. -- Jean-Yves Migeon jeanyves.mig...@free.fr
Re: CVS commit: src/share/man/man4
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
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. Christoph
Re: CVS commit: src/share/man/man4
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
> On Fri, Jul 22, 2011 at 08:38:43AM +, Thomas Klausner wrote: > > Remove Xr to nonexisting intro(4), > > Shouldn't we have an intro(4)? I didn't realize it was missing... that was also my thought upon reading that change... .mrg.
Re: CVS commit: src/share/man/man4
On Wed, Aug 03, 2011 at 04:07:39PM +, David Holland wrote: > On Fri, Jul 22, 2011 at 08:38:43AM +, Thomas Klausner wrote: > > Remove Xr to nonexisting intro(4), > > Shouldn't we have an intro(4)? I didn't realize it was missing... Oops, that was an error on my part. Please put it back (from the context I don't see which man page it was). How it happened? intro(4) is platform-specific, and amd64 doesn't have one... Thomas
Re: CVS commit: src/share/man/man4
On Fri, Jul 22, 2011 at 08:38:43AM +, Thomas Klausner wrote: > Remove Xr to nonexisting intro(4), Shouldn't we have an intro(4)? I didn't realize it was missing... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/share/man/man4
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
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
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
On 9 February 2010 01:47, Thomas Klausner wrote: > Module Name: src > Committed By: wiz > Date: Tue Feb 9 06:47:53 UTC 2010 > > Modified Files: > src/share/man/man4: aibs.4 > > Log Message: > Nd argument does not need quotes (groff handles more than 9 arguments nicely); > add some commas. 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 C. > > > To generate a diff of this commit: > cvs rdiff -u -r1.2 -r1.3 src/share/man/man4/aibs.4
Re: CVS commit: src/share/man/man4
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 > .\" 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
> 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
> >> Modified Files: > >>src/share/man/man4: gpio.4 > >> > >> Log Message: > >> Reword for better HTML output. > > > > we should fix our tools, instead. > > Feel free to. > > The problem is that "<" can be used in macros, so we can't stupidly > replace every "<" with a < in HTML output. Or at least only after > macros have been evaluated. \*[Lt] (and \*[Gt]) as mentioned in mdoc(7)? --- Izumi Tsutsui
Re: CVS commit: src/share/man/man4
On Sat, Jul 25, 2009 at 11:58:46PM +0200, Marc Balmer wrote: > >> 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. Feel free to. The problem is that "<" can be used in macros, so we can't stupidly replace every "<" with a < in HTML output. Or at least only after macros have been evaluated. Thomas
Re: CVS commit: src/share/man/man4
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 @@ -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
On Thu, Jun 25, 2009 at 12:25 PM, Alan Barrett 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
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)
Re: CVS commit: src/share/man/man4
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
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
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
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
Re: CVS commit: src/share/man/man4
On Sat, 9 May 2009, Joerg Sonnenberger 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. OK - I must just be lucky with all my boards being various Radeon chipsets. Thanks for clarification. - | 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/man4
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