Re: [PATCH] switching to if_xname
On Fri, Nov 01, 2002 at 01:15:45PM -0800, Nate Lawson wrote:
> 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.
>
> Please check the libdnet port and possibly libpcap.
libdnet was already broken by a different change (visability
conditionals on IFNAMSIZ), but this change would break it more. It's a
pretty simple fix (replace fr_to_ipfw_device with strlcpy). It should
be noted that libdnet's ipfw support is already broken because it
doesn't handle wildcards. libpcap doesn't require any patches.
I've already told kris I'd provide fixes for the ports this change breaks.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
msg37784/pgp0.pgp
Description: PGP signature
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Subscribe
Please subscribe me to the mailing list! Thanks! Jeffrey A. Ward EDS Information Analyst To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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
programs that use libkvm ("netstat -r" for exmaple). That's why this is
a .0 feature.
Thanks,
Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
msg37780/pgp0.pgp
Description: PGP signature
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 <[EMAIL PROTECTED]> :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 :@@ -1139,7 +1139,8 @@ : 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 :-- : :What this does is limit the value to no more than 32767 (SHRT_MAX) :However, I believe the more correct answer is that so_linger should :not be a signed value to begin with. : :The reasoning is that what does a negative so_linger mean? To :close the socket before the user does ;^)? : :It is somewhat obvious that so_linger does not need to be a long. : :It is not possible to change the API to make the input a short. : :Limiting the value to 32767 is reasonable (and that is a *vary* :long linger time) : :However, given that negative linger values really don't exist :(logically) it would be reasonable to not that field be signed. :That would naturally limit the values to being within a valid :range and prevent some strange results, specifically when :looking at the tsleep() call where the so_linger field is :just blindly multiplied by the hz of the system. (around line :312 of uipc_socket.c) A segative so_linger will get sign extended :into a negative int (32-bit) (times hz) and then passed to tsleep :which just checks for zero, passed on to timeout which then :passes it to callout_reset. It turns out that callout_reset will :take negative values and make them a single tick... (whew! lucky :thing that was there :-) : :The question I have is: should put together a patch that changes :so_linger (and xso_linger) to unsigned? (And make sure there are :no bad side effects) or is the trivial fix above what is wanted? : :[ My personal feeling is that since so_linger has no valid negative : value that the field should be unsigned. Not that it matters : about improving the range as 32767 is over 9 hours. It is more : a matter of "correctness" in the code/representation since the : code assumes the value is not negative already. ] : :-- :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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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? Overall, I like it. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[brooks@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 <[EMAIL PROTECTED]> - From: Brooks Davis <[EMAIL PROTECTED]> Date: Wed, 23 Oct 2002 20:50:38 -0700 To: [EMAIL PROTECTED] 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 a giant no-op from the user perspective. Real features will come later, but the API/ABI change needs to happen soon or it's going to be a 6.0 feature. I'm running this patch on my laptop with a GENERIC kernel without any problems so far. For all it's size, most of the changes are log() or printf() calls plus a fairly consistant change to each network driver's attach function so this should be generally low impact. The patch is available at the URL below. I tried to send a copy to the list, but it looks like it got silently tossed as too large. If you want a copy e-mailed to you, feel free to ask me for one. http://people.freebsd.org/~brooks/patches/if_xname.diff Please review. Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 - End forwarded message - msg3/pgp0.pgp Description: PGP signature
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 [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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): [EMAIL PROTECTED] 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! Prior status reports may be viewed at: http://www.FreeBSD.org/news/status/ Of particular interest, rolling up to the 5.0 release, are reports relating to the major architectural projects with results in 5.0, including SMPng, KSE, GEOM, TrustedBSD, UFS2, newcard, firewire, ACPI, IPsec acceleration, and new hardware ports including sparc64 and ia64. Including reports on the status approaching the release, and identifying areas where "must be done" requirements are present for the release will help consumers of FreeBSD get a sense of what they can expect in 5.0, as well as what other developers need to work on in order to make it happen. Robert Watson, Scott Long FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Seek and Find KGKQSUUQSI
READY TO KNOW? REALLY? CONFIDENTIAL! The SOFTWARE They Want BANNED In all 50 STATES. Why??? Because these secrets were never intended to reach your eyes... Get the facts on anyone Locate Missing Persons, find Lost Relatives, obtain Addresses and Phone Numbers of old school friends, even Skip Trace Dead Beat Spouses. Very Valuable when doing Genealogy projects! In Fact this software is a "Must Have" You'll save 100's of hours... This is not a Private Investigator, but a sophisticated SOFTWARE program DESIGNED to automatically CRACK YOUR CASE with links to thousands of Public Record databases. Find out SECRETS about your relatives,friends, enemies, and everyone else! Even your spouse! With the New,INTERNET SPY AND YOU! It's absolutely astounding! Here's what you can learn. License plate number Get anyone's name and address with just a license plate number Find that girl you met in traffic! Driving record!Get anyone's driving record! Social security number! Trace anyone by social security number! Address!Get anyone's address with just a name! Unlisted phone numbers!!! Get anyone's phone number with just a name even unlisted numbers! Locate! Long lost friends, relatives, a past lover who broke your heart! E-mailSend anonymous e-mail completely untraceable! Dirty secrets! Discover dirty secrets your in-laws don't want you to know! Investigate anyone! Use the sources that private investigators use (all on the Internet)secretly! Ex-spouse! Learn how to get information on an ex-spouse that will help you win in court! (Dig up old skeletons) Criminal search Background check! Find out about your daughter's boyfriend! Find out!If you are being investigated! Neighbors!Learn all about your mysterious neighbors! Find out what they have to hide! People you work with! Be astonished by what you'll learn about people you work with! Education verification! Did he really graduate college? Find out! Internet Spy and You! Software will help you discover ANYTHING about anyone, with clickable hyperlinks and no typing in Internet addresses! Just insert the floppy disk and Go! You will be shocked and amazed by the secrets that can be discovered about absolutely everyone! Find out the secrets they don't want you to know! About others, about yourself! It's INCREDIBLE what you can find out using Internet Spy and You and the Internet! You'll be riveted to your computer screen! Get the software they're trying to ban! Before it's too late! ACT NOW!! ONLY $18.95!! REGULAR PRICE $49.95 ONLY for those who A*C*T within the next 7 days! ORDER NOW AND RECEIVE THE SPY SOFTWARE FOR $18.95! THAT'S RIGHT ONLY $18.95 a $30 savings... ;-)) This offer Can be withdrawn at any time, act within 7 days for the special price. Your price is...$18.95 add ONLY $1.05 Shipping/Handling ...__ Your Total is only..$20.00 We will SEND YOU the Internet Spy and SOFTWARE so you can begin discovering all the secrets you ever wanted to know! You can Know EVERYTHING about ANYONE with our Internet Spy and Software. Works with all browsers and all versions of AOL! US FUNDS ONLY, MONEY ORDER, CHECKS Foreign money orders must be payable from a US BANK AND IN US FUNDS NO EXCEPTIONS! DON'T WAIT TO GET STARTED... It's as easy as 1, 2, 3. STEP 1 - Print the form below. Or put the requested info neatly printed on any paper. We need this to fill your order!!! STEP 2 - Type or print your order information into the order form section. STEP 3 - Mail order form and payment to the address below. ONLY...$20.00 including the SHIPPING/HANDLING! Netsense PO BOX 2033 Columbus, NE 68602-2033 Name: ___ Address: _ City/State/Zip: __ E-Mail ___ DISCLAIMER: The seller of this powerful software resource will not be held responsible for how the purchaser chooses to use it's resources. To be removed from our list [EMAIL PROTECTED] and put Remove in the subject. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
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 @@ -1139,7 +1139,8 @@ 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 -- What this does is limit the value to no more than 32767 (SHRT_MAX) However, I believe the more correct answer is that so_linger should not be a signed value to begin with. The reasoning is that what does a negative so_linger mean? To close the socket before the user does ;^)? It is somewhat obvious that so_linger does not need to be a long. It is not possible to change the API to make the input a short. Limiting the value to 32767 is reasonable (and that is a *vary* long linger time) However, given that negative linger values really don't exist (logically) it would be reasonable to not that field be signed. That would naturally limit the values to being within a valid range and prevent some strange results, specifically when looking at the tsleep() call where the so_linger field is just blindly multiplied by the hz of the system. (around line 312 of uipc_socket.c) A segative so_linger will get sign extended into a negative int (32-bit) (times hz) and then passed to tsleep which just checks for zero, passed on to timeout which then passes it to callout_reset. It turns out that callout_reset will take negative values and make them a single tick... (whew! lucky thing that was there :-) The question I have is: should put together a patch that changes so_linger (and xso_linger) to unsigned? (And make sure there are no bad side effects) or is the trivial fix above what is wanted? [ My personal feeling is that since so_linger has no valid negative value that the field should be unsigned. Not that it matters about improving the range as 32767 is over 9 hours. It is more a matter of "correctness" in the code/representation since the code assumes the value is not negative already. ] -- 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
