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 unistd.h
#include stdio.h
#include fcntl.h
#include stdlib.h
#include limits.h
#include sys/stat.h
#include sys/types.h
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)) {
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]
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 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?
[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 stdio.h
#include errno.h
#include sys/time.h
/* 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: 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: 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: 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 stdio.h
#include errno.h
#include sys/time.h
/* 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: POSIX Threads
On Wed, 29 Oct 2003 13:10:53 +0100, Isaac Gelado [EMAIL PROTECTED] wrote: snip But, when the server is running under FreeBSD 5.0 snip 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: 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: 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]
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: 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 unix, 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: 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: snip But, when the server is running under FreeBSD 5.0 snip 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: 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: snip But, when the server is running under FreeBSD 5.0 snip 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]
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: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]
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: 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
