Re: const char *
:don't think there's any way to get rid of the warning without changing :the declarations. : :In my opinion, the use of -Wcast-qual is bogus. Often the whole :point of a cast is to remove a qualifier such as const. It's one :thing to warn when that's done implicitly, and quite another thing to :warn when the programmer has clearly expressed his intent through the :use of a cast. : :John :-- : John Polstra j...@polstra.com There are only a few cases where cast-qual is bogus. 99% of the warnings it generated were quite real. Maybe not bugs, but definitely programming by misadventure. Volatile and const are only going to become more important as we get deeper into the SMP issues. Especially volatile. cast-qual is necessary to keep people from making bozo mistakes. Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: const char *
../../dev/usb/ukbd.c: In function `ukbd_detach':
../../dev/usb/ukbd.c:373: warning: cast discards `const' from pointer
target type
...
It is a consequence of the following type definition:
(sys/bus_private.h)
struct device {
...
const char* desc; /* driver specific description */
...
}
One problem I have is that a string like that might be produced by
concatenating a few strings together. In the case of USB the desc is
the string returned by the device. At attach the string is created and
malloc()-ed, at detach free()-ed.
At the sys/bus*.h (bus) level, `desc' is just a string. It is const
mainly so that callers can pass a literal string to device_set_desc()
without getting a warning from -Wcast-qual. Unfortunately, this prevents
the bus level from helping you keep track of how the string was created.
The warning could be avoided using a table of the original (non-const)
addresses of the (malloc()ed) strings passed to device_set_desc().
This is a bit much to avoid a harmless warning, but you would need to
do it if not all strings were malloc()ed.
The warning can be avoided by (ab)using a variant union. I plan to use
a suitably macroised version of this to fix warnings for library functions.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
Hello! Five minutes ago I type 'nfsstat' and got: nfsstat: sysctl: No such file or directory I take a look at the source and that's what I found: Nfsstat gets statistic via sysctl(3). name[0]=CTL_VFS, name[2]=NFS_NFSSTATS, but name[1] has a value of vfc.vfc_typenum, returned by getvfsbyname(3). And it is very bad, 'cause vfc_typenum contains fs type number assigned by kernel, not sysctl OID! As we can see in nfs_vfsops.c NFS sysctl node declared with OID_AUTO (on my system it becomes 119, not 4 as returned by getvfsbyname). Now that it is possible to change the sysctl tree at runtime, the changes are not actually (completely) made for vfs sysctls. Special code for making impossible changes for vfs sysctls went away. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Slow seq. write on Seagate ST36530N
It sounds like a good idea, and it is. What I want to see is scsi_da use this automatically. I have never liked the punch it, Chewey! approach CAM has been taking. What do you mean scsi_da use this automatically? All of the tagged queueing stuff is controlled in the transport layer. What are you proposing that the DA driver do? It is up to a target driver to control properties of performance and reliability on the target device and to mediate between filesystems and that device. The da driver should be checking for and adjusting performance criteria based upon this. Whether it is now currently mistakenly placed in the transport layer (tags are a property of parallel SCSI- tags, qua tags, are not the issue, but the number of parallem operations at a time is) is not the issue. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
Mr. Rabson- Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I would suggest that the patches make their way into the 4.0 and 3.1 source trees, although I have yet to test them on a machine that was not affected by the PCI bus probe problem. I'll incorporate the patch into a more conventional 4.0 machine later today and let you know the results. We want to thank you so much for your quick response. The owners of the machine are quite gratified that they will be able to take advantage of the second processor after all. The dmesg from the machine appears below, in case you find it interesting. -Ben Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sat Feb 20 16:51:12 PST 1999 bhle...@server.mediumlook.com:/usr/src/sys/compile/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Pentium II (299.53-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping=3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO V,MMX real memory = 16777216 (16384K bytes) avail memory = 13316096 (13004K bytes) Preloaded elf kernel kernel at 0xf0342000. Probing for devices on PCI bus 0: chip0: Ross (?) host to PCI bridge rev 0x01 on pci0.0.0 vga0: S3 Trio graphics accelerator rev 0x43 int a irq 11 on pci0.13.0 chip1: PCI to ISA bridge (vendor=0e11 device=a0f3) rev 0x0c on pci0.15.0 ide_pci0: PCI IDE controller (busmaster capable) rev 0x0a int a irq 15 on pci0 .15.1 chip2: Ross (?) host to PCI bridge rev 0x01 on pci0.17.0 Probing for devices on PCI bus 1: tl0: Compaq Netelligent 10/100 Proliant rev 0x10 int a irq 11 on pci1.7.0 tl0: Ethernet address: 00:80:5f:85:97:2e tl0: autoneg complete, link status good (half-duplex, 10Mbps) ncr0: ncr 53c875 fast20 wide scsi rev 0x04 int a irq 11 on pci1.9.0 adv0: AdvanSys ASC3150 Ultra SCSI controller rev 0x02 int a irq 11 on pci1.10. 0 adv0: AdvanSys Ultra SCSI Host Adapter, SCSI ID 0, queue depth 16 Probing for devices on PCI bus 2: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: @@@ [0x ] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 ed0 not found at 0x280 fe0 not found at 0x300 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked wdc1 not found at 0x170 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0: unknown board_id: f000 ie0 not found at 0x300 ep0 not found at 0x300 ex0 not found le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 cs0 not found at 0x300 adv0 not found at 0x330 bt0 not found at 0x134 aha0 not found at 0x134 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da1 at adv0 bus 0 target 4 lun 0 da1: iomega jaz 1GB J.83 Removable Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: Attempt to query device size failed: NOT READY, Medium not present da0 at ncr0 bus 0 target 0 lun 0 da0: COMPAQ WDE4360W 1.52 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) -- Benjamin Lewis bhle...@gte.net -or- bhle...@purdue.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Hold it! LINT / GENERIC inconsistency
Anyone care to look at LINT and GENERIC and in particular at the ppc0 line? GENERIC lists ppc0 as a device, LINT as a controller. Since config accepts GENERIC's format I'm inclined to think that's the correct one. But one of my own files has controller in it and is also accepted, but I don't think we can mix device/controller lines with each other, right? Someone care to enlighten me or update the appropriate files? CURRENT sources from yesterday 20-2-1999. --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nl This is my Truth, tell me your's... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: one SysV bug/fix, how many more
parts of proc (p_vmspace etc.) For that matter, does any of kern_exit.c:exit1() need to be spl()d? It sure seems like it to me. Along with other parts of kern_exit.c, and many other things having to do with refcnt's. Is it just my paranoia, or have I got this spl concept correct? spl is for blocking interrupts. Process-related things shouldn't be and mostly aren't touched by interrupts. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
On Sun, 21 Feb 1999, Benjamin Lewis wrote: Mr. Rabson- Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I would suggest that the patches make their way into the 4.0 and 3.1 source trees, although I have yet to test them on a machine that was not affected by the PCI bus probe problem. I'll incorporate the patch into a more conventional 4.0 machine later today and let you know the results. We want to thank you so much for your quick response. The owners of the machine are quite gratified that they will be able to take advantage of the second processor after all. The dmesg from the machine appears below, in case you find it interesting. I've committed the fix to both branches, thanks for the feedback. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
On Sun, 21 Feb 1999, Bruce Evans wrote:
Hello! Five minutes ago I type 'nfsstat' and got:
nfsstat: sysctl: No such file or directory
I take a look at the source and that's what I found:
Nfsstat gets statistic via sysctl(3). name[0]=CTL_VFS, name[2]=NFS_NFSSTATS,
but name[1] has a value of vfc.vfc_typenum, returned by getvfsbyname(3).
And it is very bad, 'cause vfc_typenum contains fs type number assigned
by kernel, not sysctl OID! As we can see in nfs_vfsops.c NFS sysctl node
declared with OID_AUTO (on my system it becomes 119, not 4 as returned by
getvfsbyname).
Now that it is possible to change the sysctl tree at runtime, the changes
are not actually (completely) made for vfs sysctls. Special code for
making impossible changes for vfs sysctls went away.
Oh. Thats nasty. I don't want to allocate special oids for 'privileged'
nodes. I think the userland code should use sysctlbyname() instead.
This patch seems to fix it for me:
Index: nfsstat.c
===
RCS file: /home/ncvs/src/usr.bin/nfsstat/nfsstat.c,v
retrieving revision 1.12
diff -u -r1.12 nfsstat.c
--- nfsstat.c 1998/10/25 10:59:44 1.12
+++ nfsstat.c 1999/02/21 11:47:08
@@ -162,16 +162,9 @@
err(1, kvm_read);
}
} else {
- int name[3];
size_t buflen = sizeof *stp;
- struct vfsconf vfc;
- if (getvfsbyname(nfs, vfc) 0)
- err(1, getvfsbyname: NFS not compiled into kernel);
- name[0] = CTL_VFS;
- name[1] = vfc.vfc_typenum;
- name[2] = NFS_NFSSTATS;
- if (sysctl(name, 3, stp, buflen, (void *)0, (size_t)0) 0) {
+ if (sysctlbyname(vfs.nfs.nfsstats, stp, buflen, (void *)0,
(size_t)0) 0) {
err(1, sysctl);
}
}
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
On Sun, 21 Feb 1999, Bruce Evans wrote:
Hello! Five minutes ago I type 'nfsstat' and got:
nfsstat: sysctl: No such file or directory
I take a look at the source and that's what I found:
Nfsstat gets statistic via sysctl(3). name[0]=CTL_VFS, name[2]=NFS_NFSSTATS,
but name[1] has a value of vfc.vfc_typenum, returned by getvfsbyname(3).
And it is very bad, 'cause vfc_typenum contains fs type number assigned
by kernel, not sysctl OID! As we can see in nfs_vfsops.c NFS sysctl node
declared with OID_AUTO (on my system it becomes 119, not 4 as returned by
getvfsbyname).
Now that it is possible to change the sysctl tree at runtime, the changes
are not actually (completely) made for vfs sysctls. Special code for
making impossible changes for vfs sysctls went away.
A related problem is in mountd which should be fixed by this patch:
Index: mountd.c
===
RCS file: /home/ncvs/src/sbin/mountd/mountd.c,v
retrieving revision 1.34
diff -u -r1.34 mountd.c
--- mountd.c1998/12/29 09:38:49 1.34
+++ mountd.c1999/02/21 11:53:45
@@ -255,7 +255,7 @@
char **argv;
{
SVCXPRT *udptransp, *tcptransp;
- int c, error, mib[3];
+ int c, error;
struct vfsconf vfc;
error = getvfsbyname(nfs, vfc);
@@ -321,10 +321,7 @@
}
}
if (!resvport_only) {
- mib[0] = CTL_VFS;
- mib[1] = vfc.vfc_typenum;
- mib[2] = NFS_NFSPRIVPORT;
- if (sysctl(mib, 3, NULL, NULL, resvport_only,
+ if (sysctlbyname(vfs.nfs.nfs_privport, NULL, NULL,
resvport_only,
sizeof(resvport_only)) != 0 errno != ENOENT) {
syslog(LOG_ERR, sysctl: %m);
exit(1);
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
Now that it is possible to change the sysctl tree at runtime, the changes
are not actually (completely) made for vfs sysctls. Special code for
making impossible changes for vfs sysctls went away.
Oh. Thats nasty. I don't want to allocate special oids for 'privileged'
nodes. I think the userland code should use sysctlbyname() instead.
This patch seems to fix it for me:
Index: nfsstat.c
===
RCS file: /home/ncvs/src/usr.bin/nfsstat/nfsstat.c,v
retrieving revision 1.12
diff -u -r1.12 nfsstat.c
--- nfsstat.c 1998/10/25 10:59:44 1.12
+++ nfsstat.c 1999/02/21 11:47:08
@@ -162,16 +162,9 @@
err(1, kvm_read);
}
} else {
- int name[3];
size_t buflen = sizeof *stp;
- struct vfsconf vfc;
- if (getvfsbyname(nfs, vfc) 0)
- err(1, getvfsbyname: NFS not compiled into kernel);
- name[0] = CTL_VFS;
- name[1] = vfc.vfc_typenum;
- name[2] = NFS_NFSSTATS;
- if (sysctl(name, 3, stp, buflen, (void *)0, (size_t)0) 0) {
+ if (sysctlbyname(vfs.nfs.nfsstats, stp, buflen, (void *)0,
(size_t)0) 0) {
err(1, sysctl);
}
}
The old interface is the standard one (although the above code shows how
inconvenient it is). mountd uses it too.
Perhaps the sysctl oid could be assigned to the vfs type number instead of
vice versa. The type number namespace can already have holes, although
it can't be very sparse because getvfsbyname(3) has to do an O(n) search
of it.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
In message 199902211232.xaa05...@godzilla.zeta.org.au, Bruce Evans writes:
Index: nfsstat.c
===
RCS file: /home/ncvs/src/usr.bin/nfsstat/nfsstat.c,v
retrieving revision 1.12
diff -u -r1.12 nfsstat.c
--- nfsstat.c 1998/10/25 10:59:44 1.12
+++ nfsstat.c 1999/02/21 11:47:08
@@ -162,16 +162,9 @@
err(1, kvm_read);
}
} else {
- int name[3];
size_t buflen = sizeof *stp;
- struct vfsconf vfc;
- if (getvfsbyname(nfs, vfc) 0)
- err(1, getvfsbyname: NFS not compiled into kernel);
- name[0] = CTL_VFS;
- name[1] = vfc.vfc_typenum;
- name[2] = NFS_NFSSTATS;
- if (sysctl(name, 3, stp, buflen, (void *)0, (size_t)0) 0) {
+ if (sysctlbyname(vfs.nfs.nfsstats, stp, buflen, (void *)0,
(size_t)0) 0) {
err(1, sysctl);
}
}
The old interface is the standard one (although the above code shows how
inconvenient it is). mountd uses it too.
There is nothing less standard about sysctlbyname to my knowledge...
--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org Real hackers run -current on their laptop.
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: problem during online register StarOffice 5.0
Maxim Sobolev wrote: I had the same problem, when first installing SO5, and found workarround. W hen you start SO and get question do you want to register now, reply no, then select menu Tools-Macro...-Organazer.. select Libraries tab and ena ble all libraries (by checking checkboxes). Then re-enter registration mode (menu Help- Registration... Maybe this will help (it worked for me). Sincerely, Maxim Umm, what libraries should be there? I only have a single checkbox next to a single library (Standard) and only one choice in the dropdown box (which soffice). This can't be disabled.. Should there be more? Perhaps this is the problem? Chan Yiu Wah wrote: Hello, I encounterd an error when I tried to the online register StarOffice 5.0. T he error is uforms = ActiveDocument.UNO.Drawpage.Forms. Is there another way t o register to get the unlimit access for personal edition (so5). Thanks. Clarence To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Cheers, -Peter -- Peter Wemm pe...@netplex.com.au Netplex Consulting No coffee, No workee! :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
The old interface is the standard one (although the above code shows how inconvenient it is). mountd uses it too. There is nothing less standard about sysctlbyname to my knowledge... sysctl() is in Linux (starting in 2.1.x), BSD4.4, NetBSD, OpenBSD, etc. sysctlbyname() is in FreeBSD (starting in 2.2). Some of the Linux sysctl numbers are even binary compatible. However, all Linux filesystem sysctls are incompatible, starting with the top-level identifier being named CTL_FS instead of CTL_VFS. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
On Mon, 22 Feb 1999, Bruce Evans wrote: The old interface is the standard one (although the above code shows how inconvenient it is). mountd uses it too. There is nothing less standard about sysctlbyname to my knowledge... sysctl() is in Linux (starting in 2.1.x), BSD4.4, NetBSD, OpenBSD, etc. sysctlbyname() is in FreeBSD (starting in 2.2). Some of the Linux sysctl numbers are even binary compatible. However, all Linux filesystem sysctls are incompatible, starting with the top-level identifier being named CTL_FS instead of CTL_VFS. If more than just NFS was defining its own sysctl variables, I might be worried but as I found out when I did the original dynamic sysctl work, only NFS actually used the (IMHO) ugly mechanism for rewiring its oid number by putting a pointer to the oid in its struct vfsops. Since sysctlbyname exists and is obviously a better mechanism for reading the variable (based on code complexity), then why not use it? We maintain both nfsstat and mountd in our tree and I don't see anyone expecting to be able to run Net/OpenBSD versions of those utilities on FreeBSD. If people feel strongly that we should continue to support the old mechanism, I guess I could modify vfs_register to change the oid numbers. It doesn't really seem worth it to me though. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
In message pine.bsf.4.05.9902211322320.82049-100...@herring.nlsystems.com, Do ug Rabson writes: Since sysctlbyname exists and is obviously a better mechanism for reading the variable (based on code complexity), then why not use it? I support this. It was the intention of sysctlbyname() to minimize the use of well-known-OIDs as much as possible. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Hold it! LINT / GENERIC inconsistency
On Sun, Feb 21, 1999 at 12:19:08PM +0100, Jeroen Ruigrok/Asmodai wrote: Anyone care to look at LINT and GENERIC and in particular at the ppc0 line? GENERIC lists ppc0 as a device, LINT as a controller. GENERIC wins. Since config accepts GENERIC's format I'm inclined to think that's the correct one. But one of my own files has controller in it and is also accepted, but I don't think we can mix device/controller lines with each other, right? Someone care to enlighten me or update the appropriate files? I do it. Thanks for the report. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: one SysV bug/fix, how many more
On Sun, 21 Feb 1999, Bruce Evans wrote: parts of proc (p_vmspace etc.) For that matter, does any of kern_exit.c:exit1() need to be spl()d? It sure seems like it to me. Along with other parts of kern_exit.c, and many other things having to do with refcnt's. Is it just my paranoia, or have I got this spl concept correct? spl is for blocking interrupts. Process-related things shouldn't be and mostly aren't touched by interrupts. Bruce But without an spl, couldn't multiple processes do Very Bad Things in a partially shared proc context? Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: one SysV bug/fix, how many more
spl is for blocking interrupts. Process-related things shouldn't be and mostly aren't touched by interrupts. But without an spl, couldn't multiple processes do Very Bad Things in a partially shared proc context? They can do that with or without an spl if they don't lock things properly spl can give improper giant locking as a side effect, but it doesn't necessarily prevent other processes running, since tsleep() isn't locked by spls. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: one SysV bug/fix, how many more
On Mon, 22 Feb 1999, Bruce Evans wrote: spl is for blocking interrupts. Process-related things shouldn't be and mostly aren't touched by interrupts. But without an spl, couldn't multiple processes do Very Bad Things in a partially shared proc context? They can do that with or without an spl if they don't lock things properly spl can give improper giant locking as a side effect, but it doesn't necessarily prevent other processes running, since tsleep() isn't locked by spls. Okay, so we'd need a true mutex, not spl. Do you not agree that there are some pretty glaring races in code that assumes that vmspace, signals, etc. aren't shared? Bruce Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
On Sun, 21 Feb 1999, Doug Rabson wrote:
Oh. Thats nasty. I don't want to allocate special oids for 'privileged'
nodes. I think the userland code should use sysctlbyname() instead.
This patch seems to fix it for me:
Works for me too. This problem exists not only in -current, i believe.
Should all sysctl be replaced by sysctlbyname? I just grep sysctl in `find
/usr/src/usr.bin *.c` and got many lines. Just start checking...
Index: nfsstat.c
===
RCS file: /home/ncvs/src/usr.bin/nfsstat/nfsstat.c,v
retrieving revision 1.12
diff -u -r1.12 nfsstat.c
--- nfsstat.c 1998/10/25 10:59:44 1.12
+++ nfsstat.c 1999/02/21 11:47:08
@@ -162,16 +162,9 @@
err(1, kvm_read);
}
} else {
- int name[3];
size_t buflen = sizeof *stp;
- struct vfsconf vfc;
- if (getvfsbyname(nfs, vfc) 0)
- err(1, getvfsbyname: NFS not compiled into kernel);
- name[0] = CTL_VFS;
- name[1] = vfc.vfc_typenum;
- name[2] = NFS_NFSSTATS;
- if (sysctl(name, 3, stp, buflen, (void *)0, (size_t)0) 0) {
+ if (sysctlbyname(vfs.nfs.nfsstats, stp, buflen, (void *)0,
(size_t)0) 0) {
err(1, sysctl);
}
}
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd.Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
-
Roman V. Palagin | Friday, monday, what's the difference.
System Administrator | (C) Jordan K. Hubbard
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
On Sat, Feb 20, 1999 at 08:02:17PM +, Lyndon Nerenberg wrote: I've been trying to get some progamming doc out of TI for the PCI1200 PCI/Cardbus bridge (used in the Dell Inspiron 7000), however they cannot seem to understand that I'm not asking for a pre-written device driver :-( Does anyone out there have doc for the PCI1200 (and preferably the entire PCI12xx family) they could send me? Or have a knowledgable contact inside TI that could send same to me? While CardBus isn't supported, this controller (in my Fujitsu Lifebook 280dx) works with PAO because the PCI-CardBus bridge supposedly uses some kind of Intel-compatible mode. I've been unable to get it to work under stock pccard without PAO (look at my post to -hackers yesterday), but it worked with PAO without a hitch. --lyndon -- Nathan Dorfman nat...@rtfm.net The statements and opinions in my Unix Admin @ Frontline Communicationsusenet posts are mine, not FCC's. The light at the end of the tunnel is the headlight of an approaching train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: paranoid patches
On Thu, 18 Feb 1999, Lyndon Nerenberg wrote: Basically, it is a patch into libkvm and w, that will allow a user (with the exception to the super user, naturally) to only view processes or information belonging to him/herself. The only problem with this is setuid binaries. The processes may have been started by me (top, etc..), but this wouldn't allow me to monitor the process once it's started. And, anything that can read /dev/[k]mem is free to bypass libkvm and just grovel around in the kernel memory space, anyway. Not only that - you would need to disable other holes as well, which has been done on purpose. Think of /procfs and sysctl kern.proc..something. Andrzej Bialecki ++---++ - ab...@nask.pl ||PicoBSD|| FreeBSD in your pocket? Go and see: Research Academic |+---+| Small Embedded FreeBSD Network in Poland | |TT~~~| |http://www.freebsd.org/~picobsd/ ~-+==---+-+ - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: const char *
Matthew Dillon wrote: : :In my opinion, the use of -Wcast-qual is bogus. Often the whole :point of a cast is to remove a qualifier such as const. It's one :thing to warn when that's done implicitly, and quite another thing :to warn when the programmer has clearly expressed his intent through :the use of a cast. There are only a few cases where cast-qual is bogus. 99% of the warnings it generated were quite real. Maybe not bugs, but definitely programming by misadventure. Volatile and const are only going to become more important as we get deeper into the SMP issues. Especially volatile. cast-qual is necessary to keep people from making bozo mistakes. I would find -Wcast-qual tolerable if it behaved just a little bit differently. It should allow without complaint explicit casts which change _only_ the constness. For example, casting from const char * to char * explicitly would be OK. But casting from, say, const char * to void * would still produce a warning. This would make it possible to get rid of the warnings in those cases where it made sense to cast away const (e.g., dealing with bad but standard interfaces). The above is more or less how C++'s const_castT(x) construct works. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
There are PDF and zipped PostScript data sheets for these parts on TI's web page: http://www.ti.com/sc/docs/folders/analog/pci1211.html Ya, I found those by doing a search inside the TI site. The problem is the data sheets those URLs point to only describe the hardware side of things. There's nothing there describing how to deal with the chips in software. --lyndon pgptTMuiD0TJK.pgp Description: PGP signature
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
While CardBus isn't supported, this controller (in my Fujitsu Lifebook 280dx) works with PAO because the PCI-CardBus bridge supposedly uses some kind of Intel-compatible mode. I've been unable to get it to work under stock pccard without PAO (look at my post to -hackers yesterday), but it worked with PAO without a hitch. I looked at PAO, but it doesn't appear to support the 3.X branch, which I'm running. If there's a PAO for 3.X, please let me know where it is (!). --lyndon pgpmCSF1Mm2La.pgp Description: PGP signature
Re: Compaq built-in ncr tl controllers with 4.0
Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I can confirm that the patch solved the PCI bus problem here too. The machine here is now running 3.1-STABLE. I have included the dmesg output at the end of this message. As for SMP, we're not quite there yet. First, generic SMP kernel panics because it finds 50 INTRs. After building a new kernel with 50 INTRs, we got a new panic: assign_apic_irq: inconsistent table. I can't say I'm surprised, because I *know* there are problems with the Compaq mptable (from earlier message about MP Proliants). So I'm now digging into the Compaq mptable - which is also included at the end of this message. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #2: Sun Feb 21 17:10:46 CET 1999 t...@newsfeed1.telia.no:/usr/src/sys/compile/NEWSFEED1 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 332803853 Hz CPU: Pentium II/Xeon/Celeron (332.80-MHz 686-class CPU) Origin = GenuineIntel Id = 0x651 Stepping=1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,b24 real memory = 603979776 (589824K bytes) avail memory = 584593408 (570892K bytes) Preloaded elf kernel kernel at 0xf02a5000. eisa0: CPQ561 (System Board) Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: Ross (?) host to PCI bridge rev 0x03 on pci0.0.0 vga0: Cirrus Logic GD5430 SVGA controller rev 0x22 int a irq 255 on pci0.6.0 chip1: PCI to EISA bridge (vendor=0e11 device=0001) rev 0x07 on pci0.15.0 chip2: Ross (?) host to PCI bridge rev 0x03 on pci0.17.0 Probing for devices on PCI bus 1: ncr0: ncr 53c875 fast20 wide scsi rev 0x14 int a irq 9 on pci1.4.0 ncr1: ncr 53c875 fast20 wide scsi rev 0x14 int b irq 10 on pci1.4.1 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 10 on pci1.7.0 fxp0: Ethernet address 00:90:27:13:f6:21 tl0: Compaq Netelligent 10/100 rev 0x10 int a irq 5 on pci1.8.0 tl0: Ethernet address: 00:08:c7:1e:a7:35 tl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 2: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0: failed to get data. psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle changing root device to da0s3a da0 at ncr0 bus 0 target 0 lun 0 da0: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da2 at ncr0 bus 0 target 4 lun 0 da2: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da2: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da3 at ncr0 bus 0 target 5 lun 0 da3: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da3: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da1 at ncr0 bus 0 target 1 lun 0 da1: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) -- === MPTable, version 2.0.15 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4ff0 signature:'_MP_' length: 16 bytes version: 1.4 checksum:
ports
I've noticed that as I'm constantly syncing my /usr/ports directory and upgrading programs, the old packages stay there. If I pkg_delete them and there's an unchanged file that exists in both the update and the original then tat gets deleted too. Any way of cleanly removing old packages? Incidentally are the ports trees for all the FreeBSD releases the same one? I mean if I'm running 2.2.x do I still get all the latest ports? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Slow seq. write on Seagate ST36530N
Matthew Jacob wrote... It sounds like a good idea, and it is. What I want to see is scsi_da use this automatically. I have never liked the punch it, Chewey! approach CAM has been taking. What do you mean scsi_da use this automatically? All of the tagged queueing stuff is controlled in the transport layer. What are you proposing that the DA driver do? It is up to a target driver to control properties of performance and reliability on the target device and to mediate between filesystems and that device. The da driver should be checking for and adjusting performance criteria based upon this. Whether it is now currently mistakenly placed in the transport layer (tags are a property of parallel SCSI- tags, qua tags, are not the issue, but the number of parallem operations at a time is) is not the issue. I think it would be very difficult for the DA driver, or any other peripheral driver to accurately adjust the number of parallel operations based on performance. How does the peripheral driver know whether the underlying device is being pounded or just pinged? What may be pounding for one device might simply be pinging for another. Even if you measured latency for each command, there's no way to know the reason for the latency of any given command without in-depth knowledge of the device in question. (e.g., there's no way to know whether a higher-than-average time to completion is the result of an overloaded device, or the result of something like a thermal recalibration...) I think the best we could hope for is some sort of userland benchmarking process that would establish roughly the best number of transactions for a given device. Based on what I've seen, I would say that this would generally be either 1, or whatever we determine automatically from the device's queue full responses. There are, I think, relatively few devices that should be in the land in between those values. (e.g., device X doesn't return queue full until we reach 48 transactions, but its performance really stinks if you go above 30 transactions) Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
On Sun, Feb 21, 1999 at 06:27:59PM +, Lyndon Nerenberg wrote: While CardBus isn't supported, this controller (in my Fujitsu Lifebook 280dx) works with PAO because the PCI-CardBus bridge supposedly uses some kind of Intel-compatible mode. I've been unable to get it to work under stock pccard without PAO (look at my post to -hackers yesterday), but it worked with PAO without a hitch. I looked at PAO, but it doesn't appear to support the 3.X branch, which I'm running. If there's a PAO for 3.X, please let me know where it is (!). That's why I can't run PAO (and consequently no PCMCIA working on my laptop at the moment). There's a PAO for 3.0, but I'm not sure if it's for -stable or 3.0-release. You can only get it by cvsupping pao3 from jaz.jp.freebsd.org. --lyndon -- Nathan Dorfman nat...@rtfm.net The statements and opinions in my Unix Admin @ Frontline Communicationsusenet posts are mine, not FCC's. The light at the end of the tunnel is the headlight of an approaching train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
On Sun, 21 Feb 1999, Nathan Dorfman wrote: # I looked at PAO, but it doesn't appear to support the 3.X # branch, which I'm running. If there's a PAO for 3.X, please # let me know where it is (!). # # That's why I can't run PAO (and consequently no PCMCIA working on my # laptop at the moment). There's a PAO for 3.0, but I'm not sure if it's # for -stable or 3.0-release. You can only get it by cvsupping pao3 from # jaz.jp.freebsd.org. I'm running pccard just fine on a Dell Inspiron 7000 with 4.0. I had to tweak sio.c to increase a delay for the FIFO tests but other than that my modem (Zoom 56K LT DataFax) and 3CCE589ET network card are both humming along no problems. I'm going to commit the pccard.conf entries for them RSN. Between Doug and Terry I think I have enough to start playing with getting support for the network card that started this thread. :) -steve # -- # Nathan Dorfman nat...@rtfm.net The statements and opinions in my # Unix Admin @ Frontline Communicationsusenet posts are mine, not FCC's. # The light at the end of the tunnel is the headlight of an approaching # train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
/etc/pccard_ether troubles
Hi All, Anyone have any objections (now that we have dhclient in the tree) to pointing pccard_ether at its new home? -steve Index: pccard_ether === RCS file: /home/ncvs/src/etc/pccard_ether,v retrieving revision 1.10 diff -u -r1.10 pccard_ether --- pccard_ether1999/02/10 18:08:16 1.10 +++ pccard_ether1999/02/16 03:36:46 @@ -16,12 +16,12 @@ if [ x$pccard_ifconfig != xNO ] ; then if [ x$pccard_ifconfig = xDHCP ] ; then - if [ -f /usr/local/sbin/dhclient ] ; then + if [ -f /sbin/dhclient ] ; then if [ -s /var/run/dhclient.pid ] ; then kill `cat /var/run/dhclient.pid` rm /var/run/dhclient.pid fi - /usr/local/sbin/dhclient + /sbin/dhclient elif [ -f /usr/local/sbin/dhcpc ] ; then if [ -s /var/run/dhcpc.pid ] ; then kill `cat /var/run/dhcpc.pid` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: one SysV bug/fix, how many more
Your bug fix is in my queue. Alan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
NFS Problems
I update 3-Stable nearly weekly, and have been experiencing the same problem for quite a while now. NFS imports, on the client side appear to be losing data. When this occurs, I see .nfs78969 files on the server side. The program on the client side always freezes (top reports it's STAT as 'D'). This occurs regularly. I've tried nfsv3 and nfsv2. Read-only imports do not cause this freezing problem. The affected file often ends up being a size of 0. Are there some switches I should try? I assume (without testing) that 4-current would also show the same problems as 3-stable. Which is why I posted here. The server is 3-stable, clients are 3-stable. In fact, they share /usr, /bin, /sbin, /home and /var/db/pkg. Everything is read only except /home. I'd love to get this thing fixed if someone could point me in any direction at all... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Slow seq. write on Seagate ST36530N
Dennis Glatting wrote... On the ST410800W I am getting, according to iozone: FWIW, several people have reported bad performance with that drive when tagged queueing is enabled. Their firmware revisions, however, were 71xx, not 45xx. Apparantly drives with firmware that starts with 00 work okay. I have contacted Seagate. Seagate's technical support staff says Seagate doesn't do firmware upgrades, rather I have to locate a vendor with disks having the revision level I seek and purchase a new disk. That's pretty lame. What is the source for firmware upgrades? I don't know, I've never upgraded the firmware on a Seagate disk. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
3.0-3.1 elf issues?
Was the 3.0-RELEASE I got ~Dec 30 aout kernel? 'file /kernel' gives /kernel: unknown pure executable but 'strings /kernel | grep -i elf' gives FreeBSD ELF among other stuff. So far, I just did 'make world' in /usr/src/, updated my config per GENERIC diff, and built the kernel. The warning to look at http://www.freebsd.org/~peter/elfday.html on make install has me wondering if 'make world' was the right thing to do in the 1st place, and wondering whether and how to update my bootblock. As far as my newcomer to freebsd upgrade experience, the info I wound up getting from people (not some 'how-to' easy-upgrade web page) was: - need to see req'd changes to /etc by inspecting cvsup output - need to update config file by looking at diff of GENERIC - need to figure how to do the diff since GENERIC was replaced Bill Ross To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: sh(1) -- exec vs. fork
So, should I send-pr? -mi Rahul Dhesi once stated: =Many years ago I posted a shell script to Usenet in which I prepended a =line with 'exec', in an attempt to avoid having a shell process hanging =around doing a wait(). David Korn himself (of Korn shell fame) =responded saying this was not necessary, as the shell would do exec() =anyway. = =I check with trace() on a Sun and he seemed to be right. This was for =the classic Bourne shell many years ago. = =But I just checked /bin/sh on 3.1-RELEASE with ktrace and the above does =not seem to be true. I get drastically different traces for = = #! /bin/sh = exec /bin/pwd = =and = = #! /bin/sh = /bin/pwd = =Rahul = = Date: Fri, 19 Feb 99 11:43:59 EST = From: Mikhail Teterin m...@misha.cisco.com = To:curr...@freebsd.org = Message-Id: 199902191644.laa08...@misha.cisco.com = Subject: sh(1) -- exec vs. fork = Reply-To: m...@aldan.algebra.com = = I just finished going through a couple of crontabs prepending the = command-lines with ``exec'', when it hit me. = = Can shell itself recognize, there will be no more commands and just = proceed to exec without forking? What would this break? =... = = =To Unsubscribe: send mail to majord...@freebsd.org =with unsubscribe freebsd-current in the body of the message = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS Problems
I update 3-Stable nearly weekly, and have been experiencing the same problem for quite a while now. NFS imports, on the client side appear to be losing data. When this occurs, I see .nfs78969 files on the server side. These files exist because they've been deleted but not closed; this is probably just an artifact of the program being stuck. The program on the client side always freezes (top reports it's STAT as 'D'). You need to pass the 'l' switch to ps and look at the 'wchan' column to see where it's actually stuck. Are there some switches I should try? I assume (without testing) that 4-current would also show the same problems as 3-stable. Which is why I posted here. There have actually been some changes in 4.0 which might affect this, if I understand correctly. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
I fixed this a while back to use sysctlbyname, as it should have been done. Bruce subsequently backed it out (bad idea, IMO). You should file a PR or otherwise petition b...@freebsd.org to un-revert his change. Hello! Five minutes ago I type 'nfsstat' and got: nfsstat: sysctl: No such file or directory I take a look at the source and that's what I found: Nfsstat gets statistic via sysctl(3). name[0]=CTL_VFS, name[2]=NFS_NFSSTATS, but name[1] has a value of vfc.vfc_typenum, returned by getvfsbyname(3). And it is very bad, 'cause vfc_typenum contains fs type number assigned by kernel, not sysctl OID! As we can see in nfs_vfsops.c NFS sysctl node declared with OID_AUTO (on my system it becomes 119, not 4 as returned by getvfsbyname). Operating system is 4.0-CURRENT as of 1999/02/20. What you think? p.s. Sorry for bad English :( - Roman V. Palagin | RVP1-6BONE | Just because you're paranoid Network Administrator | RP40-RIPE | doesn't mean they AREN'T after you To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 3.0-3.1 elf issues?
According to Wilson S. Ross: Was the 3.0-RELEASE I got ~Dec 30 aout kernel? 'file /kernel' gives Yes, the default kernel format was changed to ELF on Jan., 6th. 3.0-RELEASE builds a.out kernel but you can generated ELF ones if you want. - need to see req'd changes to /etc by inspecting cvsup output Or you could use mergemaster for that (in ports). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problems with nfsstat and dynamic OID
I fixed this a while back to use sysctlbyname, as it should have been done. Bruce subsequently backed it out (bad idea, IMO). You only worked around the previous breakage of vfs sysctls for the statically configured case. The dynamically configured case was more fundamentally broken (sysctls were not wired at all). Other applications that use vfs sysctls, e.g., mountd(8), remained broken in all cases. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
