headers
Joel Wood | 1 Nov 2002 04:18

Re: FYI: FreeBSD and Intel/ICP Vortex Raid-Controllers

Also, incase your intrested, you can also use icpcon with the iir driver
incase you want to fool with the raid from userland.  icpcon looks alot
like the interface you get when booting.  You can look for failures,
rebuild the raid, and get statistics.

To use icpcon, you just need to:

mknod /dev/iir c 164 0
ln -s /dev/iir /dev/icp

You can get icpcon as part of the icp freebsd driver zip from
icp-vortex.com.

-Joel

On Wed, 30 Oct 2002, Kai Gallasch wrote:

> Hi,
>
> a few days ago I looked through the LINT file of the stable kernel
> sources and
> wondered if the "iir" RAID device would also support the ICP vortex line
> of RAID controllers (INTEL recently bought the manufacturer ICP and
> with it its whole
> productline of controllers)
>
> So I asked one of the contacts for the "iir" named in the LINT -
> achim.leubner <at> intel.com -
> if ICP Vortex controllers are also supported..
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Sinz | 1 Nov 2002 13:23

Socket so_linger setting

During some parameter limit checking work, I ran into what I believe to
be an error in FreeBSD.  (Albeit unlikely to be hit)

A setsockopt of the SO_LINGER field will cause strange results if
the value is set above 32767.

This is due to the fact that in struct socket, the so_linger field
is a signed short and the parameter passed to setsockopt for linger
is a signed long.

What happens is that any value between 32768 and 65535 will cause
so_linger to be negative.  And then getsockopt will return a sign
extended negative value in the signed long field for linger.

The "trivial" fix is to do the following:

------------------------------------------------------
--- uipc_socket.c       Wed May  1 01:13:02 2002
+++ /tmp/uipc_socket.c  Fri Nov  1 06:55:10 2002
 <at>  <at>  -1139,7 +1139,8  <at>  <at> 
                         if (error)
                                 goto bad;

-                       so->so_linger = l.l_linger;
+                       /* Limit the value to what fits in so_linger */
+                       so->so_linger = (l.l_linger > SHRT_MAX ? SHRT_MAX : l.linger);
                         if (l.l_onoff)
                                 so->so_options |= SO_LINGER;
                         else
------------------------------------------------------
(Continue reading)

Permalink | Reply | 5 comments |
headers
Robert Watson | 1 Nov 2002 19:29
Picon
Favicon

Request for submissions: FreeBSD Bi-Monthly Development Status Report Sept-Oct 2002


This is a solicitation for submissions for the September 2002 - October
2002 FreeBSD Bi-Monthly Development Status Report.  All submissions are
due by October 10, 2002.  Submissions should be made by filling out the
template found at: 

  http://www.FreeBSD.org/news/status/report-sample.xml

Submissions must then be e-mailed to the following address for automated
processing (IT HAS CHANGED): 

  monthly <at> FreeBSD.org

Reports must be submitted in the XML format described, or they will be
silently dropped.  Submissions made to other e-mail addresses will be
ignored.  If more than one report is submitted for a project, the latest
instance will be used. 

Status reports should be submitted once per project, although project
developers may choose to submit additional reports on specific
sub-projects of substantial size.  Status reports are typically one or two
short paragraphs, but the text may be up to 20 lines in length. 
Submissions are welcome on a variety of topics relating to FreeBSD,
including development, documentation, advocacy, and development processes. 
Submitting developer status reports help maintain an important link
between FreeBSD developers, as well as a link to the user and sponsor
communities.  By submitting a report, you help share information about the
rapid progress made by the project, making it easier for advocates to
point at the excellent work that's being done!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Watson | 1 Nov 2002 19:33
Picon
Favicon

Re: Request for submissions: FreeBSD Bi-Monthly Development Status Report Sept-Oct 2002

On Fri, 1 Nov 2002, Robert Watson wrote:

> All submissions are due by October 10, 2002.

Needless to say, the deadline is actually November 10, 2002.  Rather than
thinking of this as an "off the hook" scenario, think of it as an extra
month to submit the status report, starting about a month ago :-). 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert <at> fledge.watson.org      Network Associates Laboratories

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Permalink | Reply | 0 comments |
headers
Brooks Davis | 1 Nov 2002 19:54

[brooks <at> one-eyed-alien.net: [PATCH] switching to if_xname]

I'm trying to get some review for the following patch.  I realize it's
quite large, but most it is is trivial.  The ipfw code is the only thing
that worries me significantly.  I have promised Kris that I will fix
ports that break with this change so you don't need to worry about that
issue.

I'd like to commit this prior to 5.0-R pending RE approval (post DP2
would be fine if that would help get it out the door).

Thanks,
Brooks

----- Forwarded message from Brooks Davis <brooks <at> one-eyed-alien.net> -----

From: Brooks Davis <brooks <at> one-eyed-alien.net>
Date: Wed, 23 Oct 2002 20:50:38 -0700
To: net <at> FreeBSD.ORG
Subject: [PATCH] switching to if_xname

As previously discussed, I've created a patch to replace if_unit and
if_name with if_xname in struct ifnet following the example of NetBSD
and OpenBSD.  I've tried to place the more intresting parts of the diff
near the top.

This patch will break ports which use libkvm to read interface
statistics.  This effects at least wmnet and wmnet2 (though both
segfault on current without this patch).  The patches to fix this should
be trivial since most of those applications probably support NetBSD or
OpenBSD and I plan to bump __FreeBSD_version.  Other then those issues
and a generalization of interface globing in IPFW, this patch should be
(Continue reading)

Permalink | Reply | 565 comments |
headers
Nate Lawson | 1 Nov 2002 21:07

Re: [PATCH] switching to if_xname

You might also try -net or -arch.

On Fri, 1 Nov 2002, Brooks Davis wrote:
> I'm trying to get some review for the following patch.  I realize it's
> quite large, but most it is is trivial.  The ipfw code is the only thing
> that worries me significantly.  I have promised Kris that I will fix
> ports that break with this change so you don't need to worry about that
> issue.
> 
> I'd like to commit this prior to 5.0-R pending RE approval (post DP2
> would be fine if that would help get it out the door).
> 
> Thanks,
> Brooks
> 
> http://people.freebsd.org/~brooks/patches/if_xname.diff
> 
> Please review.

Couple comments.

* You interchangeably use strlcpy and snprintf(... "%s", ...) and even
strncpy/strcpy(!).  You probably want to go with just strlcpy.
* There may be some cases where a string compare is too slow and it needs
a unit compare.  I'm not familiar with the code that does this but please
comment.
* Some places seem to still be using a unit number as a local loop
counter.  Just curious if this has any side effects.
* Do the ipfw glob changes break ABI?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthew Dillon | 1 Nov 2002 21:08

Re: Socket so_linger setting

    I think your patch is fine as is, Mike!  Good find!  Even though 
    so_linger cannot be negative, it is often convenient to use a signed
    integer to store the value to avoid unexpected arithmatic results
    when mixing with signed operations.  My quick perusal does not show
    any cases of this for so_linger, so we could make it unsigned, but I
    don't see any pressing need to do so.   The range check would need
    to be in there in either case.

    Can I go ahead and commit it?

					-Matt
					Matthew Dillon 
					<dillon <at> backplane.com>

:During some parameter limit checking work, I ran into what I believe to
:be an error in FreeBSD.  (Albeit unlikely to be hit)
:
:A setsockopt of the SO_LINGER field will cause strange results if
:the value is set above 32767.
:
:This is due to the fact that in struct socket, the so_linger field
:is a signed short and the parameter passed to setsockopt for linger
:is a signed long.
:
:What happens is that any value between 32768 and 65535 will cause
:so_linger to be negative.  And then getsockopt will return a sign
:extended negative value in the signed long field for linger.
:
:The "trivial" fix is to do the following:
:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brooks Davis | 1 Nov 2002 21:23

Re: [PATCH] switching to if_xname

On Fri, Nov 01, 2002 at 12:07:05PM -0800, Nate Lawson wrote:
> Couple comments.
> 
> * You interchangeably use strlcpy and snprintf(... "%s", ...) and even
> strncpy/strcpy(!).  You probably want to go with just strlcpy.

I forgot to sweep for those again.  I'll do another pass shortly.

> * There may be some cases where a string compare is too slow and it needs
> a unit compare.  I'm not familiar with the code that does this but please
> comment.

The only case I recall where unit compare was really in the fast path
was in ipfw.  In my change, globing is now a bit more expensive since it
uses fnmatch instead of ignoring the unit, but the non-globing case should
be pretty much the same if not slightly faster (it no longer has to
check the unit and the median length of the compared string will only
rise by 1 for every one except tunnel servers).

> * Some places seem to still be using a unit number as a local loop
> counter.  Just curious if this has any side effects.

We've got a number of devices that really like to know thier unit
number.  In those cases, I've generally stuffed it into the softc if it
wasn't there already.

> * Do the ipfw glob changes break ABI?

Yes, but I don't think that's a hugh deal.  The bigger deal is breaking
the network interface API and ABI which in turn breaks a few user land
(Continue reading)

Permalink | Reply | 2 comments |
headers
Michael Sinz | 1 Nov 2002 21:44

Re: Socket so_linger setting

Matthew Dillon wrote:
>     I think your patch is fine as is, Mike!  Good find!  Even though 
>     so_linger cannot be negative, it is often convenient to use a signed
>     integer to store the value to avoid unexpected arithmatic results
>     when mixing with signed operations.  My quick perusal does not show
>     any cases of this for so_linger, so we could make it unsigned, but I
>     don't see any pressing need to do so.   The range check would need
>     to be in there in either case.
> 
>     Can I go ahead and commit it?

I would at least commit it as a range check...

Maybe we should look at changing so_linger to unsigned too.
(As I stated before, it "documents" the value range a bit more
correctly and, with better compilers, the "math errors" would
be warnings if you assumed signed-ness of the value :-)

--

-- 
Michael Sinz -- Director, Systems Engineering -- Worldgate Communications
A master's secrets are only as good as
	the master's ability to explain them to others.

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Permalink | Reply | 0 comments |
headers
Nate Lawson | 1 Nov 2002 22:15

Re: [PATCH] switching to if_xname

On Fri, 1 Nov 2002, Brooks Davis wrote:
>   The bigger deal is breaking
> the network interface API and ABI which in turn breaks a few user land
> programs that use libkvm ("netstat -r" for exmaple).  That's why this is
> a .0 feature.
> 
> Thanks,
> Brooks

Please check the libdnet port and possibly libpcap.

-Nate

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Permalink | Reply | 1 comment |

Gmane