Re: C++ code in a kernel module?

[Matthew Emmerton]

> 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

[Matthew Emmerton]

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

[Matthew Emmerton]

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]"

Re: RFC: Change to sys_errlist

[Matthew Emmerton]

- Original Message - 
From: "John-Mark Gurney" <[EMAIL PROTECTED]>
To: "Matthew Emmerton" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 04, 2003 2:50 PM
Subject: Re: RFC: Change to sys_errlist


> Matthew Emmerton wrote this message on Fri, Jul 04, 2003 at 14:03 -0400:
> > 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.
>
> This is not good.  This will just encourge more programers to not properly
> test return values.  Read man 2 errno says: "Successful calls never set
> errno;", so this depends upon the programmer initalizing errno to 0
> before they make their call.  If they are already so poor as to be
> calling perror, etc with errno 0, then I doubt that we can depend upon
> them initalizing errno to 0 and giving consistant results.

You're right.  Furthermore, SUSv3 indicates that errno is a positive
integer; this presumably excludes 0 so our existing implementation is fine.

I guess I'll have to bring this up with the Linux folks and see if they'll
change.

--
Matt Emmerton

___
[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

[Matthew Emmerton]

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 

 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

>
> > > 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

[Matthew Emmerton]

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: sis900 : sis0 attach returned 6

[Matthew Emmerton]

> > 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:  port 0xd000-0xd0ff mem 0xcfffc000-0xcfffcfff
> irq 12
>   at device 3.0 on pci0
> sis0: Ethernet address: 00:d0:09:de:34:ee
> miibus0:  on sis0
> rlphy0:  on miibus0
> rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> rl0:  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:  on rl0
> rlphy1:  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: sis0 - phy problem

[Matthew Emmerton]

> hi,
> i also encounter problem with sis0 nic onboard. here is an
> extract from dmesg:
>
> FreeBSD 4.6.2-RELEASE
>
> sis0:  port 0xd400-0xd4ff mem 0xe780-0xe7800fff
irq \
>   at device 1.1 on pci0
> sis0: Ethernet address: 00:00:00:00:00:00
> miibus0:  on sis0
> ukphy0:  on miibus0
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> ohci0:  mem 0xe700-0xe7000fff irq 5 at device
1.2 on pci0
> usb0: OHCI version 1.0, legacy support
> usb0:  on ohci0
> [...]
> rl0: Ethernet address: 00:50:22:9b:c7:24
> miibus1:  on rl0
> rlphy0:  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

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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:  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  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)

[Matthew Emmerton]

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

[Matthew Emmerton]

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.

[Matthew Emmerton]

> > 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

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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.

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

Re: Reading BIOS from userland

[Matthew Emmerton]

> > 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

Reading BIOS from userland

[Matthew Emmerton]

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: sar on FreeBSD

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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: [SUGGESTION] - JFS for FreeBSD

[Matthew Emmerton]

> * 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: about boot0

[Matthew Emmerton]

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]>
> 
>
> __
> 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?

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> > 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?

[Matthew Emmerton]

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"

[Matthew Emmerton]

> 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

[Matthew Emmerton]

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 :   movzbl (%edx,%eax,1),%eax


Takes %eax + %edx, obtains the byte value in memory at that address,
zero-extends and places into %eax

0x80839ff :   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

Sizing a Streaming Media Server

[Matthew Emmerton]

Folks,

I very interesting project just landed in my lap -- I need to setup a
FreeBSD server to be a streaming media server for 1000+ clients using
Nullsoft's Shoutcast.

I have some experience with streaming media, so I know how to size the
network side of the equation, but what I'm really at a loss for is how much
processing power a server will need to do this effectively, and better yet,
how to properly tune the FreeBSD machine to handle that many simultaneous
clients.

If anyone has any experience with this sort of thing, or has any advice,
please contact me directly.

Thanks,

--
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

[Matthew Emmerton]

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

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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?

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

On Wed, 6 Jun 2001, Dan Phoenix wrote:

> 
> Jun  6 18:48:10 www rpc.statd: invalid hostname to
> sm_stat: ^X^X^Z
> 
>^Z%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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> -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:  (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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> >>> 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

[Matthew Emmerton]

> > 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> > 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?

Please forget I ever said this. I took a look at what would be involved, and
it's wa too deep for me to even begin about thinking about it.

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Kernel area libmish stuff

[Matthew Emmerton]

> 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: Kernel area libmish stuff

[Matthew Emmerton]

> 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: FreeBSD on S/390?

[Matthew Emmerton]

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: Switching from buildkernel to config seems to recompile the entire kernel

[Matthew Emmerton]

> I cvsup'ed my 4.2-stable box and did the usual
> make buildworld
> make buildkernel KERNCONF=
> where KNAME is the name of theconfig file
> make installkernel KERNCONF=
> make installworld
>
> and then rebooted the box. A short while I modified my kernel config
> to remove sl and ppp. I then did a /usr/sbin/config 
>
> This seems to recompile all the modules and the entire kernel even though
> I expected only a few things to be recompiled and the kernel relinked

A surprising number of things get recompiled when the slightest change is
made to a kernel configuration. I've often wondered myself why removing one
line (such as psuedo-device bpf) forces lots of stuff to be recompiled (like
the ahc driver).

--
Matt Emmerton


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: ADSL and PPPoE question

[Matthew Emmerton]

> On Mon, 12 Feb 2001 08:20:55 -0800, Julian Elischer wrote:
> >  [EMAIL PROTECTED] wrote:
> >  >
> >  > I'm very sorry if this is a stupid question.
> >  >
> >  > In our company, we want to set up a small network of about 20 PCs.
> ADSL
> >  > seems like a good inexpensive solution, and I understand that FreeBSD
> with
> >  > Netgraph can act like a gateway for our computers.
> >
> >  are they in different places?
>
> No - the same place.
>
> >  Negraph/ppp can act as a gateway for pppoe connections but I am not
sure
> >  how that helps you. How do you get the ADSL sessions to terminate on
> >  an ethernet in your office?
> >  (does your ISP provide that service?)

Where I come from (Ontario, Canada), there are two predominant forms of DSL
service.  Residential DSL provides a DSL modem, which you need to talk PPPoE
to, or Commercial DSL, which provides a DSL modem and a Cisco 1600.

If you're going to get hardware equivalent to the "Residental DSL" service,
then you can use PPPoE on FreeBSD to connect.  If your ISP will provide you
with a router, then you don't have to worry about the PPPoE stuff.

In both cases, I believe you'll have to run routed in order to route the
block of IPs into via your firewall node to your internal network, or use
NAT to do a 1-1 mapping of public routable IPs to private 192.168.x.x
addresses.

--
Matt Emmerton



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: soft updates performance

[Matthew Emmerton]

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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

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: syscall kernel modules on 3.0-release

[Matthew Emmerton]

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: make top better

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

Re: Atomic bit operations

[Matthew Emmerton]

> 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: Atomic bit operations

[Matthew Emmerton]

> 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

[Matthew Emmerton]

> 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

Atomic bit operations

[Matthew Emmerton]

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

SVR4 Emulation and SCO OpenServer 5

[Matthew Emmerton]

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 SVR3 lineage 
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?]

[Matthew Emmerton]

> 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

Re: SVR4 Emulation [was Re: iBCS status?]

[Matthew Emmerton]

> 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

Re: SVR4 Emultaion [was Re: iBCS status?]

[Matthew Emmerton]

> In the last episode (Jun 06), Mark Newton said:
> >  > There is
> >  > apparently quite a difference between Solaris and SCO SVR4; the first
> >  > thing I had to do was change the lseek() syscall to use 32-bit
offsets
> >  > instead of 64-bit, for example.
> >
> > Interesting - Solaris has two lseek syscalls, notionally "lseek" and
> > "lseek64".  If SCO only has one, which is a 64 bit variant, could
> > you perhaps let me know what its syscall number is?
>
> SCO OSR5 has only the 32-bit variant at syscall 19, and its args match
> the ibcs2_lseek syscall (int fd, long offset, int whence). UW7
> apparently has two additional syscalls: lseek32 and lseek64, but I
> don't know what numbers they are; I don't have UW7.

I work at a SCO shop that uses the Progress RDBMS extensively.  (I'm working
on writing the Perl DBD module for it as we speak.)  Once I get that hacked
out, I'll take a look at the svr4 stuff and offer any SCO-related fixes that
are needed.

And while we're on the topic, has anyone looked at the svr4 emulation stuff
for Linux, most notably Debian?  According to this link
(http://www.debian.org/Packages/stable/otherosfs/ibcs-base.html), it has SCO
SVR3 as well as SCO ODT5 (SVR4) support.  This may have already covered a
lot of the hairy issues (like syscall mappings). I realize it is dated (late
97), but anything helpful is better than nothing :)

--
Matthew Emmerton
GSI Computer Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

iBCS status?

[Matthew Emmerton]

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