Re: C++ code in a kernel module?
On Mon, 8 Sep 2003 11:35:37 -0600
John Giacomoni [EMAIL PROTECTED] wrote:
I was planning on using the macro __cplusplus to toggle using
extern C { }, however the bsd.kmod.mk style Makefiles seem to
force the language to -std=c99 even when compiling with c++ .
my initial steps have been as follows:
take a functioning C based kernel module and rename to .cc
added extern C around the includes.
#defined key words such as new to xxx_new
recompiled the new .cc file by hand without -std=c99, but
keeping all the flags as the Makefile set them.
then linked using the Makefile and finally loaded the module.
-fno-rtti -fno-exceptions is probably a must unless you want to bring a
whole libsupc++ library into the kernel.
I've been silently following this thread, and unless I missed something, has
anyone asked John why he wants/needs to use C++ in the kernel?
--
Matt Emmerton
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
No, none of these methods will work. This very discussion came up in -questions a few months ago (or maybe it was late last year). The conclusion was that unless someone rewrites the /etc/fstab parsing routines in libc to support quoted and/or escaped spaces, we'll never be able to mount filesystems that have spaces in their names. -- Matt Emmerton Just a thort, not having tried it .. does either of the 'standard' methods of including spaces actually work in fstab ?? I speak of quoting (either single or double) and backslashing the space /mnt/space/silly long dirname/filename also with spaces or /mnt/space/silly\ long\ dirname/filename\ also\ with\ spaces mjt On Wed, 2003-07-30 at 23:31, Tim Kientzle wrote: Do file system names and mount points with whitespaces violate the specification of fstab? If so, the least thing I'd suggest is the document this restriction. Or should one extend 'getfsent' such that is able to cope with those whitespaces? I am not sure whether this would have any further implications so I am asking here. Formal standards tend to avoid system administration issues such as this. I doubt you would be violating any published standard. I say go for it. If something else breaks because of this change, let's fix that, too. I like the fact that FreeBSD works pretty well with other systems; lets keep pushing that. Tim Kientzle This Email has been scanned for Viruses by MailMarshal. -- Murray Taylor Special Projects Engineer - Bytecraft Systems Entertainment P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 M: +61 417 319 256 E: [EMAIL PROTECTED] or visit us on the web http://www.bytecraftsystems.com http://www.bytecraftentertainment.com This Email has been scanned for Viruses by MailMarshal. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Change to sys_errlist
On Sun, 6 Jul 2003, Terry Lambert wrote: Matthew Emmerton wrote: This is a RFC on a change to sys_errlist for errno = 0. On Linux, if perror() or strerror() is called with errno = 0, the resulting string is Success. On FreeBSD, the resulting string is Unknown error: 0. I think that FreeBSD's output is unintentionally confusing, as errno = 0 implies success. The following patch will change the output to the Linux behaviour. I appreciate any comments. Actually, I ran into a situation on MacOS X the other day that had a system call with a -1 return code with an errno == 0. I would personally like to distinguish this case, if only for the purpose of catching kernel errors. Saying Success when in fact the system call is returning -1 is a bogus thing to do. Agreed. I thought this over and read some specs and believe our way is the right way. -- Matthew Emmerton Computer Partners IT Specialist ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RFC: Change to sys_errlist
This is a RFC on a change to sys_errlist for errno = 0.
On Linux, if perror() or strerror() is called with errno = 0, the resulting
string is Success.
On FreeBSD, the resulting string is Unknown error: 0.
I think that FreeBSD's output is unintentionally confusing, as errno = 0
implies success.
The following patch will change the output to the Linux behaviour.
I appreciate any comments.
--- /usr/src/lib/libc/gen/errlst.c Sat Apr 24 14:28:24 1999
+++ errlst.cFri Jul 4 13:53:27 2003
@@ -38,7 +38,7 @@
#include stdio.h
const char *const sys_errlist[] = {
- Undefined error: 0, /* 0 - ENOERROR */
+ Success, /* 0 - ENOERROR */
Operation not permitted, /* 1 - EPERM */
No such file or directory,/* 2 - ENOENT */
No such process, /* 3 - ESRCH */
--
Matt Emmerton
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interview in Byte with Chris Sontag/SCO and FUD relatingtoBSDsettlement agreement
On Wed, Jun 18, 2003 at 12:01:38PM +0930, Greg 'groggy' Lehey wrote: On Tuesday, 17 June 2003 at 6:08:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Heller [EMAIL PROTECTED] writes: Will the FreeBSD project issue an offical statement relating to these allegations? What will happen to FreeBSD if SCO aims at the BSD projects. Could SCO revoke the Settlement Agreement and pursue a court ruling? This is not an official statement from the project. There is not now, nor has there *EVER* been *ANY* System V code in BSD. *EVER*. NEVER. NEVER. NEVER. Agreed. The fact that Sontag even mentions this detracts further from an already very stupid interview. I've put an analysis at http://.lemis.com/grog/sco-sontag-16jun2003.html. Your site seems not to be responding. Do you need a mirror? s//www/g and you should be able to access the site. -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports and /var/db/pkg
ok, so i wrote a small script (tcl, since i don't know perl), that does some checking, it reports for each package, the number of files how many are realy there, and if so, checks the MD5. now, if im not to far off, if some/all files are missing, or if the md5 does not match, i should be able to remove the package info, ... Well, that's not what you were asking for originally, and tools already exist to check that. OK, let me refrase it PROBLEM: how to update /var/db/pkg, when it knows too much, i.e. /usr/local has less stuff that /var/db/pkg knows about. e.g. pkg_info -g and the example from the pkg_which(1) manpage that I mentioned to you in a previous email. i read most of the pkg*, and though im very impressed, i fail to find a clear/easy way to get a one line output saying: pkg xyz no longer exits, can be removed from database thanks, danny If you know that package XYZ exists in /var/db/pkg but isn't in /usr/local (probably because you didn't 'make deinstall' or pkg_delete it), just do this: rm -rf /var/db/pkg/XYZ -- Matt Emmerton ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: matthew dillon
These messages aren't from the *real* Matt Dillon, they're from a stupid troll who has been impersonating various FreeBSD developers for a few months now. This particular troll uses anonymous remailers so the postmaster is helpless to block email addresses or IP ranges. So, if the message looks like a fake, sounds like a fake, and is littered with profanities (such as the F*ck Fumerola Licence), then please assume this is the voice of the troll and is best ignored. -- Matt Emmerton Sorry folks, I don't know, who this mathew dillon guy really is, or how important he is for the FreeBSD project, but I don't think, he should be on any of the freebsd mailing lists or any related facilities, if he just can't keep with some of the most basic rules of communication. It may be adequate or something like normal in irc channels or even usenet groups - although it should not - to behave this childish way, but I think at least on the freebsd mailing lists, there should be a little standard of etiquette or what it's called. I know I am not the first one thinking this way, the replies will probably be the same as every time before. Please accept my apologizes if I should hit the wrong person, but someone really does not behave in a acceptable way here and I just wanted to complain about it, to let people know, that freebsd-* is no place for private quarrels or neuroses. --- sorry for my bad english, etc, I'm new to freebsd/unix/bla etc, blubblubblub, a very disappointed bsd fan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sis0 - phy problem
hi, i also encounter problem with sis0 nic onboard. here is an extract from dmesg: FreeBSD 4.6.2-RELEASE sis0: SiS 900 10/100BaseTX port 0xd400-0xd4ff mem 0xe780-0xe7800fff irq \ at device 1.1 on pci0 sis0: Ethernet address: 00:00:00:00:00:00 miibus0: MII bus on sis0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ohci0: SiS 5571 USB controller mem 0xe700-0xe7000fff irq 5 at device 1.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SiS 5571 USB controller on ohci0 [...] rl0: Ethernet address: 00:50:22:9b:c7:24 miibus1: MII bus on rl0 rlphy0: RealTek internal media interface on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto i tried to force and hard code a mac address for the sis0, but it really seems that PHY isn't well recognized. Well, it's recognized, it's just unknown. I'm assuming that you can't actually use your sis0 NIC in this configuration. Is this correct? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sis900 : sis0 attach returned 6
From: Matthew Emmerton [EMAIL PROTECTED] Subject: Re: sis900: sis0 attach returned 6 Guido, I did some more digging and it appears the bigger problem is that the RTL8201 external PHY isn't supported (yet) in FreeBSD. Patches to support this PHY, along with reports of successful testing in numerous configurations, are reported in PR kern/30836 (and kern/35691). This PR has been sitting in GNATS since March - does anyone want to step and commit it? It seems that this chipset is frequently used on motherboards with embedded ethernet, so it would be nice to have this supported RSN. It works for me... is the RTL8201L different? This happens to be on 4.7 RC2, but it has worked since 4.6, or shortly thereafter, if I recall correctly. (This machine also has a realtek card in it...) sis0: SiS 900 10/100BaseTX port 0xd000-0xd0ff mem 0xcfffc000-0xcfffcfff irq 12 at device 3.0 on pci0 sis0: Ethernet address: 00:d0:09:de:34:ee miibus0: MII bus on sis0 rlphy0: RTL8201L 10/100 media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: RealTek 8139 10/100BaseTX port 0xcc00-0xccff mem 0xcfffbf00-0xcfffbfff ir q 15 at device 11.0 on pci0 rl0: Ethernet address: 00:50:bf:77:6f:44 miibus1: MII bus on rl0 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jim Rowan [EMAIL PROTECTED] It looks like the 8201L PHY was first supported in 4.6-RELEASE, but the PR wasn't updated to reflect this. Guido, if possible, could you try with 4.6.2-RELEASE and see if your card gets detected? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sis900: sis0 attach returned 6
Guido, I did some more digging and it appears the bigger problem is that the RTL8201 external PHY isn't supported (yet) in FreeBSD. Patches to support this PHY, along with reports of successful testing in numerous configurations, are reported in PR kern/30836 (and kern/35691). This PR has been sitting in GNATS since March - does anyone want to step and commit it? It seems that this chipset is frequently used on motherboards with embedded ethernet, so it would be nice to have this supported RSN. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sis900 : sis0 attach returned 6
I am trying to install 'FreeBSD 4.6.2-RELEASE #0: Wed Aug 14 21:23:26 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC i386' on a new ECS iBuddy4 desknote with sis900 fast ethernet card. The sis900 is never attached. When I look at dmesg output, I see repeated blocks of output about the sis900: = sis0: SiS 900 10/100BaseTX port 0xd400-0xd4ff mem 0xdfffb000-0xdfffbfff irq 5 at device 3.0 on pci0 = sis0: Ethernet address: (...mac address...) = sis0: MII without any PHY! = device_probe_and_attach: sis0 attach returned 6 I can use this device without problems under win2k. How can I proceed to get the sis900 working? When you see the boot: prompt, hit space and then type 'boot -v' and watch your system boot. Then send the list the detailed information about the sis0 driver (use the dmesg command once you've booted.) What's probably happening is that we're not recognizing the PHY device that the sis900 uses, or the card itself is doing something wierd. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
perceived strangeness with getopt(1,3)
Maybe I'm missing something huge, but getopt(1,3) aren't working the way I think they should. I have a script that I want to take two options, both of which have required arguments. gabby# getopt k:s: -k getopt: option requires an argument -- k -- gabby# getopt k:s: -s getopt: option requires an argument -- s -- gabby# Ok, so far, so good. But now let's combine them: gabby# getopt k:s: -k arg1 -s arg2 -k arg1 -s arg2 -- Ok, looks fine. gabby# getopt k:s: -k -s -k -s -- gabby# Wha? Neither of these options specified arguments! I guess you could consider that -k's argument was '-s', but I was pretty sure that an option's argument couldn't start with a dash character (to avoid the ambiguity that I'm hitting right now.) I'm pretty sure I'm the one that's confused (not getopt), since I get the same behaviour on -STABLE and -CURRENT. Can someone tell me how to accomplish what I want to do? Basically, I want this: gabby# getopt k:s: -k arg1 -s getopt: option requires an argument -- k -k arg1 -- gabby# getopt k:s: -k -s arg2 getopt: option requires an argument -- k -s arg2 -- gabby# -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kern/41227: Serial port IRQs cannot be shared when they should be
I'm the originator of the patch in this PR. The patch allows FreeBSD to work with some USR/3Com PCI modems that share IRQs with other system devices. From the PR: Synopsis: Serial port IRQs cannot be shared when they should be State-Changed-From-To: open-feedback State-Changed-By: njl State-Changed-When: Fri Aug 23 17:42:14 PDT 2002 State-Changed-Why: Have you discussed this on -hackers or -current? There are reasons that RF_SHAREABLE is not enabled in sio (in both -current and -stable). The patch is not complete. http://www.freebsd.org/cgi/query-pr.cgi?pr=41227 Can anyone enlighten me on the reasons for this? The user of the patch has experienced no problems using his PCI modem (sio) concurrently with his USB printer (ulpt) when both devices share IRQs. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reg: Claiming a device which is already claimed by another driver.
Hi,
I am writing a charecter driver for a pci-ide controller, my problem
is that atapci driver already claims my device. So in essence I need to
detach the atapci driver from my device and claim it
I have tried using the bus_generic_detach to detach the atapci driver,
but
now how will I be able to attach to it??
If you're writing a new driver for a PCI-IDE controller, then you'll have to
remove the default FreeBSD driver for that particular device from your
kernel, so that the device isn't taken when you attempt to start your
driver.
This would require removing any of the 'device ata' lines from your kernel
config, adding in the proper line for your new driver, rebuilding your
kernel and then debugging from there. ('options ddb' is good when writing
new kernel drivers.)
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Questions about kernel/userspace backwards compatibilty between minor revisions
I' m working on getting OpenAFS working 100% on FreeBSD, and while reviewing the first set of my patches with the OpenAFS maintainer, some questions about kernel/userspace backwards compatibility came about. More specifically, OpenAFS was first ported on FreeBSD 4.2, and as a result, all config files (autoconf and 3 static files) are configured to look for FreeBSD 4.2. The CVS maintainer's current idea is is to duplicate all of these config files and autconf logic for FreeBSD 4.[013456]. This will add a bunch of _identical_ files to the CVS repo and add a whole lot of unneccessary autoconf checks that IMHO, are unneeded. This begs the question, is a check for FreeBSD 4.x sufficient enough from a userland perspective? What about from a kernel perspective (for kernel modules)? From my observations (I compiled the userland on 4.[236] with no problems), I think that a check for 4.x should be sufficient for userland and kernel modules, but if any kernel hacking is involved (as is done in net/arla), finer-grained checking will be required. Can anyone confirm or deny this? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ruby ports and PREFIX
So, what I'm doing here is experimenting with encap, a nifty little
package standard where the idea is that you install your software with
PREFIX set to /usr/local/encap/pkgname-version, and the package manager,
epkg, will look through that dir and symlink files from that hierarchy
in to /usr/local for you. It makes stuff like identifying the source of
a file, or rolling back to an earlier version of a software package,
downright trivial,
Of course, in terms of FreeBSD, I like to use ports to build packages,
so I've patched up bsd.port.mk to re-define PREFIX for intallations, and
run the package manager after install completes, etc. Most ports work
really well, assuming they honor PREFIX.
Which, ruby add-ons do not seem to do. For example, optparse:
do-install:
${MKDIR} ${RUBY_SITELIBDIR}/${PORTNAME}
${INSTALL_DATA} ${WRKSRC}/optparse.rb ${RUBY_SITELIBDIR}/
${INSTALL_DATA} ${WRKSRC}/optparse/*.rb
${RUBY_SITELIBDIR}/${PORTNAME}/
What the heck is that? On my test system, the RUBY_SITELIBDIR is
defined by interrogating RUBY, and the result is
/usr/local/encap/ruby-1.6.7.2002.05.02p/lib/ruby/site_ruby/1.6 ... what
I REALLY want is for the Port to install files based on PREFIX,
/usr/local/encap/ruby-optparse-0.8.6, and then I will link them in to
the proper ruby site directories which contain files in /usr/local
symlinked to their appropriate source packages.
A few questions:
1) Shouldn't the ruby add-on ports honor PREFIX?
But they do! When you install Ruby, it will install into ${PREFIX}. By
interrogating Ruby to get the RUBY_SITELIBDIR, you'll get the proper site
library directory, which is most definitely under ruby's install directory,
which is under the ${PREFIX} that was specified at compile-time.
2) To that end, is there a good way to define RUBY_SITELIBDIR and
friends in bsd.ruby.mk to honor PREFIX?
See above.
3) Once I symlink new files in to the ruby file hierarchy, so I have to
do any magic for Ruby to pick up to this fact? Is ruby going to do
anything troublesome like go looking in the encap directory it was built
for, instead of /usr/local?
As long as the files can be found (physically or via symlinks) via the
RUBY_SITELIBDIR that ruby think it's using, you shouldn't have any problems.
IIRC, this situation is one of the reasons why Perl is coming out of the
base system in -CURRENT right now, in order to make all things Perl
PREFIX-clean.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: national security backdoor in FreeBSD.
There is a backdoor in all versions of FreeBSD that are not compiled from source code within portmapper and telnetd. Hmm. Let's check out this logic. The binaries that ship on the FreeBSD distros are compiled from source. When I upgrade my system, I compile from source. And the backdoor only exists in binaries that are not compiled from source. So where do these binaries-with-no-source come from? Oh, I know! Carnivore detects FreeBSD ISO downloads, and tells the Magic Lantern software on my ISP's servers to change the binaries inside the ISO images that I FTP. Makes perfect sense! -- Matt Emmerton [ A proud Canuck who takes offense to the huge Canadian flag hanging on this dude's bedroom wall. ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: make(1) command-line variables
Dear Colleagues,
I need some help. Consider I have a Makefile for
application that can be build with different
options. Some of them I need just to define
via -D flag of the ``make'', but other need
to be set to some specific values (for example,
it can be path to my temporary dir). So I
use
make -DFIRST MYTMPDIR=/special/tmp
And I want just to keep track of the parameters
used to build that application. Nothing difficult
to obtain the name of Makefile from .MAKEFILE, as well
as make flags of make (including those -D, defining
some variables) from the .MAKEFLAGS var. But I did
NOT found the normal way to obtain the list of
variables defined in the command line through the
VAR=VAL construction. Strange, right?
Man says that
.MAKEFLAGS
The environment variable MAKEFLAGS may contain anything
that
may be specified on make's command line. Its contents are
stored in make's .MAKEFLAGS variable.
That is wrong, .MAKEFLAGS does not contain anything.
It won't contain anything unless you set MAKEFLAGS in the calling
environment.
[ Makefile ]
all:
@echo MAKEFLAGS: ${.MAKEFLAGS}
gabby$ export MAKEFLAGS=-Dfirst -Dsecond; make
MAKEFLAGS: -Dfirst -Dsecond
gabby$
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, 13 Mar 2002, Brooks Davis wrote: On Wed, Mar 13, 2002 at 04:25:00PM -0800, Terry Lambert wrote: This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? I thought it was a real bad thing to run CPUs in SMP systems at different clock rates. In fact, I never thought it was possible. I know I can't on my old 2-way P166 box, but things have changed a lot since '91. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Reading BIOS from userland
Is there any easy way to read the contents of a system BIOS from userland? bios(9) seems to have some very specific kernel-related BIOS routines, but nothing generic. I'm trying to write a program that will dump the BIOS image to stdout so that I can use strings(1) to sniff out version strings and other textual data on systems that can't be rebooted and/or easily reached. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading BIOS from userland
Is there any easy way to read the contents of a system BIOS from userland? No. Most modern BIOS code is paged, compressed and in some cases encrypted. bios(9) seems to have some very specific kernel-related BIOS routines, but nothing generic. I'm trying to write a program that will dump the BIOS image to stdout so that I can use strings(1) to sniff out version strings and other textual data on systems that can't be rebooted and/or easily reached. If this is all that you want, you can just open /dev/mem and read the section between 0xe and 0xf, much of this information is in there. Duh! I knew there was a simple way! This will suffice for my purposes. Thanks! -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sar on FreeBSD
Dustin Puryear wrote: After a month of futile searching I am unable to find a sar-like tool available for FreeBSD. I was alerted to the SNMP capabilities of FreeBSD. However, it would still be nice to have a system-level tool available that doesn't require SNMP. Does anyone know of anything for FreeBSD that is sar-like? If a sar-like tool isn't available, I may just begin writing something myself. Is there any interest in this? Compile up the real sar. SCO released the sources a year or two back, now. If that's the case, then where are they? The only publicly available SCO sources I've been able to find are those for csope (which is hosted at SourceForge.) http://www.sco.com/opensource doesn't exist anymore, now that Caldera owns SCO, and a search for opensource and open source on Caldera's web site only brings up hits on OpenLinux and the opensource packages that are included with it. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: boot1
On 04-Jan-02 Matthew Emmerton wrote: On 03-Jan-02 David E. Cross wrote: I'd like to create a /boot.config switch that will have boot1 _not_ read from the console; this is for a secure setup. Would others be interested in these patches when I finish them? Yes. I've seen other places use this, and I would commit it. :) How would this affect systems where you *have* to hit enter at the first boot: prompt in order to kick off a boot sequence? I've got two identical machines (same hardware, cloned hard drives), and one of them simply won't boot unless you hit enter. Turning off console imput would render this system useless after a reboot :) I think there's a PR open about this somewhere. Errr, why do you have to hit enter? If this patch does what I think it does, you won't even get a boot: prompt at all, it will just jump straight into the loader (or kernel). Besides, it wouldn't be on by default. You would have to explicitly turn it on via a flag in /boot.config. As Mike Silbersack (sp?) pointed out, it's a rogue problem that people run into every now and then. I think it's BIOS/motherboard related. In any case, if the patch bypasses the prompt entirely, then there's no problem in my case (and would actually make things better for me.) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: boot1
On 03-Jan-02 David E. Cross wrote: I'd like to create a /boot.config switch that will have boot1 _not_ read from the console; this is for a secure setup. Would others be interested in these patches when I finish them? Yes. I've seen other places use this, and I would commit it. :) How would this affect systems where you *have* to hit enter at the first boot: prompt in order to kick off a boot sequence? I've got two identical machines (same hardware, cloned hard drives), and one of them simply won't boot unless you hit enter. Turning off console imput would render this system useless after a reboot :) I think there's a PR open about this somewhere. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SMP beeping
On Mon, 10 Dec 2001, Chad David wrote: I sent a message about this to -stable last week, but didn't get any input that resulted in a solution to this problem so... -stable for the last week or more (I did a make world last week for the first time in over a month) beeps on and off when SMP is enabled. The beeping appears to be timed with very short stalls of the system; that is, when moving the mouse across the screen it stops at what seems to be that start of each beep. The beeps are not consistent in length, but the tone does not change. If I boot a kernel with the exact same config only with SMP disabled it does not beep, and mouse cursor movement is fluid. You never mentioned that the beeps were caused by moving your mouse before! Are you using a KVM? If so, does this problem occur when using a mouse that is directly connected to you system? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
* Hiten Pandya [EMAIL PROTECTED] [011210 16:02] wrote: hi all, this is a wild idea...suggestion... i wanted to ask if there were any _plans_ to port JFS (Journaled File System) to FreeBSD... as for JFS, it is developed by IBM for Linux and is licensed under GPL, so we could put this into src/gnu/ It is used on IBM MainFrames and Enterprise servers for high performance and maximum throughput... I'm glad you took the time to read the marketting literature. The problem is that porting it is going to be a bit more complicated than just dumping it into src/gnu. Feel free to take a shot at porting it though, let us know when you're done. I'm gainfully employed by IBM (although not for FreeBSD pursuits), and have had this on my TODO list for a while. The licence issue is a real sticky point, especially since the GPL and BSD licences are like oil and water. Because of the GPL licence, JFS support can never become part of the GENERIC kernel, and any related support tools will have to exist as separate binaries (newfs.jfs, fsck.jfs), as is currently done with the EXT2FS filesystem. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [SUGGESTION] - JFS for FreeBSD
Most current users will probably not like the speed penalties of a journal file system, and stick to the faster FS. On the other hand a solid journal FS may encourage more take up for back end databases, for e-commerce, data warehousing, etc... The transaction support of JFS isn't really viable for large-scale database implementations because it imposes a real speed penalty. Most large-scale DB2 or Oracle installations use raw disk, and let the transaction support in the database keep everything sane. The real benefit of JFS (or any other journaling FS) is to provide a transactional guarantees for everyday disk activites. The best example I can think of is a large multi-user UNIX box in a programming environment, with multiple CVS trees, local working copies of code, and lots and lots of updates (compiles, checkouts, search-and-replace, etc.) It is in this kind of environment that you want the assurance that any update will either pass or fail -- nothing in between to cause corruption that could potentiall remain undetected and eventually snowball into an unusuable filesystem. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: about boot0
I believe it's because the boot loader goes by partition type. All Microsoft operating systems can use FAT (either FAT16, FAT32 or both). The boot loader can't tell what operating system you've got installed on your FAT partition, so it goes with the lowest common denominator - DOS. -- Matt Emmerton hi all, is there a reason behind.. why all Windows related boot options are marked as DOS?... src/sys/boot/i386/boot0.s is it because of the 512-byte limit... = -Hiten, Thank You, Yours Sincerely, Hiten Pandya, [EMAIL PROTECTED] http://www.geocities.com/hitmaster2k __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD performing worse than Linux?
FWIW, I'm seeing this as well. However, this appears to be a new occurance, as we were using a FreeBSD 3.X system for our reference test platform. I recently updated it to FreeBSD 4.4-RELEASE, and I'm getting nothing but complaints about broken connections, poor performance, and very inconsistent results. Most likely between 3.x and 4.4-REL the driver for the network card(s) that you're using got changed, and are now causing problems. Many drivers are now much more picky about media problems, so it would be wise to make sure that the hosts on the local LAN segment aren't a) filling the LAN with garbage from a bad cable, and b) the FreeBSD is hooked to the LAN with a good cable. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: meteor driver problems
My guess every computer that you used to test the card uses the PCI 2.x chipset. Correct. In fact, they're all identical: Asus P2B-D(S) dual PII mainboards (at various clock speeds), so I'm a bit surprised that I'm only having issues with two of them (so far, *knocking on wood*). Well, clock speed could be a factor. Are they all running the same BIOS revision? You may wish to upgrade (or downgrade) them as an experiment. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Does DDB's watch feature actually work?
I've been using DDB the last few days attempting to track down a supposed bug in our TCP/IP stack. (See PR/31746). From what I've been able to tell so far (using the ugly insert-printf-here mechanism of debugging), a structure is getting zeroed which is causing the problem reported in the PR. So, I decided to learn how to use DDB, and set a watch on the data element that's getting blown away. The problem is, once I've got a watch in place, the system traps (page fault) at the strangest locations in the networking code -- %eip is nowhere near any code that modifies the data that I'm watching. There is a note in the ddb(4) man page, that states that attempts to watch wired kernel memory may cause unrecoverable errors in some systems such as i386. Is this the cause of what I'm seeing? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Tracking down BTX halted
Doug Write wrote: On Fri, 16 Nov 2001, Sandeep Joshi wrote: I changed the disklabels on a few SCSI disks and now I keep getting these BTX halted messages every time I reboot. Lemme guess, you're running them in 'dangerously dedicated' mode. There is a bug in Adaptec BIOSen that they will not tolerate DD disks. Which controllers have this bug? I've got a whole bunch of 7880 and 79xx controllers with disks running in DD mode and never have had this problem. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Simple x86 assembler question
Hi all, This weekend I decided to do some assembly hacking on some object-only code that I've lost the C source for. Since I haven't coded assembler for at least 8 years, and I threw my x86 assembly manuals out when I moved 6 months ago, there are a few things that are stumping me. In particular, am I interpreting these instructions correctly? 0x80839fb uttstrbyt+43: movzbl (%edx,%eax,1),%eax Takes %eax + %edx, obtains the byte value in memory at that address, zero-extends and places into %eax 0x80839ff uttstrbyt+47: movzwl 0xe90(%ebx,%eax,2),%edx Takes %eax + %ebx + 0xe90, obtains the word value in memory at that address, zero-extends and places in %edx. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Adding support for Duxbury PCI modem to FreeBSD 4.4
On Tue, 16 Oct 2001, Peter van Heusden wrote: On Mon, Oct 15, 2001 at 09:35:58AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Peter van Heusden writes: I'm having a look at the Linux 2.4 kernel code, since they apparently have winmodem support (including for the SM56 chipset, which is now no longer supported by Motorola - double Aaaargh!), but will probably have to go with an external modem, since it seems to be impossible to get internal PCI non-winmodems. 3Com makes a PCI hardware (non-Winmodem) modem. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328
What OS is running on the NFS client and server? -- Matthew Emmerton || [EMAIL PROTECTED] GSI Computer Services || http://www.gsicomp.on.ca On Tue, 25 Sep 2001, Brian Reichert wrote: I'm starting to see errors in /var/log/messages under 4.2-RELEASE: Sep 23 00:31:17 bmdb1 /kernel: got bad cookie vp 0xe2e5ef80 bp 0xcf317328 Not many, but more than one, and I've never seen this in my years of using FreeBSD. The code producing this message is in /usr/src/sys/nfs/nfs_bio.c, with this associated comment: /* * Yuck! The directory has been modified on the * server. The only way to get the block is by * reading from the beginning to get all the * offset cookies. * * Leave the last bp intact unless there is an error. * Loop back up to the while if the error is another * NFSERR_BAD_COOKIE (double yuch!). */ Is this an error that I need to worry about? Is this just my NFS client loosing track of some bookkeeping details? -- Brian 'you Bastard' Reichert [EMAIL PROTECTED] 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 Since this device is recognized by the kernel as 'ugen0', it doesn't know that it's a storage unit, and explains why you can't mount it. In order to use this device, you'll have to update the USB subsystem to recognize this device as a storage unit, and perhaps do some other code hacking before you can access it as a SCSI disk. Hopefully someone else on the list can provide you with more details (as in, how do I do what I need to do to get this thing working!) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: perhaps one of phk's intern projects?
On Thu, 26 Jul 2001, Matthew Jacob wrote: It'd be nice if one could pass a time specification to at in the form of next reboot. -matt Why not just write a script for the command and stick it in /usr/local/etc/rc.d? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
Richard Hodges wrote: Sure, no argument there. Taking Wes' suggestion, maybe there is an opportunity in the official distribution distinction. How about a certificate of authenticity which costs the vendors $1 or $2 (or whatever), and shows the customer that their choice of vendors helped FreeBSD financially. Incidentally, this certificate might also be a selling point for those twisted individuals that just don't understand free software :-) Now that's an idea, but it raises problems with shipping the certificates across national borders, causing import duties, etc. Maybe if we made the certificates in PostScript or even fig files. ;^) I'm not sure how much of a difference the certificate would make, as far as import duties goes. I live in Canada (Toronto, Ontario), and accoriding to new rules that came into effect on Jan 1/2001, my CDs (which are considered computer programs, electronic media) are now subject to 5% duty, 7% GST, 8% provincial tax, plus a $5.00 handling charge by Canada Post. (So much for NAFTA!) So on a USD$30 set of CDs (CAD$45), that works out to be about $15 in taxes and fees due to the classification. I don't see how a certificate would change that for the worse. (Well, unless the discs started being shipped via UPS. Then I'd get dinged for a $20 handing fee instead of $5.) For those in Europe or Australia, I'm not sure what the import rules are, but I'm sure they already have to pay some sort of import duties, and I don't see how the inclusion of a certificate would change that for the worse. I do like the idea of a certificate, but unless it's flashy like MS's, it might not make much of a difference to management. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: rpc.statd
On Wed, 6 Jun 2001, Dan Phoenix wrote: Jun 6 18:48:10 www rpc.statd: invalid hostname to sm_stat: ^XF7FFBF^XF7FFBF^ZF7FF BF^ZF7FFBF%8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hnM-^PM-^PM-^PM-^PM-^PM-^PM-^PM-^PM- [ snip ] It's some l33t h4x0r attemting to use a Linux RPC exploit against your FreeBSD machine. From what I've been told, It's harmless (since FreeBSD never had the hole that Linux did), and I see it quite often on some of the public boxes that I run. Are you absolutely sure that this was the cause of your kernel panic? -- Matt Emmerton GSI Computer Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: no keyboard
On Sat, 5 May 2001, Ceri Storey wrote: On Sat, May 05, 2001 at 08:54:18PM +0200, Ingo Flaschberger wrote: Note : this is a way to kill your keyboard : an AT keyboard is not hot-plug compatible i have never killed a keyboard with un / plugging. at linux it works. Well, it works, until your keyboard does actually break :) I've toasted lot of keyboards this way (Fujitsu POS no less). I have found that IBM keyboards take the punishment quite well. At least I can count on IBM engineering. As a result, that's the only type of kbd we keep in our datacenters. While IBM keyboards are good (I've hot-plugged and otherwise abused a few in my day), IBM computers have had their share of faulty engineering. A high school I worked at once had quite a problem with some IBM PS/1 desktops, which exhibited the following traits: - hot-plugging a keyboard would either fry the keyboard or damage the MB (still usuable, just no KB support) - hot-plugging a keyboard into the PS/2 mouse port (no thanks to some badly oriented labels) would provide a few sparks, some smoke, and a toasted keyboard and MB. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Problem with device rl
-BEGIN PGP SIGNED MESSAGE-
Maybe this isn't right mailing list to send this problem but here it is:
I have D-Link DFE-530TX+ and in LINT I read that I should use device rl
for this Network card but kernel don't want to find it only output off
kernel is :
pci0: unknown card (vendor=0x1186, dev=0x1300) at 13.0 irq 11
This should be that card.I read all posts from docs.freebsd.org and I
couldn't find how to solve this problem.
Version of FreeBSD is 4.2 and line in kernel is :
device miibus
device rl
You're doing the right thing, but sadly the driver hasn't been updated to
support the DFE-530TX+ and the DFE-538TX/R cards.
If you feel comfortable patching kernel source code, the following patches
will add support for the DFE-530TX+ card.
[ Thanks to Bill Paul for posting these patches on the -net mailing list
last month. ]
--
Matt Emmerton
*** if_rl.c.orig Sun Mar 25 19:08:34 2001
--- if_rl.c Sun Mar 25 23:14:00 2001
***
*** 149,154
--- 149,156
Delta Electronics 8139 10/100BaseTX },
{ ADDTRON_VENDORID, ADDTRON_DEVICEID_8139,
Addtron Technolgy 8139 10/100BaseTX },
+ { DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS,
+ D-Link DFE-530TX+ 10/100BaseTX },
{ 0, 0, NULL }
};
***
*** 898,904
rl_read_eeprom(sc, (caddr_t)rl_did, RL_EE_PCI_DID, 1, 0);
if (rl_did == RT_DEVICEID_8139 || rl_did == ACCTON_DEVICEID_5030 ||
! rl_did == DELTA_DEVICEID_8139 || rl_did == ADDTRON_DEVICEID_8139)
sc-rl_type = RL_8139;
else if (rl_did == RT_DEVICEID_8129)
sc-rl_type = RL_8129;
--- 903,910
rl_read_eeprom(sc, (caddr_t)rl_did, RL_EE_PCI_DID, 1, 0);
if (rl_did == RT_DEVICEID_8139 || rl_did == ACCTON_DEVICEID_5030 ||
! rl_did == DELTA_DEVICEID_8139 || rl_did == ADDTRON_DEVICEID_8139 ||
! rl_did == DLINK_DEVICEID_530TXPLUS)
sc-rl_type = RL_8139;
else if (rl_did == RT_DEVICEID_8129)
sc-rl_type = RL_8129;
*** if_rlreg.h.orig Sun Mar 25 19:08:34 2001
--- if_rlreg.h Sun Mar 25 19:10:12 2001
***
*** 433,438
--- 433,448
#define ADDTRON_DEVICEID_8139 0x1360
/*
+ * D-Link vendor ID.
+ */
+ #define DLINK_VENDORID 0x1186
+
+ /*
+ * D-Link DFE-530TX+ device ID
+ */
+ #define DLINK_DEVICEID_530TXPLUS 0x1300
+
+ /*
* PCI low memory base and low I/O base register, and
* other PCI registers.
*/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: thoughts on /etc/newsyslog.conf
Hello, In writing an article on syslogd and newsyslog, I've noticed something intensely annoying about newsyslog.conf. FreeBSD supports three different formats for dates in newsyslog.conf: raw hours since last rotation, ISO 8601, and FreeBSD-specific week-day-month. Wouldn't it make sense to standardize on one or the other of ISO8601 or W-D-M for the default newsyslog.conf? You need 'raw hours' format to support relative times, commonly used with size parameters to control the growth of web logs. (ie "Rotate when size 10M or 6 hours from last rotate") You need ISO8601 to support rolling on fixed dates (1st of the month, etc.) You need 'W-D-M' format to support rolling on a weekly/monthly/daily basis. This can't be done using ISO8601 because ISO uses fixed dates. (How would you specify rotating every monday using ISO8601, when the date of every monday changes from month to month and year to year?) As a point of reference, cron's time/date parameters are functionally a combination of W-D-M and ISO8601. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sigh... ypserv bug still very much alive
The ypserv bug (the one where ypserv randomly stops responding or just seg-faults) is still very much alive. I had to restart it about 11 times in the course of 20 minutes this morning. That's the bad news, the good news is that I started it each time with 'ktrace -i'. Also, in the last 200 lines of kdump output for each and every crash there is the sequence of calls "select(); gettimeofday();"... that sequence of calls never appears in the ypserv source code, but does appear in svc_tcp.c in librpc... my question is: "ypserv defines its own svc_run, and for TCP connections specifically handles things itself very carefully, how is the svc_tcp.c code getting called at all?" I think the answer to that is the source of the problem (it should also be noted that in the case where ypserv hasn't died and I have collected ktrace information -- up to 8 gig of it -- the "select(); gettimeofday();" sequence is _never_ called.) I have virtually no experience with RPC or YP/NIS, but I can trace code. Here's what I found: Case #1 usr.sbin/ypserv/ypserv.c : main() calls svctcp_create() lib/libc/rpc/svc_tcp.c : svctcp_create() returns an SVCXPRT with a reference to an initialized rendezvous handler That in itself seems fine, but a rendezvous_request() op on the rendezvous handler can trigger the problem: lib/libc/rpc/svc_tcp.c : rendezvous_request() calls makefd_xprt() lib/libc/rpc/svc_tcp.c : makefd_xprt() calls xdrrec_create() with a pointer to readtcp() lib/libc/rpc/svc_tcp.c : readtcp() calls select(), gettimeofday() Case #2 usr.sbin/ypserv/ypserv.c : main() calls svc_register() lib/libc/rpc/svc_tcp.c : svc_register() calls pmap_set() lib/libc/rpc/pmap_clnt.c: pmap_set() *may* call clnt_create() lib/libc/rpc/clnt_generic.c : clnt_create() calls clnttcp_create() lib/libc/rpc/svc_tcp.c : clnttcp_create() calls readtcp() lib/libc/rpc/svc_tcp.c : readtcp() calls select(), gettimeofday() In answer to your question about "how is the svc_tcp.c code getting called at all?": In case #1, it's getting called when main() starts up and creates the initial TCP listener. In case #2, it's getting called when main() registers the services. Hopefully this will aid you (and others) in tracking down this problem. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gzip's custom i386 asm should be disabled
I sure hope I'm not the only one with a "lab" of 4 FreeBSD machines that are all 486s or 586s. You may find that the 686 assembly is as fast on a 386/486/586 as the old assembly is. Maybe you could test it and let the list know? I was under the impression that the 586/686 code uses instructions that are not present on 386/486 machines, so I doubt that it would help. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gzip's custom i386 asm should be disabled
I sure hope I'm not the only one with a "lab" of 4 FreeBSD machines that are all 486s or 586s. You may find that the 686 assembly is as fast on a 386/486/586 as the old assembly is. Maybe you could test it and let the list know? I was under the impression that the 586/686 code uses instructions that are not present on 386/486 machines, so I doubt that it would help. Bite your tongue! The youngest instruction in my patches is movzx, which was introduced with the 386. Serves me right for not looking at the patches (no thanks to my flaky cable connection.) My bad assumption that code optimized for 586/686 would be 586/686-specific. I'll go away now :) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gzip's custom i386 asm should be disabled
Since I would imagine a large percentage of FreeBSD users run on i686 cores, it'd be great to get this pretty significant speed increase into our tree. I sure hope I'm not the only one with a "lab" of 4 FreeBSD machines that are all 486s or 586s. It would be great to implement these patches for gzip in the base tree, but they need to be conditianal based on CPUTYPE in /etc/make.conf. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel area libmish stuff
Well here's the story: a few days ago my video card broke, so I'm without X and such, and using a spare 486 box on the freebsd console. Out of lack of other things to do, I did most of the porting of one of the screensavers in the xscreensaver collection to the freebsd syscons. The problem I'm having now is I dunno the _right_ way to get the trig functions from the userland libm in kernel space. _is_ there a right way? or can it be statically linked into the screensaver module? (ouch) There's probably a way to include *some* of the libm functions (from /usr/src/lib/msun, since /usr/src/lib/libm is deprecated). However, this would require a considerable amount of Makefile magic, and also require that the msun code be present in order to do a complete build of the kernel with modules. I doubt that this requirement would make you many friends in -questions :) I was thinking of just getting a sintable array and making a few simple functions, so the whole of libm doesn't need to be statically linked into the module (from my understanding, once loaded, this module wont ever get paged out, and thus it'd be _bad_ for it to be big). This is probably the best way to go, IMO. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel area libmish stuff
On Fri, 9 Mar 2001, Matt Dillon wrote: You can't safely do FP instructions in the kernel. I do not believe the FP context is saved/restored between processes in kernel mode, only from user mode. The kernel saves and restores the fp state in the few places it uses FP instructions (for memory copying). In anycase, I think there'd be a problem here. The last time I tried using FP in a device driver, it caused kernel panics (I hate it when that happens...) Seeing as the original requestor wanted to use FP functions to do number crunching in screen savers, would adding a few strategic FP save/restore calls in the syscons driver be enough to allow FP calculations in screen saver modules? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD on S/390?
On Thu, 1 Mar 2001, Robert Watson wrote:
On Wed, 28 Feb 2001, Ken Bolingbroke wrote:
Long shot, probably, but I've got a bunch of virtual machines on an IBM
S/390 mainframe, and while we're running SuSE Linux on most of them, on
a whim I tossed out the idea of running FreeBSD on one of them, and to
my surprise, it was taken seriously.
So, has anyone done any work with getting FreeBSD running on a S/390?
What can I do to make it happen if there's interest?
Well, as you've seen from the two responses already, the implicit answer
to your question of "has anyone done any work" appears to be "no" :-).
However, I think a number of us in the developer community see this as a
fairly serious gap, and would like to remedy this. However, IBM hasn't
been dropping S/390 machines and documentation in anyone's laps (at least,
not mine, and no one else has mentioned it), so the primary facilitators
would be, as with any new hardware port:
1) Access to necessary technical documentation and expertise
2) Access to hardware
3) Someone with appropriate expertise willing the guide ("own", if you
will) the port to the platform through to completion, and continue to
provide on-going maintainership in the face of adversity (someone adds
fine-grained SMP support and it falls on the maintainer to figure out
how that works on their platform, if no one has hardware).
Part of the "real answer" is probably that IBM or a large consumer of
S/390 machines has to shepherd the whole process to make it happen, and
that probably involves a moderate amount of money, and moderate levels of
frustration. If you can provide access to the first and survive the
second, then you can certainly make this a reality. If not, well, it
would be nice to see it happen but the task is to identify someone who can
provide these.
Well, I'm starting with IBM in May at their Toronto Labs. All of my
managers were particularly interested in my non-Linux open source activity
(what is this FreeBSd thing that you talk about?)
I'm not promising anything, but I too would *love* to get IBM supporting
FreeBSD in some way. Perhaps a version of JFS released under the BSD
licence would be a start, and then hardware support for RS/6k and S/390.
I will keep my eyes and ears open for anything useful that falls my way.
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates performance
On Mon, 12 Feb 2001, Jordan Hubbard wrote: One other point that I would like to understand is why -j4 takes longer on all of my systems. That goes against what everyone claims should happen. With how many running processors? If you're running -j4 on a uniprocessor system, you're only introducing competition for already scarce CPU resources, though -j2 can be a speedup since this allows one target build to run while another is in an I/O wait. I've only seen a speedup with -j4 when using at least 2 CPUs. FWIW, I've got an ancient dual-CPU machine (Pentium 133s) with an onboard Adaptec 7870 hooked to a pair of SCSI-2 drives. With any intensive build activity (make buildworld, or a kernel recompile), -j8 gives me the best results. (I came to this conclusion after profiling a kernel build using -j2/4/6/8/10/12.) The only explanation I can give in my case is that the onboard 7870 is a PCI device and is the main bottleneck in the system (my motherboard is a very interesting EISA/PCI combo, mfgd in 1991). Although Jordan's quite right in saying that using anything larger than -j2 on a uniprocessor machine will usually be futile, in the world of SMP things are much stranger, so it's good to experiment. (-j8 is about a 50% speedup over -j2). YMMV. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mount checking for read-only media
In message [EMAIL PROTECTED] Kenny Drobnack writes: : Up there on my wish list is getting a journaling : filesystem ported to FreeBSD. You may wish to check out IBM's JFS port for Linux (http://oss.software.ibm.com/developerworks/opensource/jfs/) It's released under the GPL. The nice thing about it is that there's 25 point-in-time releases, each enabling a new feature, which makes for easy testing. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall kernel modules on 3.0-release
On 7 Feb 2001, Dag-Erling Smorgrav wrote: Matthew Luckie [EMAIL PROTECTED] writes: I completely understand your plea to not use 3.0 release. I am personally using 4.2-stable. Its not my decision to use 3.0 I beleive the computers running 3.0 have been running it for several years now - i.e. it was the latest available at the time. Well, it was a stupid decision at that time, and the decision not to upgrade or replace these machines now is even stupider. Hey now, go easy. Lots of stupid decisions are made by "managers" who don't understand the implications of old(er) technology. I've got a 3.2-R machine which I'm forced to maintain, and the only reason why it's not running 3.2-S or 4.2-S is because I can't take the stupid thing offline. I've haggled with my boss for a 6 hour window and the answer is no, no, no. I've even got a 3.2-S installation waiting in /usr/obj. The only way I'm going to get my 3.2-R machine upgraded (and the only way this person is going to get their 3.0-R machine upgraded) is when it breaks and requires a complete reinstall to become operational. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syscall kernel modules on 3.0-release
On Thu, 8 Feb 2001, Dan Langille wrote: On 7 Feb 2001, at 21:14, Matthew Emmerton wrote: On 7 Feb 2001, Dag-Erling Smorgrav wrote: Matthew Luckie [EMAIL PROTECTED] writes: I completely understand your plea to not use 3.0 release. I am personally using 4.2-stable. Its not my decision to use 3.0 I beleive the computers running 3.0 have been running it for several years now - i.e. it was the latest available at the time. Well, it was a stupid decision at that time, and the decision not to upgrade or replace these machines now is even stupider. Be careful how you criticize. Hey now, go easy. Lots of stupid decisions are made by "managers" who don't understand the implications of old(er) technology. I've got a 3.2-R machine which I'm forced to maintain, and the only reason why it's not running 3.2-S or 4.2-S is because I can't take the stupid thing offline. I've haggled with my boss for a 6 hour window and the answer is no, no, no. I've even got a 3.2-S installation waiting in /usr/obj. What about replacing the box with a new box? Smaller window. Unfortunately, all management sees is the $2000+ cost of a new box. (I'm sure that in both my case and the other case, management has spent more than that in the additional labour required to work around the "features" of the older box.) The only way I'm going to get my 3.2-R machine upgraded (and the only way this person is going to get their 3.0-R machine upgraded) is when it breaks and requires a complete reinstall to become operational. It might pay to send an email to your boss, cc'd to yourself explaining this. I've seen some managers who make decisions such as that and then blame others when the crap hits. That might work, but that requires boss/manager to have some idea of the technical implications of a) upgrading and b) remaining with old OS. Depending on the organization, the situation may be next-to-impossible. (And no saying I-told-you-so when it eventually breaks.) -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make top better
Hi, "top" always puts CPU idle time in last, but I think in CPU states, idle is most important field, could anyone move idle field to first. It all depends on your focus. Someone using FreeBSD as a terminal or fax server with a whole bunch of serial devices might want "interrupt" first. Someone running an Apache / mod_perl / DBI machine might want "system" first. Someone running a server as a development / shell box might want "user" first. And someone running rc5 really doesn't care about idle or nice (since on my 3 boxes idle is usually 0.0% and nice is around 90%, which of course skews the "true" load of the system.) Furthermore, anyone using 'top -d' in a shell script to grab and report CPU usage data would have to change their scripts. With this in mind, I doubt a compelling reason can be formulated to make *any* field first, so it would be best to leave it the way it is. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving to KLM's
this isn't what i was askingFWIW, my current kernel is 1.4M :P. What i'm wanting to know is what is the minimal kernel (meaning what HAS to be there for it to boot) that can be compiled. I want to try using the KLM feature for pretty much everything (if_dc, if_ed, ipfw, nfs, etc etc), mostly just so i can learn more about FBSD. Processor support (machine, cpu), options COMPAT_43, FFS, FFS_ROOT, bus devices (device isa, pci), some sort of drive subsystem (SCSI - device ahc, scbus, da or ATA - device ata, atadisk, ata0) and system console support (device sc0, vga0) and keyboard support (device atkbdc0/atkbd0). If you want serial console support, then you can swap out the keyboard stuff for serial support (device sio) That's about the minimal stuff you need. You need bus, disk, filesystem and user input/output support in the kernel before you can load KLDs. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Moving to KLM's
ok, what would be the minimal kernel that i can compile :), or is there a document somewhere that says that info? We have LINT, should we make something called MIN for minimal kernel needed to boot? It's not really feasible to create a "minimal" kernal, since "minimal" really depends on your hardware (the most obvious -- do you need ATA or SCSI to boot? which network drivers do you need?) The easiest way to create MIN is to take GENERIC and take out absolutely everything that you don't have or need. I think my best effort so far is on a little 486 gateway box for my home lan which weights in at 1.7MB. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Atomic bit operations
Hi all, I've taken a look around for an implementation of atomic bit operations in FreeBSD (similar to Linux' asm/bitopt.h, which include clear_bit() and test_and_set_bit()) but haven't found any. The only thing I've found are the atomic clear/set/add/sub routines in machine/atomic.h. Do we have an implementation of atomic bit operations, and if we don't, would we like some? -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Atomic bit operations
On 01-Feb-01 Matthew Emmerton wrote:
On 31-Jan-01 Matthew Emmerton wrote:
Hi all,
I've taken a look around for an implementation of atomic bit
operations
in
FreeBSD (similar to Linux' asm/bitopt.h, which include clear_bit()
and
test_and_set_bit()) but haven't found any. The only thing I've found
are
the atomic clear/set/add/sub routines in machine/atomic.h.
Do we have an implementation of atomic bit operations, and if we
don't,
would we like some?
Erm, atomic_set() sets's bits, and atomic_clear() clear's bits.
Anything
else
you might need can be done with atomic_cmpset() anyways.
Where are these functions implemented? /usr/include/machine/atomic.h
just
has atomic_set_XXX and clear_XXX primitives, which work on
char/short/longs,
but not individual bits.
1) You need to look in -current.
I only recently moved to 4-stable, so I'm not going to jump to -current
quite yet :)
2) atomic_set_int(my_int, 4); sets bit _2_ in the integer variable
my_int.
Make sense? You can't address individual bits on a machine. :-P
I presume that I could wrap the char operations with something that
takes
0x01 and bit-shifts it appropriately so that atomic_set/clear could be
used.
Hmm, so you mean the API is atomic_set(foo, x) implies foo |= 1 x?
That means you can't set more than 1 bit atomically, which is a bit
limiting.
Yes, but it's the API used by some code I recently inherited. (Recall that
this API is Linux's asm/bitops.h) I realize that the existing
atomic_xxx_xxx functions are much more flexible than bit-based ones, but
wouldn't it make sense to have the full complement of functions available?
However, certain other primitives are missing, such as an atomic
test-and-set operation. Under the current scheme this would have to be
done
by two independent operations, which is not useful when atomicitiy is
required.
do {
x = my_int;
while (atomic_cmpset_int(my_int, x, x | foo) == 0);
if (x foo)
foo_was_already_set;
else
foo_was_not_already_set;
I had based my assumptions on what I saw in 4-stable, which doesn't have
atomic_cmpset. I'll have to take a peek at 4-current or wait until some
features trickle down to 4-stable.
Thanks,
--
Matt Emmerton
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Atomic bit operations
On 31-Jan-01 Matthew Emmerton wrote: Hi all, I've taken a look around for an implementation of atomic bit operations in FreeBSD (similar to Linux' asm/bitopt.h, which include clear_bit() and test_and_set_bit()) but haven't found any. The only thing I've found are the atomic clear/set/add/sub routines in machine/atomic.h. Do we have an implementation of atomic bit operations, and if we don't, would we like some? Erm, atomic_set() sets's bits, and atomic_clear() clear's bits. Anything else you might need can be done with atomic_cmpset() anyways. Where are these functions implemented? /usr/include/machine/atomic.h just has atomic_set_XXX and clear_XXX primitives, which work on char/short/longs, but not individual bits. I presume that I could wrap the char operations with something that takes 0x01 and bit-shifts it appropriately so that atomic_set/clear could be used. However, certain other primitives are missing, such as an atomic test-and-set operation. Under the current scheme this would have to be done by two independent operations, which is not useful when atomicitiy is required. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Atomic bit operations
On 01-Feb-01 Matthew Emmerton wrote: 2) atomic_set_int(my_int, 4); sets bit _2_ in the integer variable my_int. Make sense? You can't address individual bits on a machine. :-P I presume that I could wrap the char operations with something that takes 0x01 and bit-shifts it appropriately so that atomic_set/clear could be used. Hmm, so you mean the API is atomic_set(foo, x) implies foo |= 1 x? That means you can't set more than 1 bit atomically, which is a bit limiting. Yes, but it's the API used by some code I recently inherited. (Recall that this API is Linux's asm/bitops.h) I realize that the existing atomic_xxx_xxx functions are much more flexible than bit-based ones, but wouldn't it make sense to have the full complement of functions available? If you don't want to patch the code, then you can use a local wrapper in your code in the form of a suitable macro. We already have one atomic API, we don't need to maintain 2. :) Well, I wasn't proposing to implement the entire Linux API, rather add 'bit' to the the existing list of 'char, int, long' that is currently supported. It wouldn't be too difficult, and some people might even find it convenient. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SVR4 Emulation [was Re: iBCS status?]
On Wed, Jun 07, 2000 at 10:24:15PM -0400, Matthew Emmerton wrote: brandelf will really understand any brand at all; We just add special cases to suppress the need for -f for "known" brands. As it happens, though, there's no reason why you can't run "brandelf -f -t BOGUS-BOGUS foo" and have it put a BOGUS-BOGUS brand into an ELF object called foo. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) Well, yes, that's the thing - Branding is, AFAICT, specific to FreeBSD and Linux ELF; All other OSs need either a heuristic to select the appropriate emulator (for example, the pathname to the ELF interpreter in the executable, which doesn't always work), or an explicit branding, or an appropriate setting of the kern.fallback_elf_brand sysctl MIB variable. Even more interesting is the SCO document on how ELFs are pseudo-branded. OpenServer 5: No brand, but have a 28-byte NOTE field. UnixWare 7: No brand, but have one of the flags set in the FLAG field. (I couldn't find anything more specific than this.) -- Matthew Emmerton GSI Computer Services +1 (800) 217-5409 (Canada) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SVR4 Emulation and SCO OpenServer 5
According to the lxrun (Linux Emulator for SCO) documentation and the Debian ibcs2/svr3 emulator package, OpenServer 5 is SVR3 (with extension for symbolic links and a few other goodies.) SCO documentation backs up the SVR3lineage for OSR5, and verifies that UnixWare 2 and 7 are SVR4 and SVR5, respectively. The SVR3 heritage would explain why a few test programs that I wrote performing simple system calls (exec, fork, chdir, etc) fail under the SVR4 emulator, because they're trying to execute syscall 40 which is undefined in SVR4 -- but refers to the xenix call gate under ibcs2/svr3. If this is indeed the case, the ibcs2 code will need to modified to support ELF executables so that SCO OpenServer 5 binaries can be run under the ibcs2/svr3 emulator, with appropriate changes being made to allow the SCO extensions. --Matthew EmmertonGSI Computer Services+1 (800) 217-5409 (Canada)
Re: SVR4 Emulation [was Re: iBCS status?]
To fix it in as painless a way as possible, I'm envisaging something along the lines of this: * The existing svr4 KLD module, which implements the guts of the emulator; and * Additional much, much smaller modules which implement the differences between the "base" svr4 and wierd oddball variants. Modularity seems to be the most logical way to go. The ibcs2 stuff was sortof written like this (ibcs2.ko, and then ibcs2_coff.ko handled all the COFF-specific stuff; yes, it's quite different, but the concept was similar.) Each variant would have its own ELF brand to aid the selection of the correct API. Makes sense. On a related note, I'm curious to see how this will integrate into existing non-kernel tools. For example, truss and brandelf) only understand BSD and Linux ELF binaries, and will require modifications to identify all the different brands. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) -- Matthew Emmerton GSI Computer Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
iBCS status?
Hi all, I was recently playing around with iBCS support in FreeBSD 3.4/4.0, and noticed that there hasn't been much done since 96/97. >From what I can see now, FreeBSD can't run SCO OpenServer 5.0 ELF binaries, which is a feature I need desperately -- Linux has this functionality. If anyone is working on iBCS, let me know, otherwise I'll start hacking away at the the emulation code to allow SCO OSR5 ELF stuff. Thanks, --Matthew EmmertonGSI Computer Services
