Hi,
I think a CTASSERT macro like in FreeBSD would be nice. It could be used
to verify assumptions about type and struct sizes.
This should work on gcc 2.9.5, too, but I haven't tested it.
--- sys/lib/libkern/libkern.h
+++ sys/lib/libkern/libkern.h
@@ -138,6 +138,9 @@ abs(int j)
#endif
#endif
One more simple diff about global variables:
- Document which variables are used for sysctl(8)
- Remove the redundant debug-only icmpprintfs variable
- Add static to global variables used only in this file.
ok?
Index: netinet/ip_icmp.c
==
On 2013/05/03 10:36, Martin Pieuchot wrote:
> One more simple diff about global variables:
> - Remove the redundant debug-only icmpprintfs variable
This lets you enable/disable the printfs from DDB, I haven't used this
particular one, but I have used similar variables before, it's very useful
wh
hi,
looks like we're missing some device_unref's that need to be
there after we call device_lookup or disk_lookup or numerous
macros that expand to either of those.
it would be nice if someone with working hibernate and ahci
could test the diff (on either i386 or amd64).
i'm also not 100% sure i
As much as I hate adding more code to lockmgr, the recent rototill
made one incompatible change. We need to preserve the difference
between shared and exclusive locks (only tmpfs seems to care).
Index: kern_rwlock.c
===
RCS file: /cvs
On Sun, Apr 28, 2013 at 08:12:31AM -0500, Vladimir Támara Patiño wrote:
> On Fri, Apr 26, 2013 at 01:04:26PM +0200, Stefan Sperling wrote:
> >Do you want to try implementing this idea?
> >I believe this idea would result in a smaller diff, too.
>
> Attached,
Thanks, very nice. I've committed the
hi,
while looking for the device_unref bugs, i found that
vscsi doesn't check if device_lookup has returned a
valid return value.
ok?
diff --git sys/dev/vscsi.c sys/dev/vscsi.c
index 3da371c..db65642 100644
--- sys/dev/vscsi.c
+++ sys/dev/vscsi.c
@@ -296,6 +296,9 @@ vscsiioctl(dev_t dev, u_long
Chris Ivancic & Colin Ligertwood reported in January that the
"SolarWinds NetFlow Traffic Analyzer" doesn't like it if the
ingress/egress interface index is always 0 (v5) or not present at all
(v9/v10). This keeps track on which interface a packet for a state was
first observed / first left and exp
On 3 May 2013 16:28, Florian Obser wrote:
> Chris Ivancic & Colin Ligertwood reported in January that the
> "SolarWinds NetFlow Traffic Analyzer" doesn't like it if the
> ingress/egress interface index is always 0 (v5) or not present at all
> (v9/v10). This keeps track on which interface a packet
On Fri, May 03, 2013 at 15:50 +0200, Mike Belopuhov wrote:
> diff --git sys/dev/pci/cz.c sys/dev/pci/cz.c
> index 9f74393..03b0fb5 100644
> --- sys/dev/pci/cz.c
> +++ sys/dev/pci/cz.c
> @@ -848,23 +848,30 @@ cztty_getttysoftc(dev_t dev)
> {
> int i, j, k, u = minor(dev) & ~CZTTYDIALOUT_MASK;
On Sun, Apr 28, 2013 at 08:12:31AM -0500, Vladimir Támara Patiño wrote:
> reordering of #includes in setrunelocale.c to comply
> better with style (9).
>
> Index: locale/setrunelocale.c
> ===
> RCS file: /cvs/src/lib/libc/locale/setru
hi,
as far as i can tell these functions are not used anymore.
ok?
diff --git sys/arch/sparc/dev/z8530kbd.c sys/arch/sparc/dev/z8530kbd.c
index 0a9c364..c746e56 100644
--- sys/arch/sparc/dev/z8530kbd.c
+++ sys/arch/sparc/dev/z8530kbd.c
@@ -213,8 +213,6 @@ static void zs_modem(struct zskbd_softc
hi,
not sure if this is anyhow useful, but we can completely ditch
DV_TTY since it's not used in any sensible way.
any objections? ok?
diff --git sys/arch/alpha/tc/scc.c sys/arch/alpha/tc/scc.c
index d25901e..ad37605 100644
--- sys/arch/alpha/tc/scc.c
+++ sys/arch/alpha/tc/scc.c
@@ -179,7 +179,7
> Date: Fri, 3 May 2013 20:04:11 +0200
> From: Mike Belopuhov
>
> hi,
>
> not sure if this is anyhow useful, but we can completely ditch
> DV_TTY since it's not used in any sensible way.
>
> any objections? ok?
NAK, these are used by hotplugd.
On 3 May 2013 20:12, Mark Kettenis wrote:
>> Date: Fri, 3 May 2013 20:04:11 +0200
>> From: Mike Belopuhov
>>
>> hi,
>>
>> not sure if this is anyhow useful, but we can completely ditch
>> DV_TTY since it's not used in any sensible way.
>>
>> any objections? ok?
>
> NAK, these are used by hotplugd
On Fri, May 03, 2013 at 09:55, Ted Unangst wrote:
> As much as I hate adding more code to lockmgr, the recent rototill
> made one incompatible change. We need to preserve the difference
> between shared and exclusive locks (only tmpfs seems to care).
Thinking about this some more, I like it even l
Thinking about this some more, I like it even less.
VOP_ISLOCKED is actually documented by the man page to return either 0
or 1. Not some LK flag. The fact that some filesystems are lazy and
just feed up lockstatus doesn't mean lockstatus is broken. It means
tmpfs_islocked and ufs_islocked are br
Index: acpitz.4
===
RCS file: /cvs/src/share/man/man4/acpitz.4,v
retrieving revision 1.5
diff -u -p -r1.5 acpitz.4
--- acpitz.431 May 2007 19:19:48 - 1.5
+++ acpitz.43 May 2013 20:01:51 -
@@ -54,3 +54,8 @@ The
.Nm
On 2013/04/30 17:39, I wrote:
> Seems to work well enough; and unlike my uthum (one of the dual-sensor ones)
> it seems to stay attached without dropping out all the time.
So I've tracked this uthum problem down a bit further...
uthum: ntc tuning start. cur state = 0x66, val = 0x8435
uthum: ntc t
On 2013/05/04 01:40, Stuart Henderson wrote:
> --- uthum.c 15 Apr 2013 09:23:02 - 1.19
> +++ uthum.c 4 May 2013 00:19:28 -
> @@ -515,7 +515,7 @@ uthum_ntc_getdata(struct uthum_softc *sc
> return EIO;
>
> /* get sensor value */
> - if (uthum_read_data(sc, C
Hello tech@,
I run a not note-worthy anonymous ftp server at home for friends and
family. This works perfectly with the supplied ftpd.
As of recently I noticed the amount of unfamiliar connections rising,
but using wtmp and last I found that it used reverse lookups.
For a lot of cases this isn'
On 05/04/13 07:26, Martijn van Duren wrote:
Hello tech@,
I run a not note-worthy anonymous ftp server at home for friends and
family. This works perfectly with the supplied ftpd.
As of recently I noticed the amount of unfamiliar connections rising,
but using wtmp and last I found that it used re
On Sat, May 04, 2013 at 07:26, Martijn van Duren wrote:
> For a lot of cases this isn't a problem. But there are a couple of
> instances where the domain name resolves to something a little to
> generic to be useful to determine it's origin and hence I'm not able to
> decide if it's a legit connect
23 matches
Mail list logo
