Re:cvsweb service down?
it seems NOT only cvsweb down, but also all /cgi/ related services. e.g. The PR system :( Kang Liu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re:cvsweb service down?
In your mail: >From: "Xin LI" <[EMAIL PROTECTED]> >Reply-To: >To: <[EMAIL PROTECTED]> >Subject: cvsweb service down? > > So what happend? Planned shutdown? In addition it seems that the maillist is > reproducing several outdated posts, are they related? The proxy server received an invalid response from an upstream server... hmm.. I think it might be a cgi-script related problem. Regards. Kang Liu. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cvsweb service down?
Hi gang, I got these when visiting cvsweb.freebsd.org: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET /cgi/cvsweb.cgi/. Reason: Could not connect to remote machine: Connection refused So what happend? Planned shutdown? In addition it seems that the maillist is reproducing several outdated posts, are they related? Thanks. Xin LI ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: POSIX Threads
On Tue, 27 Jan 2004 01:19:43 +0100, ISAAC GELADO FERNANDEZ <[EMAIL PROTECTED]> wrote: - Mensaje original - De: Jeremy Messenger <[EMAIL PROTECTED]> Fecha: Miércoles, Octubre 29, 2003 6:33 pm Asunto: Re: POSIX Threads On Wed, 29 Oct 2003 13:10:53 +0100, Isaac Gelado <[EMAIL PROTECTED]> wrote: > But, when the server is running under FreeBSD 5.0 I think that you do really need to update your machine to 5.1- CURRENT for the threads. It's a lot improvement from 5.0, but I have no idea if it will solve your problem in that area. At least, you can help with the developers to keep the things up to date. I recently upgraded my system to 5.2 and now all works perfectly. Check the date of this email; it was from Oct 29th, 2003 :-) Something is going crazy in the mailing list, I am getting over 70 to 80 old stuff coming in my inbox. Ugh.. Cheers, Mezz Cheers, Mezz -- bsdforums.org 's moderator, mezz. -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: POSIX Threads
- Mensaje original - De: Jeremy Messenger <[EMAIL PROTECTED]> Fecha: Miércoles, Octubre 29, 2003 6:33 pm Asunto: Re: POSIX Threads > On Wed, 29 Oct 2003 13:10:53 +0100, Isaac Gelado <[EMAIL PROTECTED]> wrote: > > > > But, when the server is running under FreeBSD 5.0 > > > I think that you do really need to update your machine to 5.1- > CURRENT for > the threads. It's a lot improvement from 5.0, but I have no idea if > it > will solve your problem in that area. At least, you can help with > the > developers to keep the things up to date. I recently upgraded my system to 5.2 and now all works perfectly. > > Cheers, > Mezz > > > -- > bsdforums.org 's moderator, mezz. > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers- > [EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ip_input - chksum - why is it done so early in ip_input?
On Sat, Jan 17, 2004 at 12:50:04AM +0100, Sten Daniel S?rsdal wrote: > > Apologies for the cross-post, i wasnt sure if this was hackers or net material. > > I've often wondered why ip checksumming is done on every incoming > packet and not only on the packets that need to be delivered locally. > It looks like a very expensive way of doing it, especially on high > PPS. Basically all hosts do checksumming so why not just pass the bad > packet on, making the forward process alot cheaper (cpu wise)? > > I ran some tests (unable to disclose results) by removing it completely > and it seems to make a noticable impact on the performance. > Especially on for example gaming services where there is a high PPS versus > actual data. > > Besides that i'd like to add that FreeBSD has the fastest forwarding engine > i've seen on any free OS. It's in my opinion a very suitable OS for > routing/forwarding. > Have you tried ``sysctl net.inet.ip.fastforwarding=1''? It's documented in the inet(4) manpage. Cheers, -- Ruslan Ermilov FreeBSD committer [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Power Patches
Hi, > On Fri, 02 Jan 2004 11:23:11 -0700 (MST) > "M. Warner Losh" <[EMAIL PROTECTED]> said: imp> This looks like it isn't mapping the cis in correctly. Can you turn imp> on hw.cardbus.debug_cis=1? I assumed you meant hw.cardbus.cis_debug. ;) cardbus0: Resource not specified in CIS: id=10, size=800 cardbus0: Resource not specified in CIS: id=14, size=2 cardbus0: Resource not specified in CIS: id=18, size=80 cardbus0: Non-prefetchable memory at 8800-9001 cardbus0: IO port at 1000-107f cardbus0: at device 0.0 (no driver attached) cbb0: CardBus card activation failed Full output of dmesg is also attached in this mail. imp> : imp> 1) You are using hw.pci.unsupported_io=1. Turn it off and use imp> : imp>these patches. Let me know if it doesn't. Typically it imp> : imp>appears that this helps people hitting the double imp> : imp>allocation problem. imp> : imp> : I used to set hw.pci.unsupported_io=1. Changing this value doesn't imp> : help. imp> Dang. I'd like to get to the bottom of this. Aha, I made sure to set hw.pci.allow_unsupported_io_range. But, I did just copy&paste it from your message. :-) Sincerely, dmesg.out Description: Binary data -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan [EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org http://www.imasy.org/~ume/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Update: PR bin/60636
On Mon, 29 Dec 2003, 01:27-0600, William Grim wrote: > Hey there. > > I emailed that PR into the FreeBSD team the other day. I didn't remove > a line that said , because the above lines said comments and > anything between < and > would be removed. It put [EMAIL PROTECTED] > as my email, and now I'm getting all sorts of spam to that mail box (all > dealing with that stupid ass "Last chance to update MS" and shit). > > Sorry for the cussing, but this is frustrating since that's used > strictly for system administration; can you change the email address to > [EMAIL PROTECTED] > > Thanks. > > PS : Just tell me who to forward this email too to get this resolved if > this is not the appropriate place. Done. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: support for __thread
On Sun, 21 Dec 2003, Eric Anholt wrote: > On Sun, 2003-12-21 at 12:08, Daniel Eischen wrote: > > On Sun, 21 Dec 2003, Alfred Perlstein wrote: > > > > > * Alfred Perlstein <[EMAIL PROTECTED]> [031221 02:47] wrote: > > > > How do I get __thread to work for me? > > > > > > > > http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html > > > > > > > > it seems the assembler chokes on it? > > > > We don't have support for it yet. Why do you want it? > > From what I understand, having thread-local variables would be a big > bonus for OpenGL. Yes, it was folks from Nvidia that urged us to support this. This probably better belongs on -current; some developers don't read -hackers. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during "normal" operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? Actually, this is quite similar to what people at Vasco do (http://www.vasco.com). They make devices that (from what I can tell) hash a PIN and a timestamp (along with some other arbitrary values generated by a server, which are optional) and give you a return hash. From what I've seen, the hash is rather elementary and I feel somewhat silly using it to log into my bank. I sent an email to them a while ago; it seems that the security may lie somewhat on the knowledge of the hashing function. But there are definitely devices that do these sorts of things (although the ones from Vasco don't work with GSM, so sending the SMS back would have to go through the phone). Although, I must say, that sending the SMS via the phone is quite insecure as well. If you've the ability to send SMSes, you can most likely fake the address your SMS is coming from, just like you can fake an email. Although, AFAIK, it's a bit more difficult to track the origin of an SMS message. However, most new phones have J2ME capability. I hate Java, but since it's the HLL that we're allowed to use, we could make use of it. After Helix has had some time to be cryptanalyzed, it might be a good candidate for just this kind of application -- a lightweight, fast, easily implementable encryption and authentication algorithm (though it looks promising to me). Until then, some other kind of encryption/authentication could take place. In any case, many phones allow sockets to be created and sent (and if they don't, they most certainly support HTTPS channels). I think an app utilizing this would be a bit more secure in this scenario than one via SMS (or via the Vasco method, I don't have a ton of faith in their closed-source solution). This would be a good, mobile way to provide a one-time key, though. You might even be able to implement it to request keys from multiple administrators assuming the first administrator failed. Who knows. Haven't been following this discussing very closely, so feel free to poke me with a stick if I'm babbling about some obscure tangent. While you're in there, paint that bikeshed blue. Only if there's not someone painting it already :) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a FreeBSD DVD
On Mon, Nov 24, 2003 at 10:06:46AM -0500, Leo Bicknell wrote: >Well, what I'm really interested in is the install + live file >system on a single DVD, which is how the DVD's at FreeBSD mall are >advertised (I've never bought one, myself). So, I can build an >install CD, I (think I) can build a live file system CD. How do >you get them both on a DVD, and give the user a boot choice? Based on the way it boots and promts, the live file system CD appears to be identical to the install CD as far as the kernel and sysinstall are concerned. I suspect merging the two is simply a matter of loading both the live filesystem hierarchy and the installation files into a single image. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel enviroment in sysctl MIB
Hello, I am investigating the possiblilies for looking at the kernel boot parameters from within a userland utility. (Possibly a new FreeBSD install facility) The idea is that by looking at sysctl kern.environment.* you should be able to see the BTX variables. An install program could use this to see an INSTALL_SERVER=install.company.com variable (etc...) to use as install server. The BTX loader could provide these variables at install boot time, thus enableing fully automated installs. When I look at kern/kern_environment.c I see that the BTX loader provides its "environment variables" to the kernel. They show up in the kernel under char *kern_envp. When looking at this variable in the gdb debugger I see the first environment variable of the BTX loader: "LINES=24". I do not master the gdb enhough to see the next enviroment variable (I tried (kgdb) print [EMAIL PROTECTED], but this does not show the variable after the first \0 character) but I am sure its there. My question is this: When looking at kern/kern_environmet.c I see routines that install a SYSCTL_NODE kern.environment. The sysctl_kernenv routine handles this node. What I do not understand is how the environment is returned from this routine. I suppose that at sys_init time you should traverse the environment once and install SYSCTL_ADD_STRING leaves for all environment variables. Then later sysctl calls could ask for the value of these strings. Am I right? Or does it work differently? When you issue the command "sysctl kern.environment" as root you see no output, but also no error! When you try "sysctl kern.environment.LINES" you do get an error I can understand why! No leaves were installed. What is wrong, and how can we fix it? Vriendelijke groet / Kind Regards, Reinier Kleipool, Network Engineer, Protocomix Rotterdamserijweg 122 3042 AS Rotterdam Tel 0654 227144 Fax 010 245 0902 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sound Blaster Audigy LS problem
On Nov 04, Anthony Schneider wrote: > [...] > timeout = (hz * sndbuf_getblksz(bs)) / (sndbuf_getspd(bs) * sndbuf_getbps(bs)); > if (timeout < 1) > timeout = 1; > timeout = 1; > > seems like overkill... > I noticed this too. It was introduced in rev 1.65 to "reduce latency/pauses in output." It isn't clear to me why it's there. --Mat -- It's impossible to awaken a man who is pretending to be asleep. - Navajo saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rfork problem
On 04-Nov-2003 David Schultz wrote:
> On Tue, Nov 04, 2003, Igor Serikov wrote:
>>
>> David,
>>
>> Is it okay to have a condition that can be created by a mortal user and
>> then cannot be changed by the root? The waiting process cannot be killed
>> and would keep "waiting" till system reboot.
>
> Aah, I see. No, it's not okay that a non-root user can create an
> unkillable process. -CURRENT doesn't have this problem because it
> rightly fails when a userland program tries to use RFPPWAIT. (It
> isn't supposed to be available to userland, which is why it isn't
> documented.) The problem could be fixed by backporting the
> relevant bits from -CURRENT.
>
>> I do not think it is a good idea to make ppwait state uninterruptible in
>> any case.
>
> I do not think it would be safe to deliver a signal to a parent
> process while a vforked child is borrowing its address space.
>
> Here's a patch against -STABLE:
>
> Index: kern_fork.c
> ===
> RCS file: /cvs/src/sys/kern/kern_fork.c,v
> retrieving revision 1.72.2.15
> diff -u -r1.72.2.15 kern_fork.c
> --- kern_fork.c 28 Sep 2003 11:08:31 - 1.72.2.15
> +++ kern_fork.c 4 Nov 2003 19:13:33 -
> @@ -130,6 +130,9 @@
> int error;
> struct proc *p2;
>
> + /* Don't allow kernel only flags. */
> + if ((uap->flags & RFKERNELONLY) != 0)
> + return (EINVAL);
> error = fork1(p, uap->flags, &p2);
> if (error == 0) {
> p->p_retval[0] = p2 ? p2->p_pid : 0;
You'll need to backport RFKERNELONLY as well in sys/unistd.h as that
isn't in 4.x AFAIK.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: POSIX Threads
On Wed, 29 Oct 2003 13:10:53 +0100, Isaac Gelado <[EMAIL PROTECTED]> wrote: But, when the server is running under FreeBSD 5.0 I think that you do really need to update your machine to 5.1-CURRENT for the threads. It's a lot improvement from 5.0, but I have no idea if it will solve your problem in that area. At least, you can help with the developers to keep the things up to date. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
On Mon, 26 Jan 2004, Steve Watt wrote:
> [EMAIL PROTECTED] wrote:
> >do what ping does (ping -f)
> >when you get an ENOBUFS do a usleep for 1 mSec.
> >and then send it again.
you are correct, but I just meant that it requested to sleep 1mSec, not
that the sleep actually WAS 1mSec.
Making udp sockets block would break so many things since
it was always this way since sockets were invented in BSD2.x
>
> So how, exactly, do you actually sleep for 1mSec? I recently did some
> experiments using nanosleep(), and it seems that the minimum sleep time
> is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system).
>
> Mind you, that behavior is precisely aligned with what POSIX says should
> happen, since nanosleep() is not allowed to return success before the
> specified amount of time has expired, and you might be calling it 5nS
> before the clock tick. But it does make doing correct Tx pacing a bit
> more challenging.
>
> Tried the same thing with usleep(1), same result of ~20mS per
> sleep.
>
> Here's the program I tested that with. Same results on a 4.4-RELEASE
> and a 5.2-RELEASE machine.
>
> Numbers from one run:
> 4.4-REL: 1501 loops, 30.017931 elapsed, time per loop: 19998.622 us
> 5.2-REL: 1501 loops, 30.016053 elapsed, time per loop: 19997.371 us
>
> - - - 8< - - -
>
> #include
> #include
> #include
>
> /* Seconds to count loops */
> #define RUNTIME 30
>
> int
> main(int argc, char **argv)
> {
> struct timespec start, now, end, delay, remain;
> double ts, te;
> long loops = 0;
> int rv;
>
> clock_gettime(CLOCK_REALTIME, &start);
> end.tv_sec = start.tv_sec + RUNTIME;
> end.tv_nsec = start.tv_nsec;
>
> do {
> delay.tv_sec = 0;
> delay.tv_nsec = 1; /* 10uS */
>
> do {
> rv = nanosleep(&delay, &remain);
> delay = remain;
> } while (rv < 0 && errno == EINTR);
>
> ++loops;
> clock_gettime(CLOCK_REALTIME, &now);
> } while ((now.tv_sec == end.tv_sec) ?
> (now.tv_nsec < end.tv_nsec) :
> (now.tv_sec < end.tv_sec));
>
> te = now.tv_sec + (now.tv_nsec / 10.);
> ts = start.tv_sec + (start.tv_nsec / 10.);
>
> printf("%d loops, %f elapsed, ", loops, te - ts);
> printf("time per loop: %.3f us\n", ((te - ts) / loops) * 100.);
>
> return 0;
> }
>
>
> --
> Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
> Internet: steve @ Watt.COM Whois: SW32
>Free time? There's no such thing. It just comes in varying prices...
>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: TCP MD5 (was Re: XL driver checksum producing corrupted but checksum-correct packets)
On Sun, Jan 25, 2004 at 07:59:32PM +, Aled Morris wrote: > If you're talking about RFC2385 style MD5 as used for BGP authentication, > I'd pay someone to make that work on FreeBSD (with Zebra/Quagga.) Someone already is, and I have patches for Quagga/Zebra ongoing... (how do you think I'm testing it? :-)) BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: XL driver checksum producing corrupted but checksum-correct packets
On Sun, Jan 25, 2004 at 01:13:28PM -0600, Mike Silbersack wrote: > I suppose that one thing we could do in the long run to help detect this > sort of corruption would be to import OpenBSD's TCP MD5 support and ensure > that packets which fail the md5 or fail the checksum are logged so that > they can be investigated. > > Of course, that's adding data to the packet, and heisenberg wouldn't be > too happy about that. :) I'm porting this right now. It's a bit different for us... BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
[EMAIL PROTECTED] wrote:
>do what ping does (ping -f)
>when you get an ENOBUFS do a usleep for 1 mSec.
>and then send it again.
So how, exactly, do you actually sleep for 1mSec? I recently did some
experiments using nanosleep(), and it seems that the minimum sleep time
is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system).
Mind you, that behavior is precisely aligned with what POSIX says should
happen, since nanosleep() is not allowed to return success before the
specified amount of time has expired, and you might be calling it 5nS
before the clock tick. But it does make doing correct Tx pacing a bit
more challenging.
Tried the same thing with usleep(1), same result of ~20mS per
sleep.
Here's the program I tested that with. Same results on a 4.4-RELEASE
and a 5.2-RELEASE machine.
Numbers from one run:
4.4-REL: 1501 loops, 30.017931 elapsed, time per loop: 19998.622 us
5.2-REL: 1501 loops, 30.016053 elapsed, time per loop: 19997.371 us
- - - 8< - - -
#include
#include
#include
/* Seconds to count loops */
#define RUNTIME 30
int
main(int argc, char **argv)
{
struct timespec start, now, end, delay, remain;
double ts, te;
long loops = 0;
int rv;
clock_gettime(CLOCK_REALTIME, &start);
end.tv_sec = start.tv_sec + RUNTIME;
end.tv_nsec = start.tv_nsec;
do {
delay.tv_sec = 0;
delay.tv_nsec = 1; /* 10uS */
do {
rv = nanosleep(&delay, &remain);
delay = remain;
} while (rv < 0 && errno == EINTR);
++loops;
clock_gettime(CLOCK_REALTIME, &now);
} while ((now.tv_sec == end.tv_sec) ?
(now.tv_nsec < end.tv_nsec) :
(now.tv_sec < end.tv_sec));
te = now.tv_sec + (now.tv_nsec / 10.);
ts = start.tv_sec + (start.tv_nsec / 10.);
printf("%d loops, %f elapsed, ", loops, te - ts);
printf("time per loop: %.3f us\n", ((te - ts) / loops) * 100.);
return 0;
}
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8" / 37N 20' 14.9"
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
On Mon, Jan 26, 2004 at 10:53:54AM -0800, Julian Elischer wrote: ... > On Mon, 26 Jan 2004, Stuart Pook wrote: > > > > On 23 Jan 2004, Don Lewis wrote: > > > > the send does not give an error: the packet is just thrown away. > > > > > > Which is the same result as you would get if the bottleneck is just one > > > network hop away instead of at the local NIC. > > > > But it isn't. I'm broadcasting onto the local network. With Linux and > > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just > > send(2) away, and because the send blocks when the kernel buffer space is I'd be really curious to know how Linux/Solaris actually implement this blocking send and if they really block or use some kind of timeout/retry loop in the kernel. To implement a blocking send() on UDP sockets, you need a different driver model from the one we have, one where sockets and other data sources trying to access a full interface queue should be queued into some kind of list hanging off the interface, so that when the interface is ready again you can wake up the pending clients in turn and process their requests. This would cause the output queue to become effectively unbounded (basically, it is like reserving at least one slot per socket -- more if you want to deal with fragments), and even if the slot can be allocated as part of the socket, the delay would become unbounded as well. Secondly, if the interface for some reason goes "temporarily" down (e.g. no-carrier or the like) the process would suddenly block unless you mark the socket as non blocking. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: send(2) does not block, send(2) man page wrong?
do what ping does (ping -f) when you get an ENOBUFS do a usleep for 1 mSec. and then send it again. On Mon, 26 Jan 2004, Stuart Pook wrote: > > On 23 Jan 2004, Don Lewis wrote: > > > the send does not give an error: the packet is just thrown away. > > > > Which is the same result as you would get if the bottleneck is just one > > network hop away instead of at the local NIC. > > But it isn't. I'm broadcasting onto the local network. With Linux and > Solaris (which implement what FreeBSD send(2) says), it is so easy: I just > send(2) away, and because the send blocks when the kernel buffer space is > full, I lose very few packets. With FreeBSD, I lose 60% of the packets. > (The aim is to broadcast onto a private 802.11b network.) > > If I don't want to saturate the network then I will use kernel level > traffic shaping to limit the outgoing bandwidth. I have already done this > on Linux when I was broadcasting onto my 802.11b network via an access > point connected via 100Mbits/s Ethernet. I just used traffic shaping > to limit the outgoing traffic on that Ethernet interface to 3Mbits/s. > I didn't have to change my program at all. (At one point I did try > to put the delays (with nanosleep) into my program but it worked very > badly because the scheduling delays were too big. The kernel does it > so much better.) Once again it is vital that send blocks. > > I guess that I'm out of luck with *BSD. I hope that someone will update > the send(2) man page so that the next person who wants to do what I'm > doing will know that it isn't possible with FreeBSD. > > Stuart > ___ > [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: send(2) does not block, send(2) man page wrong?
> On 23 Jan 2004, Don Lewis wrote: > > the send does not give an error: the packet is just thrown away. > > Which is the same result as you would get if the bottleneck is just one > network hop away instead of at the local NIC. But it isn't. I'm broadcasting onto the local network. With Linux and Solaris (which implement what FreeBSD send(2) says), it is so easy: I just send(2) away, and because the send blocks when the kernel buffer space is full, I lose very few packets. With FreeBSD, I lose 60% of the packets. (The aim is to broadcast onto a private 802.11b network.) If I don't want to saturate the network then I will use kernel level traffic shaping to limit the outgoing bandwidth. I have already done this on Linux when I was broadcasting onto my 802.11b network via an access point connected via 100Mbits/s Ethernet. I just used traffic shaping to limit the outgoing traffic on that Ethernet interface to 3Mbits/s. I didn't have to change my program at all. (At one point I did try to put the delays (with nanosleep) into my program but it worked very badly because the scheduling delays were too big. The kernel does it so much better.) Once again it is vital that send blocks. I guess that I'm out of luck with *BSD. I hope that someone will update the send(2) man page so that the next person who wants to do what I'm doing will know that it isn't possible with FreeBSD. Stuart ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
code compatibility between normal and geom methods for accessingdisk devices
Hi,
I wrote an fdisk program which uses several read(2) and write(2).
My program should compile on any unix that uses sane libc.
If compile it will work, except on systems that use geom methods.
I read that geom is accessed via struct BIO.
I can write a version of my program using struct BIO.
I'm sure it will compile and work.
Now should I maintain different version my program?
Or should I write a set of function for each method, then some code to
detect whatever method the kernel is using and use the appropriate set of
functions.
Also, I'm thinking, would it be a good idea to have another API to
interface every other devices API. Like:
Parent /devusing Master Device API
Child /dev/disk using GEOM API
Child /dev/netusing NET API
. . .
. . .
. . .
I'm a bit confussed...
[EMAIL PROTECTED]
thanks for reading
#include
#include
#include
#include
#include
#include
#include
int in;
int out;
int c = 0;
int bc_size = 446;
int pt_size = 66;
unsigned char buffer[512];
int bc_copy(char *source, char *destination);
int pt_copy(char *source, char *destination);
int bc_print(char *source);
int pt_print(char *source);
int p_activate(char *source, char *partition);
int p_type(char *source, char *partition, char *type);
int ptbe_edit(char *source, char *partition, char *bc, char *bh, char *bs, char *ec,
char *eh, char *es);
int ptle_edit(char *source, char *partition, char *slba, char *lbas);
int pt_sign(char *source);
void pt_list();
void usage();
main(int argc, char **argv) {
int opt;
if (argc == 1) { usage(); return -1; }
while ((opt = getopt(argc, argv, "a:c:C:e:E:hlp:P:S:t:u")) != -1) {
switch (opt) {
case 'a':
if ((argc != 4)) {
usage();
return -1;
}
p_activate(argv[2], argv[3]);
break;
case 'c':
if ((argc != 4)) {
usage();
return -1;
}
bc_copy(argv[2], argv[3]);
break;
case 'C':
if ((argc != 4)) {
usage();
return -1;
}
pt_copy(argv[2], argv[3]);
break;
case 'e':
if ((argc != 10)) {
usage();
return -1;
}
ptbe_edit(argv[2], argv[3], argv[4], argv[5], argv[6],
argv[7], argv[8], argv[9]);
break;
case 'E':
if ((argc != 6)) {
usage();
return -1;
}
ptle_edit(argv[2], argv[3], argv[4], argv[5]);
break;
case 'h':
usage();
break;
case 'l':
pt_list();
break;
case 'p':
if ((argc != 3)) {
usage();
return -1;
}
bc_print(argv[2]);
break;
case 'P':
if ((argc != 3)) {
usage();
return -1;
}
pt_print(argv[2]);
break;
case 'S':
if ((argc != 3)) {
usage();
return -1;
}
pt_sign(argv[2]);
break;
case 't':
if ((argc != 5)) {
usage();
return -1;
