ipfw and access
I was just wondering about the caveat in that access(2) man page that says that access is a potential security hole and should never be used, and the fact that ipfw calls it on line 2435. I seem to recall a discussion about this a few months ago, but I don't really remember the details... and the irony of ipfw calling a documented should never be used function got my attention. Is this really a problem, or is the man page paranoid? Thanks -- Chad David[EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada I applied the patch twice, and it still doesn't work! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DRI, XFree86-4.0.3 and -current.
In local.freebsd-hackers, you wrote: On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: I have a page about the DRI for FreeBSD at=20 http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works on= I had a look at that, but it wasn't too clear what I needed to do. I suspect that I'm expecting to checkout the DRI tree _over_ the top of the XFree86-4 tree but perhaps I don't need to do that. Neither was I. Could you clarify on merging XFree from the ports and the CVS? I tried copying the CVS-stuff over the port, but the build stopped with: cleaning in programs/Xserver/hw/xfree86/input/calcomp... cd: can't cd to calcomp [Might be my fault, after-all. R-To: -multimedia?] -- Neues aus Genua? http://germany.indymedia.org/ Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ipfw and access
Chad David [EMAIL PROTECTED] wrote: I was just wondering about the caveat in that access(2) man page that says that access is a potential security hole and should never be used, and the fact that ipfw calls it on line 2435. I seem to recall a discussion about this a few months ago, but I don't really remember the details... and the irony of ipfw calling a documented should never be used function got my attention. Is this really a problem, or is the man page paranoid? The manual page is probably paranoid, but I don't think we should change it. It's very easy to abuse access(2). It's a potential security hole if you use it to provide access control. E.g., you're a setuid process, and you got a filename as an argument. You want to open it, but only if the user that called you has sufficient privileges to do so. Using access(2) on that filename and opening it if it returns success would be a security hole, because that file might've changed (mv, cp, chmod, whatever) between your call to access(2) and your call to open(2) (classic example of a race condition). The right thing to do would be to drop effective privileges to that of the user, and use open(2) directly. ipfw just wants to know if its last argument is a valid filename (see the first usage form in the manual page). I think that's a pretty legitimate use, although it shouldn't rely on the fact that the file will exist and/or be readable when it gets around to opening it. I.e., it should still handle a failed open gracefully--and it does. One can still trick it into trying to open a file that isn't there, but the results won't be any more spectacular than doing that to any other program (e.g., `cat /nonexistent`). Besides, ipfw isn't privileged. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Interest Contributing to the FreeBsd
Hello Freebsd I have used FreeBsd For several Months including using linux and unix for about 5 Years. I have studied Information Technology and Programming for two years. I have came to the point where i believe i could help in building Freebsd. Could you please send me some information about how i can help. Philip Taylor = This Project Bebox2 will happy to help you with all your Beos and Machines bought from us. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interest Contributing to the FreeBsd
On Fri, Sep 07, 2001 at 11:53:16AM +0100, Philip Taylor wrote: Hello Freebsd I have used FreeBsd For several Months including using linux and unix for about 5 Years. I have studied Information Technology and Programming for two years. I have came to the point where i believe i could help in building Freebsd. Could you please send me some information about how i can help. Find something to contribute, and contribute it :) You might like to start with an open PR in the PR database. Kris PGP signature
Re: DRI, XFree86-4.0.3 and -current.
On Thu, Sep 06, 2001 at 10:45:51PM +0200, Olivier Houchard wrote: Josef Karthauser wrote: Has anyone got patches for DRI under -current? Joe I made an ugly patch so that the drm, gamma and tdfx kernel modules compile under current. I submitted it to DRI, so you may find it at dri.sourceforge.net. By the way no it doesn't work with devfs. I couldn't find the patch at sourceforge. Would you mind mailing it to me too? Thanks, Joe PGP signature
FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
Submissions are due this afternoon. Please submit by e-mail ASAP. We're currently substantially behind prior months -- this is in some ways expected due to various people on summer vacations in the Northern Hemisphere, but it would be nice to get things a bit more fleshed up. In particular, I'd like to see reports on: - Documentation and web work - Release engineering for 4.4-RELEASE - SMPng - KAME - Other on-going network stack changes - Ports to other platforms, including ia64, sparc64 - Hardware driver work - PR management - Security officer work Etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Forwarded message -- Date: Tue, 4 Sep 2001 12:54:24 -0400 (EDT) From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions It's that time again! I'm in the process of preparing the August, 2001 FreeBSD monthly status report, and as such am interested in seeing submissions in much the same style as previous months. Generally, this means about one paragraph of text per project describing events that have occured since the last status report (or two paragraphs for new projects, so as to introduce them). Large projects can be broken down into multiple sub-projects with seperate reports reports. If multiple developers are working on the same project, they should coordinate so as to submit only one report (or split it up into parts as appropriate along logical boundaries). Reports should relate to the FreeBSD Project, but are not limited to on-going software development: documentation, public relations, management, application developer relations, technology transfer, etc, are all relevant. Please submit reports in the following format: Project: (name here -- required field) URL: (URL, if any, here -- omit field if none) Contact: (name and e-mail address of one or more contact points -- required field) One paragraph on the topic of project status since the last report, indented two spaces, and wrapped at column 78. Plain text only, please. Please send submissions to: [EMAIL PROTECTED] The deadline for submissions is September 7, 2001, at 3:00pm EST. The report will be released soon thereafter. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Permissions on /root directory and /etc/mtree/BSD.root.dist
On Thu, Sep 06, 2001 at 08:23:34PM +0100, void wrote: On Thu, Sep 06, 2001 at 10:30:08AM +0400, Andrey Simonenko wrote: 0700 mode restricts other users from reading /root directory. When root wants to upgrade system he/she run make buildworld, make installworld. But installworld calls mtree, which changes /root permissions to default value specified in the /etc/mtree/BSD.root.dist file. So, if administrator will not forgot about needed permissions on /root, then installworld will open /root directory for reading for everybody. I propose not to change permissions on /root directory in the /etc/mtree/BSD.root.dist file and leave them unchanged. Comments? There is a whole class of problems like this. For example, my installation of mutt doesn't work right if /var/mail is not mode 1777, but BSD.var.dist changes it to 755 every time I installworld. I think a more general solution might be in order. Perhaps some sort of local.dist that is processed after BSD.*.dist. As a workaround, I put chmod 1777 /var/mail in my rc.local script. I suggest you do something similar. And then, of course, there is the obvious solution: maintaining some local patches, applied to the source tree after each update. (and reversed before each update..) This is the way I'm doing it, but then, I have a *lot* of local changes, and such an approach might not make sense for a single change like that.. G'luck, Peter -- I am the thought you are now thinking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
On Fri, Sep 07, 2001 at 10:34:29AM -0400, Robert Watson wrote: Project: (name here -- required field) URL: (URL, if any, here -- omit field if none) Contact: (name and e-mail address of one or more contact points -- required field) Project: Documentation Project URL: http://www.FreeBSD.org/docs.html URL: http://www.FreeBSD.org/docproj/index.html Contact: Documentation Project [EMAIL PROTECTED] The Handbook has been the main focus of activity this month. Due to go to the printers on the 15th a vast amount of new content has been submitted and committed. This includes a complete rewrite of the Installing FreeBSD, which massively expands the amount of information available to people new to FreeBSD. It even includes screenshots. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html Comments, and contributions are, of course, welcome. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: Interest Contributing to the FreeBsd
Philip Taylor wrote: Hello Freebsd I have used FreeBsd For several Months including using linux and unix for about 5 Years. I have studied Information Technology and Programming for two years. I have came to the point where i believe i could help in building Freebsd. Could you please send me some information about how i can help. Since this is a volunteer project there is no formal "you should do this" list. 1/ find somthing you'd LIKE to do 2/ see if someone is doing it (search the mailing lists etc.) 3/ contact them (also check CVS logs of associated files to see who may be actually checking the stuff in and contact them too) ask them if you can help them test/develop their project.. 4/ get more involved with time and use all your free time :-) Philip Taylor = This Project Bebox2 will happy to help you with all your Beos and Machines bought from us. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
Robert Watson wrote: Submissions are due this afternoon. Please submit by e-mail ASAP. We're currently substantially behind prior months -- this is in some ways expected due to various people on summer vacations in the Northern Hemisphere, but it would be nice to get things a bit more fleshed up. In particular, I'd like to see reports on: You should add a section for academic research and commercial users of FreeBSD. This might not be keeping with the philosophy, though, since most of us do not trust -current enough to do our PhD Thesis, Master's Project, or business work on it, and tend to create derivative works of -stable, instead... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
On Fri, 7 Sep 2001, Terry Lambert wrote: Robert Watson wrote: Submissions are due this afternoon. Please submit by e-mail ASAP. We're currently substantially behind prior months -- this is in some ways expected due to various people on summer vacations in the Northern Hemisphere, but it would be nice to get things a bit more fleshed up. In particular, I'd like to see reports on: You should add a section for academic research and commercial users of FreeBSD. This might not be keeping with the philosophy, though, since most of us do not trust -current enough to do our PhD Thesis, Master's Project, or business work on it, and tend to create derivative works of -stable, instead... I'd be interested in seeing submissions of this sort, including mass deployment, new research done on the platform, etc. The development status report is limited to new development on -CURRENT, and can include status on merging of features to -stable, the release process, etc. At one point, Jordan was spitting out a FreeBSD news letter once in a while. Dunno if we'll ever see it again, but I thought that was a good idea, and was part of the impetus for exploring a monthly electronic report. Of course, I've never received status information from Jordan :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
On Fri, 7 Sep 2001, Terry Lambert wrote: This might not be keeping with the philosophy, though, since most of us do not trust -current enough to do our PhD Thesis, Master's Project, or business work on it, and tend to create derivative works of -stable, instead... It should be noted, of course, that for successful technology transfer, it really good idea to target -CURRENT regardless of the ups and downs of -CURRENT: otherwise you find your work stuck in a backwater and lost (witness the lottery scheduling support, and many other things..). Part of the problem here is that often research funding waves its hands at technology transfer, but doesn't cover the day-to-day activity of merging and tracking a moving target, which is required to work on both Linux and FreeBSD. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Compiling source code
Hi, Could anybody give me some info about 'how to compile the FreeBSD source code' and run. Any pointers to useful links will also suffice. thanks a lot ashley To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Compiling source code
On Fri, Sep 07, 2001 at 03:23:31PM -0400, Ashley Thomas wrote: Hi, Could anybody give me some info about 'how to compile the FreeBSD source code' and run. Any pointers to useful links will also suffice. first, this isn't the proper mailing list for this type of question. [EMAIL PROTECTED] would be much more appropriate. second, check out the freebsd handbook, at http://freebsd.org/handbook for the answer to your question and a whole lot more... -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FINAL REMINDER: FreeBSD Monthly Development Status Report --Request For Submissions
status on merging of features to -stable, the release process, etc. At one point, Jordan was spitting out a FreeBSD news letter once in a while. Dunno if we'll ever see it again, but I thought that was a good idea, and was part of the impetus for exploring a monthly electronic report. Of course, I've never received status information from Jordan :-). I know, I know, life's been rather extremely busy. I'd love to revive the newsletter, believe me, though I also think that DaemonNews and other publications like it have admirably filled the niche. We just need to provide them with material from time to time. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Error of BUF_STRATEGY()
I use BUF_STRATEGY() in a kernel module to read a sector on a device like /dev/ad0s3g. The biowait() routine after BUF_STRATEGY() gives me errors like EALREADY and EPERM from time to time. I find out that these errors occur after I already wrote the same device by another program. If I wait a bit longer or try again, the BUF_STRATEGY() works fine and no error happens. I am wondering who is giving these errors. Is it the hardware? If so, the kernel should somehow translate the hardware error to EALREADY and EPERM. What is the exact meaning of these two errors? Thanks, -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Compiling source code
Assuming it is in /usr/src (where it gets put by default) cd /usr/src make or cd /usr/src/ make buildworld make installworld or cd /usr/src/usr.bin/yourfavouriteutility make depend make maek install If you do not hav ethe source, see the many places in th online handbook that tell you how to keep your sources up-to date with the branch you select. (look for references to cvsup) On Fri, 7 Sep 2001, Ashley Thomas wrote: Hi, Could anybody give me some info about 'how to compile the FreeBSD source code' and run. Any pointers to useful links will also suffice. thanks a lot ashley 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: FINAL REMINDER: FreeBSD Monthly Development Status Report -- Request For Submissions
On Fri, Sep 07, 2001 at 12:53:48PM -0700, Jordan Hubbard wrote: status on merging of features to -stable, the release process, etc. At one point, Jordan was spitting out a FreeBSD news letter once in a while. Dunno if we'll ever see it again, but I thought that was a good idea, and was part of the impetus for exploring a monthly electronic report. Of course, I've never received status information from Jordan :-). Wasn't this something like: hug a palm @ Hawaii ? ;-)) I know, I know, life's been rather extremely busy. I'd love to revive the newsletter, believe me, though I also think that DaemonNews and It all amounts to somebody/a team with Pulitzer prize aspirations. Meaning: people who can and are willing to write stuff on a regular basis. -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DRI, XFree86-4.0.3 and -current.
Oops, I'll have to clarify that. No, you don't need to keep an XFree86-4 tree around at all. Just get the X-DRI tree from sourceforge, and install it over your XFree86-4 install. I have both XFree and X-DRI CVS trees (downloading the 90MB or whatever per X release just isn't going to happen through my 28.8): /usr/local/src/xfree is X CVS (cvs.xfree86.org, updated/installed rarely, as most changes end up in X-DRI soon enough anyway) /usr/lcoal/src/xdri is X-DRI CVS (cvs.sourceforge.net bsd-2-0-0-branch, compiled/installed frequently). I'm working on making it so we can have an official port of the DRI -- you'll install the XFree86-4.x port (which would install X, the dri modules, libGL, libGLU, etc.), then go to graphics/drm-kmod and install that, and you'll be done installing. It's not quite finished yet, and I am waiting to get to a faster line (2 weeks) before downloading the X release to test against. On Friday 07 September 2001 03:12, Volker Stolz wrote: In local.freebsd-hackers, you wrote: On Thu, Sep 06, 2001 at 12:16:19PM -0700, Eric Anholt wrote: I have a page about the DRI for FreeBSD at=20 http://gladstone.uoregon.edu/~eanholt/dri/. The current DRI CVS works I had a look at that, but it wasn't too clear what I needed to do. I suspect that I'm expecting to checkout the DRI tree _over_ the top of the XFree86-4 tree but perhaps I don't need to do that. Neither was I. Could you clarify on merging XFree from the ports and the CVS? I tried copying the CVS-stuff over the port, but the build stopped with: cleaning in programs/Xserver/hw/xfree86/input/calcomp... cd: can't cd to calcomp -- Eric Anholt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
tiny patch to pkg_add
Ok, So this represents my most significant effort to date to fix something in C. It took me far too long to identify where the one line fix needed to go and even longer to figure out how to do it in C. Here's the problem that this fixes: When using pkg_add -r to add multiple packages (i.e. pkg_add -r foo bar baz) pkg_add was dying after adding the first package because it was botching the URL for every package after the initial one. It looked a bit like this: # pkg_add -r xonix nethack an Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/xonix.tgz... Done. Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/nethack.tgz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch `ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/nethack.tgz' by URL Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/an.tgz: File unavailable (e.g., file not found, no access) pkg_add: unable to fetch `ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4.4-release/Latest/an.tgz' by URL Anyway, it's an easy fix but my real question is, is this the correct way to destroy the value of a variable in C? Here's my patch: --- src/usr.sbin/pkg_install/add/main.c Fri Sep 7 15:02:17 2001 +++ src/usr.sbin/pkg_install/add/main.c.origFri Sep 7 13:11:40 2001 @@ -189,7 +189,6 @@ } } } - strlcpy(packagesite, , sizeof(packagesite)); } } /* If no packages, yelp */ -Bill -- -=| Bill Swingle - unfurl@(dub.net|freebsd.org) -=| Every message PGP signed -=| Fingerprint: C1E3 49D1 EFC9 3EE0 EA6E 6414 5200 1C95 8E09 0223 -=| Different all twisty a of in maze are you, passages little PGP signature
Re: tiny patch to pkg_add
On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: - strlcpy(packagesite, , sizeof(packagesite)); Chris Costello recommended that I do this like this instead: packagesite[0] = '\0' Which seems to make sense since it lacks the overhead of strlcpy. Is there a right way to do this? -Bill -- -=| Bill Swingle - unfurl@(dub.net|freebsd.org) -=| Every message PGP signed -=| Fingerprint: C1E3 49D1 EFC9 3EE0 EA6E 6414 5200 1C95 8E09 0223 -=| Different all twisty a of in maze are you, passages little PGP signature
Re: tiny patch to pkg_add
If memory serves me right, Bill Swingle wrote: Chris Costello recommended that I do this like this instead: packagesite[0] =3D '\0' Which seems to make sense since it lacks the overhead of strlcpy. Is there a right way to do this? Although I haven't seen the context for this line (other than what was in the context diff), I think most C programmers (including myself) would go with Chris's suggestion. Hope this helps, Bruce. PGP signature
Re: tiny patch to pkg_add
On Friday, September 07, 2001, Leo Bicknell wrote: I think Chris's version is right, although if you're writing a security app, or just want to be overly paranoid in general you could use: bzero((void *)packagesite, sizeof(packagesite)); That's unnecessary unless you know you're going to be reading data from that string starting somewhere other than packagesite[0];. And the `void *' cast is unnecessary, as an array is converted to a pointer when passed to a function, and any data pointer is also implicitly converted to a `void *' pointer where necessary. -- +---++ | Chris Costello| Save energy: | | [EMAIL PROTECTED] | Drive a smaller shell. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tiny patch to pkg_add
On Fri, Sep 07, 2001 at 05:46:26PM -0500, Chris Costello wrote: bzero((void *)packagesite, sizeof(packagesite)); That's unnecessary unless you know you're going to be reading data from that string starting somewhere other than packagesite[0];. And the `void *' cast is unnecessary, as an array is converted to a pointer when passed to a function, and any data pointer is also implicitly converted to a `void *' pointer where necessary. That's not the only reason to do it. Many people in the past have gotten passwords out of various applications by making them core dump, sifting through /dev/kmem, and other things. While it's not clear that his application might have these issues, I come from the better safe than sorry school. If you want to make a string empty, make it empty, don't just clobber the first character. The void * is necessary to make lint happy. It is not necessary for the program to work right. -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tiny patch to pkg_add
On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: So this represents my most significant effort to date to fix something in C. It took me far too long to identify where the one line fix needed to go and even longer to figure out how to do it in C. Here's the problem that this fixes: This was introduced in rev 1.38: and replace a big if..then..else construct to determine the package download directory with a lookup table. I am very tempted to back this part out. This better implimentation has now had two logic bugs. I wrote that big if..then..else contstruct so that the code would be *so* simple my simple my 1st quarter freshman students (back when I TA'ed) could understand it. I did it that way because I got tired of committers constantly breaking -r. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DRI, XFree86-4.0.3 and -current.
On Fri, Sep 07, 2001 at 01:54:06PM -0700, Eric Anholt wrote: I'm working on making it so we can have an official port of the DRI -- you'll install the XFree86-4.x port (which would install X, the dri modules, libGL, libGLU, etc.), then go to graphics/drm-kmod and install that, and you'll be done installing. It's not quite finished yet, and I am waiting to get to a faster line (2 weeks) before downloading the X release to test against. Cool. I'll give you a hand with it with you want. In particular I have a need for it under -current. Joe PGP signature
Re: tiny patch to pkg_add
On Fri, Sep 07, 2001 at 03:04:16PM -0700, Bill Swingle wrote: Anyway, it's an easy fix but my real question is, is this the correct way to destroy the value of a variable in C? Here's my patch: --- src/usr.sbin/pkg_install/add/main.c Fri Sep 7 15:02:17 2001 +++ src/usr.sbin/pkg_install/add/main.c.origFri Sep 7 13:11:40 2001 @@ -189,7 +189,6 @@ } } } - strlcpy(packagesite, , sizeof(packagesite)); } } /* If no packages, yelp */ Surely: *packagesite = '\0'; would do just as well? Joe PGP signature
Re: tiny patch to pkg_add
On Fri, Sep 07, 2001 at 04:22:43PM -0700, David O'Brien wrote: This was introduced in rev 1.38: and replace a big if..then..else construct to determine the package download directory with a lookup table. I am very tempted to back this part out. This better implimentation has now had two logic bugs. I wrote that big if..then..else contstruct so that the code would be *so* simple my simple my 1st quarter freshman students (back when I TA'ed) could understand it. I did it that way because I got tired of committers constantly breaking -r. the funniest thing about this is that multiple packages in -r was already fixed once by chris piazza in rev 1.29 (almost 2 years ago). -- - bill fumerola / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
In message [EMAIL PROTECTED], Chris Costello writes: On Tuesday, September 04, 2001, Maxim Sobolev wrote: Content-Description: ASCII C program text Index: coda/coda.h === RCS file: /home/ncvs/src/sys/coda/coda.h,v retrieving revision 1.9 diff -d -u -r1.9 coda.h --- coda/coda.h 1999/12/29 04:54:30 1.9 +++ coda/coda.h 2001/09/04 18:46:42 @@ -41,7 +41,7 @@ #ifndef _CODA_HEADER_ #define _CODA_HEADER_ - +#define VT_CODA VT_CODA ... I don't think that the point of this is to use a string like that, but rather a descriptive string, i.e. No actually not, I want something short and predictable like VT_CODA. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Saturday, September 08, 2001, Poul-Henning Kamp wrote: No actually not, I want something short and predictable like VT_CODA. How about my second suggestion: making v_tag point to mp-mnt_stat.f_fstypename, or a copy thereof? -- +---+--+ | Chris Costello| Why do we want intelligent terminals | | [EMAIL PROTECTED] | when there are so many stupid users? | +---+--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Tuesday, September 04, 2001, Maxim Sobolev wrote: Content-Description: ASCII C program text Index: coda/coda.h === RCS file: /home/ncvs/src/sys/coda/coda.h,v retrieving revision 1.9 diff -d -u -r1.9 coda.h --- coda/coda.h 1999/12/29 04:54:30 1.9 +++ coda/coda.h 2001/09/04 18:46:42 @@ -41,7 +41,7 @@ #ifndef _CODA_HEADER_ #define _CODA_HEADER_ - +#define VT_CODA VT_CODA ... I don't think that the point of this is to use a string like that, but rather a descriptive string, i.e. #define VT_FDESCFS file-descriptor file system #define VT_NFS network file system But is it necessary that you really use those defines? The idea is not to use them globally. Perhaps getnewvnode() should get the string from `mp-mnt_stat.f_mntfromname', instead... -- +---+---+ | Chris Costello| As far as we know, our computer has never | | [EMAIL PROTECTED] | had an undetected error.- Weisert | +---+---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel Hacker task: improve vnode-v_tag
On Friday, September 07, 2001, Chris Costello wrote: But is it necessary that you really use those defines? The idea is not to use them globally. Perhaps getnewvnode() should get the string from `mp-mnt_stat.f_mntfromname', instead... ^ Er, fstypename... -- +---++ | Chris Costello| Unprecedented performance: | | [EMAIL PROTECTED] | Nothing ever ran this slow before. | +---++ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SO_REUSEPORT on unicast UDP sockets
Vladimir A. Jakovenko wrote: Terry, I clearly understand all your explanations. Yes, we are living in real life and there is a lot of programms with bad design. But all what I want is possibility to receive UDP packets with corresponding dst IP and port by more than one process on a single host. This already works for Broadcast and Multicast addresses. If I want to get same functionality for unicast (without any kernel changes) I have to use UDP-proxy, which redirects given datagrams to loopback broadcast address, where they can be received by more that one process. Yes. According to comment in udp_input() SO_REUSEPORT hack on unicast sockets could be used in single process, right? Yes. How possibility to get duplicate traffic on two UDP sockets, which was created in _different_ processes with the same local address and port values, would break existing applications? Consider a UDP based reliable delivery protocol that cares about key frames, but not about all frames. A good example of this would be any RTSP/RTP type protocol implemented on UDP, which was used to implement streaming video of a live broadcast, using limited buffer space. In this situation, the video is delivered by sending a key frame, and then subsequent data is sent as deltas on that key frame. Effectively, this MUXes two protocols: a reliable datagram protocol containing the key frames, and an unreliable protocol containing the deltas, over a single channel. This method of key frame use is the same method used to encode DVD data and a number of real time streaming protocols, including a number of streaming video protocols running over UDP (the original technique was pioneered by a company named CinemaWare, a Utah-based developer of Amiga software, which used a technique called cell animation to reduce image data size requirements). Your hypothetical two-process-no-proxy program would not correctly acknowledge key frames consisting of more than one UDP packet, unless you delivered the unicast to both. If you delivered the unicast to both, you would need to build an acknowledgement proxy, which would only acknowledge when the entire key frame had been received by *both* processes. Taking an even simpler case, you could build a UDP packet payload classifier, which would classify UDP packets based on payload (size, etc.), and report statistics at the end of a run. Your change would result in erroneous reporting. On a philosophical note, it's questionable about whether a unicast is directed to an IP/port pair, or whether it is directed to a particular application, and the IP/port pair, or even the UDP protocol, are just a necessary vehicle for the delivery of the information. On a practical note, if you could fix the multiple delivery problem, so that only one listener got the packet, this would address many, but not all, of the objections above(*). On a purely technical note, I think you want to use something other than unicast for your implementation: multicast group seems to be the most correct fit (I am in the camp that a unicast is directed at an application, not merely a machine). (*) You would still have the problem of a meta relationship between multiple packets, and you would still have the problem of correctly selecting who would get the packet; right now, the behaviour is first listener, not LRU more MRU... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: SO_REUSEPORT on unicast UDP sockets
On Mon, Sep 03, 2001 at 11:48:02PM -0700, Terry Lambert wrote: Vladimir A. Jakovenko wrote: Hello! According to UNPv1 SO_REUSEPORT on UDP sockets can be used to bind more than one socket to the same port (even with same source ip address). But quick look on /sys/netinet/udp_usrreq.c function udp_input() shows that this will work as expected (data stream duplicate) only on multicast/broadcast local addresses. Please pay attention to the following code fragment comments: [ ... ] Is there still any real need in such backward compatibility? Can such functionality be added (fixed) with possibility to switch it off using sysctl or kernel-build option? I find such possibility realy useful at least for NetFlow data processing and believe that it would be useful for many UDP-based protocols. Bound UDP sockets have always been problematic; there's a lot of code out there that depnds on the historical behaviour for unicast, unfortunately, including a number of commercial applications that run on FreeBSD (e.g. Real Server). If you look at that code for any length of time, you will get to see it as an armpit: it's not a good place to stick your nose, and it tends to smell to high heaven. At my current job, I'm up to my elbows in it... Terry, I clearly understand all your explanations. Yes, we are living in real life and there is a lot of programms with bad design. But all what I want is possibility to receive UDP packets with corresponding dst IP and port by more than one process on a single host. This already works for Broadcast and Multicast addresses. If I want to get same functionality for unicast (without any kernel changes) I have to use UDP-proxy, which redirects given datagrams to loopback broadcast address, where they can be received by more that one process. According to comment in udp_input() SO_REUSEPORT hack on unicast sockets could be used in single process, right? How possibility to get duplicate traffic on two UDP sockets, which was created in _different_ processes with the same local address and port values, would break existing applications? -- Regards, Vladimir. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
